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 view this like the RFC1991->RFC2440 transition, where although we couldn't
drop IDEA completely we certainly made it clear an implementation probably
shouldn't use it. I suggest we take the same approach for 3DES. I agree
with you that being able to decrypt existing traffic is a good thing, but
I'd like to see strong language advising it not be used for generating new
traffic.
RFC4880 had AES128 as a SHOULD algorithm. Making it a MUST algorithm now
should not be a problem for most implmentations.
Agreed.
I do not object to making AES256 a MUST algorithm.
Thank you. :)
To get the most out of AES256, one needs enough entropy to properly seed
a PRNG to get 256 bits out of it... [good explanation snipped]
Built-in hardware random number generators are increasingly commonplace
nowadays. See, e.g., Ivy Bridge and later architectures.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp