GnuPG 2.1.0 “modern” released

1. PGP's RSA constructions are archaic; they use a format defined in the 1990s that is vulnerable to multiple different attacks and likely to harbor more that we don't know about yet. (This, bafflingly, is also a problem with DNSSEC.) I should be clear: PGP is not itself known to be vulnerable to these attacks. But neither was Java's TLS implementation, before it was found to be vulnerable a few months back.

2. RSA is well-studied but it's hard to say how well we understand its strength. There are no credible attacks on RSA-2048, but academic progress is being made on a cousin of the factoring problem it relies on (the discrete log problem). ECC is based on a harder math problem, is also well studied, and is believed to be stronger.

3. ECC is faster and provides more security with fewer key bits.

A combination of all three of these factors gives a sort of second-order issue, which is that modern public key crypto constructions tend to be based on ECC and not multiplicative group IFP/DLP algorithms. EdDSA is good for reasons other than that it's based on good ECC crypto.

Hope that's helpful and not just noise. Looking forward to inevitable 'pbsd correction. :)

>For many people the NIST and also the Brainpool curves have an doubtful origin and thus the plan for GnuPG is to use Bernstein’s Curve 25519 as default.

[1] http://cr.yp.to/ecdh/patents.html

[2] https://gnupg.org/faq/whats-new-in-2.1.html

The non-ed25519 ECC techniques in the OpenPGP standard have well establish too-old-to-be-patentable prior art: https://tools.ietf.org/html/rfc6090

While there were (and are) some specific implementation techniques for efficient ECC covered by patents, many of them have now expired, and many others have better patent-free alternatives anyway.

Further, why would timing attacks necessarily be more or less of an issue in a higher-level language than C? This is a genuine question.

I feel like in any case, there are some things that should just not be done in C. For example, the base64 encoder/decoder that gpg uses for ASCII-armoring should not be written in C; in general any parser should not be written in C; there's no reason for the code that interfaces with the user (for example, checking a password given to gpg-agent) to be written in C. You could write these in OCaml, use the FFI to natively link them into a single executable, and you'd have safety for string handling while retaining fine-grained control of the hardware during crypto.

However, I'm skeptical that you literally cannot use OCaml to implement crypto that's secure against timing attacks. You can always fall back to C for primitive operations, and you can control the garbage collector enough that gc pauses wouldn't be an issue.

IMO, the most compelling reason not to do this is that for all its fatal flaws, C is the most widely-used systems programming language, and so it has the largest share of experts ready to review code. But this doesn't seem like a good enough reason, given the severity of memory corruption bugs.

Ed448-Goldilocks is great, and may indeed be a good contender for certificates as it seems to represent a good inflexion point of security versus performance.

The Crypto Forum Research Group at the IRTF is currently considering recommendations to make to the TLS Working Group (and perhaps to be used more widely) regarding elliptic curves: I've been a, um, vocal participant there already. I've raised this development there, as it may spur the discussion forward.

Goldilocks is one of the potential curves on the table there. There's potential enthusiasm for recommending two curves: one strong, fast curve with ≈128-bit workfactor (quite likely Curve25519 in my opinion) and one super-strength curve, at least 192-bit workfactor (possible candidates include MS Research "NUMS" P384/P512, Curve41417, Ed448-Goldilocks, and E-521). The option of generating entirely new Brainpool-style random curves isn't off the table either, and some have been asking for that, but I'm really not sold: the software performance of random curves is absolutely dreadful, the implementation can be the kind of hairball we want to avoid, those asking seem to be asking because they're heavily committed to hardware with aged generic (RSA-targeted) hardware multipliers with anti-side-channel blinding that is no longer great and doesn't work right over special primes - and besides, if we wanted Brainpool, we could just use Brainpool. (Brainpool is indeed in this GnuPG release if you want it.)

If I was not performance-sensitive and wanted the highest level of security I could reasonably get from curves, maybe I'd choose E-521, which has impressive rigidity, being independently discovered and confirmed by multiple research teams, and good performance for its class due to being a Mersenne prime. But you do pay quite a bit of performance to go from the ≈224-bit to the ≈250-bit+ range, and it's not clear to me that's particularly meaningful in all cases. (Of course, maybe PGP is one of those cases, and performance isn't usually a big deal there unless it's really bad.)

Regarding SPHINCS, 41KB signatures are remarkable for what they are, but not practically ideal for OpenPGP, especially with the way the keyservers are now, but you know, I could maybe live with it. I could see it start to get ugly for keys with a lot of verifying counter-signatures on them, however.

Do remember OpenPGP doesn't bring everything to the table: for example, forward security. And MUAs have a reputation for awful UX regarding it - operator error is extraordinarily frequent. But it seems to at least be Pretty Good in practice. Thanks Werner & team!