Fascinating, accessible guide to cryptographic attacks, from brute-force to POODLE and beyond
Ben Herzog's Cryptographic Attacks: A Guide for the Perplexed from Check Point Research is one of the clearest, most useful guides to how cryptography fails that I've ever read.
While popular media likes to depict crypto as falling prey to brute-force attacks -- which offer narratively convenient countdown timers as the digital tumblers roll into place -- the actual attacks on crypto are way more interesting (and plausible) than making a lot of guesses very fast.
Herzog lays out how these attacks work, from frequency analysis to precomputation attacks to interpolation attacks to downgrade attacks to oracle attacks, and then gives specific examples of high-profile, real world defects in cryptosystems, including CRIME, POODLE and DROWN.
Understanding how crypto goes wrong -- the complex interplay of history, human error, foolishness, and unanticipated interactions -- is key to understanding computer security. This is an invaluable guide, and Herzog promises as sequel: "In the next blog post of this series, we'll talk about advanced attacks - such as meet-in-the-middle, differential cryptanalysis, and the birthday attack. We'll take a short foray into the land of side-channel attacks, and then we'll finally delve into the exquisite realm of attacks on public-key cryptography."
You might wonder who in their right mind would design a real-world system analogous to a "secure, unless you come in sideways" system, or a "secure, unless you insist otherwise" system, as described above. But much like the fictional bank would rather take the risk and retain its crypto-averse customers, systems in general often bow to requirements that are indifferent, or even overtly hostile, to security needs.
Exactly such a story surrounded the release of SSL protocol version 2 in the year 1995. The United States government had long since come to view cryptography as a weapon, best left out of the hands of geopolitical enemies and domestic threats. Pieces of code were approved on a case-by-case basis for leaving the US, often conditional on the algorithm being weakened deliberately. Netscape, then the main vendor of web browsers, was able to obtain a permit for SSLv2 (and by extension, Netscape Navigator) to support a vulnerable-by-design RSA with a key length of 512 bits (and similarly 40 bits for RC4).
By the turn of the millennium, regulations had been relaxed and access to state-of-the-art encryption became widely available. Still, clients and servers supported export-grade crypto for years, due to the same inertia that preserves support for any legacy system. Clients figured they might encounter a server which doesn't support anything else, so they hung on to optional support for it, as a last resort. Servers did the same. Of course, SSL protocol dictates that clients and servers should never use a weak protocol when a better one is available - but then again, neither should Tressler and his bank.
Cryptographic Attacks: A Guide for the Perplexed [Ben Herzog/Check Point Research]
(via Four Short Links)
