zlacker

You might want to look at page 19 and 35:

http://www.spiegel.de/media/media-35515.pdf

Did he actually say break?

>>tete+(OP)
No, he did not say break in his talk. He said something along the lines of "at one point, the NSA mentions SSH together with SSL and IPsec as technologies which there are methods against" which could mean just about anything. They could break into the host and steal the host keys for example, without having to do costly cryptanalysis.

But the moment he breathed SSH, pretty much all of IRC and the whole Saal 1 could not think of anything else. Everyone and their brother wanted to know what to use instead of SSH now that it's broken. It was a bit of panic in the air.

My suggestion is to go to the leaked slide and make your own conclusions. There are among the most credible people we have behind openssh and the crypto primitives are used in a very straightforward way.

>>xorcis+t8
They talk about decrypts of SSH tunnelling as a "potential", if they can later steal the keys. SSH, I note, does have an RSA-based key exchange as well as its usual Diffie-Hellman: if their targets have been using plain RSA, that would make an attacker's life easier for historical decrypts! Based on their typical methodology, I think that is probably what they are talking about, because they mention stealing IPsec pre-shared keys from router configurations in a very similar context.

Of course, all we have is a probably - this selection of documents is not anywhere near as comprehensive as we'd perhaps like here. We're having to fill in the blanks - and there's too many blanks to fill in clearly. There seems to be relatively little in this leak from NSA's PICARESQUE/PIEDMONT, or GCHQ's STRAP3 (which covers specific operational details: purely by way of hypothetical example :-), where individual full-take feed taps actually are in Telehouse North, or specific details about SIGINT enabling via the Cavium Nitrox chips), sadly. Alternative ideas (or leaks!) are welcomed.

Recent versions of OpenSSH have using some non-NIST primitives from djb, including Curve25519-SHA256 key exchange, Ed25519 keys and ChaCha20-Poly1305 transports. I am quite confident neither NSA nor GCHQ have any good cryptanalytic attacks against those primitives.

There is mention of some exploitation against finite-field Diffie-Hellman in TLS (PHOENIX). That lacks context, however, and we can only guess about what's missing. One possibility is it's an active attack which tricks the peers into agreeing keys over an unsafe field (TLS 1.2 has no way to date for peers to suggest or agree on lists of named fields; however, the recent ffdhe draft does provide one) - however active attacks don't really fit the context under discussion in the slides. The TLS Working Group at IETF is currently discussing this, and a suggestion's been made to remove the old finite-field DHE transports due to their poor performance and apparent vulnerability, replacing them with ECDHE over secp256r1 (a NIST curve), and quite possibly in the near future X25519 over Curve25519 (a non-NIST curve). I don't know how that's going to resolve yet.

>>Alyssa+sq
That TLS thread is nonsense. Take Dan Boneh's latest TLS survey paper [1], and notice that 34% (!) of DHE-supporting servers still support 512-bit ephemeral primes, and virtually every server defaults to 1024 bits. Who needs fancy new cryptanalysis?

Removing DHE is a mistake. The discrete log in prime fields is fine---as fine as RSA is, anyway---and it's a handy PFS backup in the (unlikely) case deployed elliptic curves turn out to be significantly wounded.

[1] http://www.w2spconf.com/2014/papers/TLS.pdf

>>pbsd+Cs
I know, right? Chilling. I could crack those (the 512-bit ones, anyway). Why on earth would we want to keep those around?

Your first sentence seems to me like an excellent reason to remove DHE altogether from TLS 1.3, considering those servers do not support, and presumably may never support, (the draft) Finite Field DHE parameter negotiation.

Discrete log in prime fields does have the index calculus problem; it won't keep being good forever, and the performance gets worse. I'm banking on having enough different backup between ECDHE over secp256r1 and X25519 over Curve25519 that any elliptic curve difficulty won't be a problem.

>>Alyssa+my
When I say DHE, I mean finite field DH in general; I have no beef with replacing the old TLS DHE mechanism by the one from the ffdhe draft, with curated prime fields to work with.

Index calculus. Over prime fields it has seen essentially no major progress (beyond small complexity tweaks, some of which are useful) since 1992 with the number field sieve. Index calculus also exists for elliptic curves, under some conditions: once again, over prime fields things seem fine (modulo MOV, anomalous, etc curves). I suspect we will also have to drop RSA if the index calculus for prime field discrete logs ever improves significantly. Likewise, some efficient attack against P-256 or curve25519 has a good chance to eliminate most or all curves in that size range.