Re: [openpgp] Default preferences for the future

["Mark D. Baushke" <[e-mail]>]

Robert J. Hansen <[e-mail]> writes:

> > I think TripleDES needs to go from a MUST to a SHOULD algorithm.
> 
> I don't see much point in dragging 3DES along with us into the future.
> It's done excellent service for 40 years, but the time has come to put
> it out to pasture.

I suppose it depends on how many messages you have encrypted that used
TripleDES as the algorithm. If you don't have an archive of encrypted
messages, then dropping TripleDES is not a big deal for you.

> > I think AES128 needs to be a MUST algorithm ... AES256 needs to 
> > be a SHOULD algorithm.
> 
> What's the rationale here? Why should the shorter keylength be
> required and the longer optional?

RFC4880 had AES128 as a SHOULD algorithm. Making it a MUST algorithm now
should not be a problem for most implmentations.

I do not object to making AES256 a MUST algorithm.

That said, if someone is using a symmetric key encryption from a pass
phrase, they are not really getting a very strong key. Certainly not one
that has 128 bits of randomness in it.

To get the most out of AES256, one needs enough entropy to properly seed
a PRNG to get 256 bits out of it. If one is using something like an
HMAC_DRBG with hmac-sha256, then really the entropy coming out of your
random number generator is only going to have 128 bits of security. So,
is there a real need to use AES256 for encryption if that is not how
many bits. I will grant you that a number of platforms are able to
provide 256 bits of strength, but not all of them.

A standard GNU/Linux system today which does not use a hardware source
of entropy and is only collecting mouse clicks and process interrupts is
not generally getting a lot of entropy for keys.

If I know that I have an OS that is using a hardware source of entropy,
then I have no problems using the stronger AES256 random key.

However, why use that much work if you know that the key is not really
that random?

	-- Mark