Im all for deprecating and/or outright dropping of support for older
ciphers, it needlessly complicates the code and testing matrix, even if
they are optional to implement. Frankly, very few people actually use,
say, CAMELLIA, in the wild. I don't think anyone would notice if it
However, if you get really restrictive (from your "eventual" list below)
and cut off support for common key sizes like 2048-bit RSA or keys that are
1 year old, you risk cutting off a huge chunk of the active OpenPGP user
base. People are very reluctant to give up or create new keys once they
have distributed they public key to others, even if said key is old and
weak, unfortunately. Updating existing keys (revoking sigs/keys, adding
new subkeys, etc) is considered black magic and far too complicated for
most casual users. Though perhaps that issue could be solved by
streamlining the process in the various implementations. Im not sure the
usability issue can be solved by the standard itself.
If the goal is to increase the use and popularity of OpenPGP, locking out a
significant number of current users seems counterproductive. Obviously,
that would be an implementation and business decision for Yahoo! and Google
to make in their codebase and not really relevant debate for this WG...
On Fri, Mar 13, 2015 at 9:23 PM David Leon Gil <coruus(_at_)gmail(_dot_)com>
First, the fait accompli:
1. Yahoo and Google have both already deprecated and removed support
for the following packet type specified for use with OpenPGPv4:
Tag 9 (symmetrically encrypted) packets
These packets provide unauthenticated encryption and -- if supported
-- can be used in a downgrade attack on senders who only use SEIPD
packets. See https://github.com/coruus/cooperpair/tree/master/encrux
2. Yahoo and GnuPG have both already deprecated V3 public keys for any
use. We recommend that other implementations do the same.
Second, the near future:
Yahoo has deprecated, and intends to disable support for all uses, of
the following primitives and packet types specified for use with
- Symmetric cipher algorithms: IDEA, TDES, CAST5, Blowfish, Twofish
- Asymmetric algorithms, generally: RSA-ES, DSA.
- Asymmetric algorithms, unless > 3070 bit key length: RSA-S, RSA-E, ELG-E.
- Compression algorithms: ZLIB. (It provides no benefits over DEFLATE,
and is more malleable.)
- Hash algorithms: MD5, SHA-1, RIPEMD160, SHA-2-224.
We do not, at present, support any of the CAMELLIA algorithms or
BZIP2. It is unlikely that we will do so in future.
At present, we anticipate removing support for these primitives no
later than May 1, 2015.
Third, other things that will be deprecated soonish:
1. Inconsistent combinations of primitives. In particular, it is
likely that we will not support RFC 6637 keys or packets unless they
conform to the 128-bit or 192-bit subprofiles specified in that
document. (We do not at present support P-521, but if we add support
for that, we would support an analogous "256-bit" subprofile.)
2. AES-128. The efficiency of multi-target attacks leaves no safety
margin for cryptanalysis. The performance difference between AES-128
and AES-256 on typical messages is negligible.
Finally, other things that may eventually result in messages or keys
being treated as invalid:
1. A published public key that is more than 1 year old. (This is
mainly taken care of by requiring > 3070 bit RSA keys...)
2. Signature by a public key which has ever signed a message or key
using MD-5 or SHA-1.
3. A compressed or literal data packet tag that is unusually formatted.
4. A compression method other than "Uncompressed".
David Leon Gil
openpgp mailing list
openpgp mailing list