Monday, September 9, 2013

Subverting the IPSec Standards Process

John Gilmore (via Tim O’Reilly):

Every once in a while, someone not an NSA employee, but who had longstanding ties to NSA, would make a suggestion that reduced privacy or security, but which seemed to make sense when viewed by people who didn’t know much about crypto. For example, using the same IV (initialization vector) throughout a session, rather than making a new one for each packet. Or, retaining a way to for this encryption protocol to specify that no encryption is to be applied.

The resulting standard was incredibly complicated—so complex that every real cryptographer who tried to analyze it threw up their hands and said, “We can’t even begin to evaluate its security unless you simplify it radically”. […] That simplification never happened.

The IPSEC standards also mandated support for the “null” encryption option (plaintext hiding in supposedly-encrypted packets), for 56-bit Single DES, and for the use of a 768-bit Diffie-Hellman group, all of which are insecure and each of which renders the protocol subject to downgrade attacks.

1 Comment RSS · Twitter

[...] Link. Standards processes are easy to sabotage. I think Google did in some data standards, but this was a bigger kill. [...]

Leave a Comment