[PATCH] Allow the user to specify AES256 as well as AES128.

Werner Koch wk at gnupg.org
Wed May 22 11:19:32 CEST 2013


On Wed, 22 May 2013 03:08, gniibe at fsij.org said:

> Although it is a story in future for me, I could imagine that some
> people using RSA 4096-bit key now (w/ enough entropy for their pass
> phrases) would like that, to match its content.

The weakest link we have in the key protection is the passphrase -
virtually nobody is able to remember a passphrase with 128 bit entropy
and 256 bit is well out of scope.  Now I hear a counterargument of a
random passphrase which is pasted into the Pinentry.  That bears the
question where to store that one and whether this additional software,
USB gimmicks etc. don't introduce a much higher risk of passphrase
compromise.  The passphrase tries to mitigate the worst case of a
compromised box - now if that is the risk, what are the probabilities
that such a compromise is limited to a one-time disk or memory copy
attack and not a long lasting active keyboard (or whatever) sniffing
attack?  Does anyone really consider that this probability is less than
breaking 128 bit AES?

> Well, I have a suggestion that it will be better to use SHA-2 of
> relevant size, instead of SHA-1.  It will be more coherent, then.

To satisfy todays crypto policy requirements, it would be better to move
to a MAC based encryption scheme instead of the ad-hoc OpenPGP encrypted
SHA-1 integrity checking.

For small devices a different KDF (e.g. scrypt) might be useful, though.

> I'm not sure if it should be a user option or not.  It makes more
> sense for me, when GnuPG selects appropriate key store scheme
> automatically.

Yep.  Algorithm proliferation does not gain us anything.  In fact it
makes the system more weak.  If we want to extend the current key
protection, a single alternative algorithm with a well defined use case
is what we should do.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.




More information about the Gnupg-devel mailing list