4 ms·

They're only slides. We don't have audio of the presentations. :) I did wonder about that, but no "common" internet encryption protocols use pairing-friendly (

They're only slides. We don't have audio of the presentations. :) I did wonder about that, but no "common" internet encryption protocols use pairing-friendly (in the open source cryptographic community sense) primitives. I think you're about right and it probably refers to matching public and private keys for CAs in SSL/TLS, looking up suitable intermediate CAs, for which they may have a few keys stashed away. They don't seem enthusiastic to wave them around much, however. I believe they probably have long-term cryptologic cracking capability (HPC) including 1024-bit RSA, but probably not 2048-bit. Maybe MD5? Maybe SHA1? Look at the long list of trusted CAs in a browser, and try to map all the intermediates they've ever signed. You may find a few likely candidates.

EthanHeilman 12y ago
To extend your statements: * breaking 1024-bit RSA is believed to be well within the resources of the NSA given public research/attacks.[0] * MD5 is already completely broken in the public research and the NSA has used MD5 collisions in malware attacks that are independent of public methods[1]. * RC4 has been attacked for a number of years, and someone who has seen unreleased Snowden documents claimed that the NSA has the ability to break RC4 in realtime[2]. Plenty of HTTPS traffic is protected by RC4. [0]:"One estimate is made by Shamir & Tromer (2003) in their hypothetical TWIRL device. They suggested that for "a few dozen million US dollars", a hardware device could be built to break a 1024-bit RSA key within around a year. Franke et al (2005) similarly estimate a cost of 200 million dollars2 for a machine to factorise a 1024-bit number in one year. If these cost estimates are accurate, it's safe to assume that the NSA has built such a machine (unless they have another way of breaking RSA more efficiently). And by Moore's Law alone, we'd assume that their machine takes considerably less than a year." http://www.javamex.com/tutorials/cryptography/rsa_key_length.shtml http://www.javamex.com/tutorials/cryptography/rsa_key_length... [1]: "He discovered that for this spy malware an as yet unknown cryptographic attack variant of his own MD5 attack is used." http://www.cwi.nl/news/2012/cwi-cryptanalist-discovers-new-cryptographic-attack-variant-in-flame-spy-malware http://www.cwi.nl/news/2012/cwi-cryptanalist-discovers-new-c... [2]: "RC4 is broken in real time by the #NSA - stop using it." https://twitter.com/ioerror/status/398059565947699200 https://twitter.com/ioerror/status/398059565947699200
- AlyssaRowan 12y ago
  Yes - I concur that the "cryptanalytic breakthrough" GCHQ talked about the NSA having a few years ago was most probably some kind of a practical RC4 break, from context. (Schneier thought this one of the likely possibilities too.) It's used enough in TLS (especially at the time these documents were penned, as some advising on BEAST countermeasures actually encouraged people to use it, instead of switching to TLSv1.2 to use the strong AEAD ciphers - awfully convenient for them!) that if they have, say a known-plaintext-prefix attack of reasonable complexity that can be hardware-accelerated, that would be widely leveragable into very real breaks to them - and the structure of such a thing would look remarkably like what we see here. RC4 is about as good as such a simple crypter can be, but it really is too simple and not good enough now, and I strongly suspect it is already toast and way too late to safely phase out - which is why the IETF are hopefully about to publish an RFC strongly recommending it MUST NOT be used in TLS, at all. (Worse, even if RC4 isn't toast to everyone right now, an attacker who can put your data on ice for a few years - like just about every Nation State Adversary does - may very well make toast with it down the line and read all your data.) We don't have any second-preimages in MD5, yet; what's demonstrated are techniques for efficient collisons. They might, but collisions are easily enough for practical problems as many have publicly demonstrated. SHA-1 hasn't been publicly demonstrated with a collision yet, but it has all the same underlying problems as MD5 (and the original SHA), just to a lesser extent - I suspect that NSA can produce SHA-1 collisions with enough effort. Don't expect them to spend more effort than they need, however, to save money and avoid revealing capabilities where possible. Several attackers have happily leveraged simpler shortcuts - there's a piece of (probably South Korean) malware that has signing keys co-opted from hapless developers who've somehow been derping around with 512-bit RSA keys. I could break those, so that's completely ridiculous! By the way - do be on the look out for PGP signatures with 1024-bit DSA signing keys. There's a lot of them. Upgrade to at least 3072-bit RSA, I suggest (or Ed25519).
sneak 12y ago
> I think you're about right and it probably refers to matching public and private keys for CAs in SSL/TLS, looking up suitable intermediate CAs, for which they may have a few keys stashed away. Compromise of a CA's key does not permit decryption of traffic encrypted by server keys that use certificates (signatures) from those CAs. This is a common misconception. It would allow for issuing (signing) a rogue, second key that could then be used to silently active MITM a connection - but getting the CA's key does not give you the VPN server's key. (Remember, a certificate is just a signature by a CA over the hash of the VPN server's public key. The CA never sees the private key of the VPN server, nor is the CA's key used for anything other than signing.)
- AlyssaRowan 12y ago
  Yes, but they're man-on-the-side already, and they already have the QUANTUM set of attacks and similar for actively racing an MITM on any TCP/UDP/ESP/etc/IP connection they want - and if they have a CA trusted for the purpose by the relevant endpoint, they can safely man-in-the-middle TLS, IPSec, etc. That's what the diagram shows, essentially: the front end of that attack.

EthanHeilman 12y ago

To extend your statements: * breaking 1024-bit RSA is believed to be well within the resources of the NSA given public research/attacks.[0] * MD5 is already completely broken in the public research and the NSA has used MD5 collisions in malware attacks that are independent of public methods[1]. * RC4 has been attacked for a number of years, and someone who has seen unreleased Snowden documents claimed that the NSA has the ability to break RC4 in realtime[2]. Plenty of HTTPS traffic is protected by RC4. [0]:"One estimate is made by Shamir & Tromer (2003) in their hypothetical TWIRL device. They suggested that for "a few dozen million US dollars", a hardware device could be built to break a 1024-bit RSA key within around a year. Franke et al (2005) similarly estimate a cost of 200 million dollars2 for a machine to factorise a 1024-bit number in one year. If these cost estimates are accurate, it's safe to assume that the NSA has built such a machine (unless they have another way of breaking RSA more efficiently). And by Moore's Law alone, we'd assume that their machine takes considerably less than a year." http://www.javamex.com/tutorials/cryptography/rsa_key_length.shtml http://www.javamex.com/tutorials/cryptography/rsa_key_length... [1]: "He discovered that for this spy malware an as yet unknown cryptographic attack variant of his own MD5 attack is used." http://www.cwi.nl/news/2012/cwi-cryptanalist-discovers-new-cryptographic-attack-variant-in-flame-spy-malware http://www.cwi.nl/news/2012/cwi-cryptanalist-discovers-new-c... [2]: "RC4 is broken in real time by the #NSA - stop using it." https://twitter.com/ioerror/status/398059565947699200 https://twitter.com/ioerror/status/398059565947699200

AlyssaRowan 12y ago
Yes - I concur that the "cryptanalytic breakthrough" GCHQ talked about the NSA having a few years ago was most probably some kind of a practical RC4 break, from context. (Schneier thought this one of the likely possibilities too.) It's used enough in TLS (especially at the time these documents were penned, as some advising on BEAST countermeasures actually encouraged people to use it, instead of switching to TLSv1.2 to use the strong AEAD ciphers - awfully convenient for them!) that if they have, say a known-plaintext-prefix attack of reasonable complexity that can be hardware-accelerated, that would be widely leveragable into very real breaks to them - and the structure of such a thing would look remarkably like what we see here. RC4 is about as good as such a simple crypter can be, but it really is too simple and not good enough now, and I strongly suspect it is already toast and way too late to safely phase out - which is why the IETF are hopefully about to publish an RFC strongly recommending it MUST NOT be used in TLS, at all. (Worse, even if RC4 isn't toast to everyone right now, an attacker who can put your data on ice for a few years - like just about every Nation State Adversary does - may very well make toast with it down the line and read all your data.) We don't have any second-preimages in MD5, yet; what's demonstrated are techniques for efficient collisons. They might, but collisions are easily enough for practical problems as many have publicly demonstrated. SHA-1 hasn't been publicly demonstrated with a collision yet, but it has all the same underlying problems as MD5 (and the original SHA), just to a lesser extent - I suspect that NSA can produce SHA-1 collisions with enough effort. Don't expect them to spend more effort than they need, however, to save money and avoid revealing capabilities where possible. Several attackers have happily leveraged simpler shortcuts - there's a piece of (probably South Korean) malware that has signing keys co-opted from hapless developers who've somehow been derping around with 512-bit RSA keys. I could break those, so that's completely ridiculous! By the way - do be on the look out for PGP signatures with 1024-bit DSA signing keys. There's a lot of them. Upgrade to at least 3072-bit RSA, I suggest (or Ed25519).

sneak 12y ago

> I think you're about right and it probably refers to matching public and private keys for CAs in SSL/TLS, looking up suitable intermediate CAs, for which they may have a few keys stashed away. Compromise of a CA's key does not permit decryption of traffic encrypted by server keys that use certificates (signatures) from those CAs. This is a common misconception. It would allow for issuing (signing) a rogue, second key that could then be used to silently active MITM a connection - but getting the CA's key does not give you the VPN server's key. (Remember, a certificate is just a signature by a CA over the hash of the VPN server's public key. The CA never sees the private key of the VPN server, nor is the CA's key used for anything other than signing.)

AlyssaRowan 12y ago
Yes, but they're man-on-the-side already, and they already have the QUANTUM set of attacks and similar for actively racing an MITM on any TCP/UDP/ESP/etc/IP connection they want - and if they have a CA trusted for the purpose by the relevant endpoint, they can safely man-in-the-middle TLS, IPSec, etc. That's what the diagram shows, essentially: the front end of that attack.