encryption algorithm

[Hauke Laging]

Am Di 17.12.2013, 15:57:54 schrieb Daniel Kahn Gillmor:

> RSA 1024 falls
> in at the equivalent of about 73 bits of symmetric cipher.  According to
> the authors, this is  "Short-term protection against medium
> organizations, medium-term protection against small organizations", not
> "a First World government".
> 
> While i don't agree with adrelanos' entire draft, i do agree that the
> default key size for gpg should be larger.  A default key size of 3072
> or 4096 bits for RSA keys sounds reasonable to me.

> We do not do the users of GnuPG any favors by continuing to generate
> weaker-than-expected keys and certifications by default.

There are non-technical arguments against your position. No, Rob, I don't have 
a scientific study for that but I guess (and invite everyone to follow mw with 
this) that using something above the minimum but below the maximum serves an 
educational purpose.

I believe there is a broad agreement that you need to *learn* what good crypto 
is (involving the whole process containing crypto, not just the small crypto 
element) to get "security". One more wild guess: 99.9% of the systems on which 
GnuPG is *actively* used do not even provide the "equivalent" of a 73-bits 
key.

If the 99.9% get 2048 bit by default then they ask: "Why not more?" That can 
be kind of annoying here but at least they ask and get told. And some probably 
understand. That's a security gain. If they notice "I have maximum security 
now" because the default is raised to 4096 then they will not ask but often 
make stupid assumptions about their overall security.

Effective use of crypto mandatorily demands for some understanding. It is 
trivial for everyone with this understanding to select the key size. So what 
real-world problem is going to be solved here?

And what could be the "expected key strength" for users with no clue about 
crypto?

I support dkg with respect to the digests, though. And I think that GnuPG 
really needs an option like personal-digest-disallow. Sende-recipient 
negotiation all well and good, but it must be possible to say: Not me! Even 
against the RfC. With such a command line option an application can easily 
limit that to certain cases (though the validity calculations must be 
configured globally, of course). We should not expect the applications to 
filter disallowed digests. Often the crypto knowledge of application 
developers is limited.


Hauke
-- 
Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/
http://userbase.kde.org/Concepts/OpenPGP_Help_Spread
OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 572 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20131217/96652624/attachment-0001.sig>