[Announce] GnuPG 2.2.1 released

[Robert J. Hansen]

> Is there a reason the changes defaulting to 3072-bit RSA keys [1] and
> AES-256 [2] from refs/heads/master did not make it into
> refs/heads/STABLE-BRANCH-2-2?

No comment on the reasons -- it's not my bailiwick.  However,

> OTOH, the NSA is apparently developing a new supercomputer named
> "WindsorGreen" believed to attack crypto, probably even "breaking
> older/weaker (1024 bit) RSA keys".

This one, I feel the need to shed some caution on.  Breaking 1024-bit
keys is *hard*: it's estimated to be a work factor of about 2**80.
Breaking 2048-bit keys is a work factor of about 2**112, or over a
billion times harder.  If we're just now reaching the point where
1024-bit keys are in serious jeopardy, it's hard for me to imagine
2048-bit keys will be in jeopardy any time soon absent some
technological development that's indistinguishable from magic.

NIST's guidance is that by 2020 we should switch over to 3072-bit keys.
We're still in the zone of safety.  The 3072-bit switchover needs to
happen and it needs to be a priority item, but it's not urgent that it
happen now, or even within the next six months.  We have time.

With respect to AES-256, the real issue to me is one of block size, not
key length.  All of the symmetric ciphers in OpenPGP are completely
impractical to brute force.  The real risk comes from the continued use
of 64-bit block ciphers, which run the possibility of repeating state
after only a few gigabytes are encrypted.  So if users are encrypting
multi-gigabyte files with CAST5, BLOWFISH, 3DES, or IDEA, that's a *far*
greater risk than using AES128.

I, personally, would like to see GnuPG refuse to use 64-bit block
ciphers for encryption unless an option was set (--allow-old-ciphers,
perhaps).  Leave the algorithms in there for RFC conformance, let them
decrypt without a warning, but require an option to be set for using them.