Logjam TLS attack

I don't think the NSA can do this on demand.

> People should just use 2048 bit keys, or stop using conventional prime field public key algorithms altogether, is what I think.

I believe moving towards ECC (especially djb's work) is probably the right move.

We can't do the former thing at all for 2048 bit DH/RSA, let alone the latter.

Entities attacking 1024 bit keys are doing something we've believed would be inevitable for something like a decade.

When 2048 bit DH/RSA falls, DH and RSA will probably fall with them; they won't fall because compute resources eventually catch up to them, but rather because we discover something about integer factorization or discrete logs that makes prime field cryptography altogether unsafe.

The problem with reusing them is of course when they're not strong enough, and so if an adversary can pop one, they can get a lot of traffic - and as I've said for a while and as the paper makes clear, 1024-bit and below are definitely not strong enough. Anything below 2048-bit would be a bit suspect at this point (which is precisely why the TLS Working Group rejected including any primes in the ffdhe draft smaller than that - even though a couple of people were arguing for them!).

If you're still needing to use 1024-bit DH, DSA or RSA for anything at all, and you can't use larger or switch to ECC for any reason, I feel you have a Big Problem looming you need to get to fixing. Custom DH groups will not buy you long enough time to ignore it - get a plan in place to replace it now. We thought 1024-bit was erring on the small side in the 1990s!

I concur that the NSA's attack on VPN looks like an operational finite-field DH break - I didn't realise that two-thirds of IKE out there would still negotiate Oakley 1 (768) and 2 (1024), but I suppose I didn't account for IKE hardware! Ouch!

Their attacks on TLS are, though also passive, architected far more simply and more suggestive of an RC4 break to me as there seems to be no backend HPC needed - ciphertext goes in, plaintext comes out. Both are realistic attacks, I feel, but RC4 would have been far more common in TLS at the time than 1024-bit DHE, and although 1024-bit RSA would be present many likely sites would have been using 2048-bit, so naturally they'd go for the easiest attack available. (That gives us a loose upper bound for how hard it is to break RC4: easier than this!) I also don't think the CRYPTO group at GCHQ would have described this as a "surprising […] cryptologic advance" from NSA, but just an (entirely-predictable) computational advance, and (again) lots of people in practice relying on crypto that really should have been phased out at least a decade ago. So there's probably more to come on that front.

Best current practice: Forget DHE, use ECDHE with secp256r1 instead (≈128-bit workfactor, much faster, no index calculus). You can probably do that today with just about everything (except perhaps Java). It will be faster, and safer. And, we know of nothing wrong with NIST P-256 at this point, despite its murky origins.

Looking forward, Curve25519 (≈128-bit) and Ed448-Goldilocks (≈222-bit) are, of course, even better still as the algorithms are more foolproof and they are "rigid" with no doubts about where they come from (and in Curve25519's case, it's even faster still). CFRG is working on recommending those for TLS and wider standardisation. You can use 25519 in the latest versions of OpenSSH right now, and you should if you can.

By "on your keyrings" I mean that quite a few PGP keys in the wild still use DSA-1024 master signing keys with (often much larger) ElGamal encryption subkeys (as DSA was not specified for a long time with keys beyond 2048-bits).

However, DSA-1024/(ElGamal-anything) is not a safe configuration anymore - an attacker who can do a discrete-log on a highly-valued 1024-bit finite field can recover the signing key, and sign things - including software released under that key, or grant themselves new encryption subkeys of any strength.

It may therefore be a good idea to review your PGP keyrings for any master keys you trust which fit that 1024-bits and below criteria (look for 1024D, or below), as they definitely are overdue an upgrade. You may find that a fruitful search, with a few surprises still. For example, to pick one high-profile signing key that would doubtless have been interesting to Nation-State Adversaries and would have been susceptible to such an attack: http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0xE3BA7... ˙ ͜ʟ˙

The common safe configuration for modern OpenPGP (and upstream GnuPG's current default, I believe) is to use RSA signing keys and RSA encryption subkeys, each of at least 2048 bits - really I'd recommend 3072 or 4096 bits, as use of PGP is not as performance-sensitive as TLS and there is no forward secrecy, so I wouldn't really recommend going much below a ≈128-bit workfactor (equivalent to ≈3072 bit RSA or ≈256-bit elliptic-curve).

Edward Snowden trusted RSA-4096 signing and encryption keys with his life, and that obviously worked out fine for him at the time.