undefined | Better HN

0 pointsAlyssaRowan11y ago0 comments

I take your point, but honestly I don't think at this time that Curve25519 (or properly implemented RSA-3072) will fall cryptologically in any reasonable timeframe without either a quantum computer or a really fundamental development in factoring/discrete logs that would probably threaten RSA-4096 roughly as badly.

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!

0 comments

2 comments · 1 top-level

nullc11y ago· 1 in thread

I'm kinda bummed that all the considered sexy curves are cofactor!=1, beyond losing a bit of rho security, it makes implementations more complex and complicates derivation schemes. (I think it also shows there is more flexibility in supposedly rigid schemes than people give credit for; IIRC brainpool _required_ cofactor 1, but a speedup is suggested (montgomery ladder instead of using a slower constant time addition law) and tada, relaxed in future curve specs. This is especially acute for PGP where performance on this sort of scale is basically a non-issue: practically no one needs to verify tens of thousands of PGP signatures per second.

Indeed, PGP doesn't bring everything to the table (You fail to mention non-repudiation, but the fact that I can't authenticate a pgp message without producing a transferable signature is a pretty big flaw for general correspondence)... but, considering the the limitations and usability concerns, it appears to me to be most suited and widely used for higher security applications authenticating software distributions with long term keys, which effectively all the rest of our computer security ends up resting on it. Other things end up being protected by OTR, TLS .. or not at all. :( We effectively have no general widely deployed "high security" option for long term person to person encryption and authentication except PGP.

wbl11y ago

This is incorrect. Cofactor 1 does not have a complete addition law, nor did original specs forbid cofactor >1 on security grounds. The Montgomery ladder doesn't have certain kinds of weaknesses common in naive implementations of Weierstrass form addition. Clearing the cofactor is easier. I can fit Montgomery ladder in 10 lines, and can't do that with a secure Weierstrass implementation.

j / k navigate · click thread line to collapse