On Sunday, March 15, 2015, Daniel Kahn Gillmor <dkg(_at_)fifthhorseman(_dot_)net
<javascript:_e(%7B%7D,'cvml','dkg(_at_)fifthhorseman(_dot_)net');>> wrote:
Yahoo has deprecated, and intends to disable support for all uses, of
the following primitives and packet types specified for use with
OpenPGP v4:
- Symmetric cipher algorithms: IDEA, TDES, CAST5, Blowfish, Twofish
- Asymmetric algorithms, generally: RSA-ES, DSA.
Are you referring to Public Key Algorithms specifically here? in
particular, this table:
https://tools.ietf.org/html/rfc4880#section-9.1
If so, RSA-ES (pubkey algorithm 1) is very widely used, even for keys
that are only marked for one usage (signatures or encryption). In fact,
i don't think there are many RSA keys labeled RSA-E (algo 2) and RSA-S
(algo 3) at all. Why treat RSA-ES separately for deprecation?
You're quite right; this was a mistake.
- Asymmetric algorithms, unless > 3070 bit key length: RSA-S, RSA-E,
ELG-E.
How did you choose this cutoff? I'm happy to see a high bar personally,
but this is likely to invalidate many 2048-bit keys that people have
been generating with (e.g.) the GnuPG defaults today. Do you think that
GnuPG should change its defaults to the higher cutoff?
Page 22 of the ENISA key-length report has a summary of recommendations.
The (NSA-written) NIST standard in this area requires 3072-bit keysize for
128-bit security. Other sources require much longer keys.
Yes, I think that GnuPG should change its defaults; I think that 128-bit
security is the bare minimum threshold for security.
- Compression algorithms: ZLIB. (It provides no benefits over DEFLATE,
and is more malleable.)
Why keep DEFLATE at all? quining seems to be possible with DEFLATE as
well. what if we yanked all compression at this layer?
I'd be happy to.
(on openpgp quining due to compression, see the 2013-10-08 entry at
http://mumble.net/~campbell/blag.txt)
Thanks for the link. There are a lot of problems with doing compression and
encryption, especially with a block-chaining mode...
I'd be quite happy to deprecate everything but uncompressed.
- Hash algorithms: MD5, SHA-1, RIPEMD160, SHA-2-224.
The OpenPGPv4 fingerprint uses SHA-1, in a way that doesn't appear to be
cryptographically risky; i'm assuming you're not removing v4
fingerprints entirely, just SHA-1 as a digest algorithm for message
signing. right?
Well, I'm not a great fan of v4 fingerprints or the SEIPD+MDC mode, but
yes: That list only refers to usage for signatures.
1. A published public key that is more than 1 year old. (This is
mainly taken care of by requiring > 3070 bit RSA keys...)
Can you say more about this? Is this about a specific cutoff in time,
or *anything* that is "more than 1 year old" at the present? If it's
the latter, what effect do you expect this kind of regular key rollover
will have? why is it warranted?
Sure. How many days since the last zero-day security vulnerability on the
computer you are using? (Hopefully you're using something awesome with
grsecurity etc., but most users aren't.)
It will be a rolling cut-off. (In future, it is possible that there may be
some non-user-circumventable prohibition on reusing RSA moduli, in
particular.)
(This applies, but with somewhat less force, to most hardware-protected
keys: It is likely that they have been used often enough that more
sophisticated attacks are likely to have been able to recover the key. And
if you're using hardware protection, you are probably a likely target of
attackers with these capabilities.)
2. Signature by a public key which has ever signed a message or key
using MD-5 or SHA-1.
How would you tell if this is the case? Isn't ignoring MD5 and SHA1
signatures itself sufficient?
An exported key, for example, may have a subkey which it has signed using
MD5. I consider this to invalidate the signing key.
A brief description of the (tentative) algorithm: Attempt to import an
importable public key. If any signature packet in the composition uses a
weak hash algorithm, reject the importable key in its entirety.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp