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

[Abel Luck]

Kyle Butt:
> On Wed, May 22, 2013 at 2:19 AM, Werner Koch <wk at gnupg.org> wrote:
> 
>> 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?
>>
> 
> While passphrases are the weakest link in general, This isn't true of
> every gnupg user, just most. That's why I left the default as AES-128.
> Most gnupg users will never see the option or consider changing it.
> 128 bits of entropy isn't that far out of scope, that's 20 printable ascii
> characters, and a dedicated user could memorize that.
> 
> I never tried to argue about storing a random passphrase and pasting
> it. I don't believe it's relevant to the discussion here.
> 
> 
>>
>>> 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.
>>
> 
> I would be willing to do this work.
> 
>>
>> For small devices a different KDF (e.g. scrypt) might be useful, though.
>>
> 
> Or this.
> 

This is what I would like to see. It is desperately needed on Android
and other mobile devices where users use even weaker than normal
passphrases.

> 
>>
>>
>> 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.
>>
>>
> I'm not sure I understand the argument here. Are you saying that you
> agree, and that rather than have it be a flag, it should be dependent
> on key size and selected automatically? I'd be happy to send that patch
> instead.
> 
> Kyle.
> 
> 
> 
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
>