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

[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.


>
>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130522/8d60dc59/attachment.html>