

On the Cryptography mailing list, John Gilmore (co-founder of pioneering ISP The Little Garden and the Electronic Frontier Foundation; early Sun employee; cypherpunk; significant contributor to GNU/Linux and its crypto suite; and all-round Internet superhero) describes his interactions with the NSA and several obvious NSA stooges on the IPSEC standardization working groups at the Internet Engineering Task Force. It's an anatomy of how the NSA worked to undermine and sabotage important security standards. For example, "NSA employees

explicitly lied to standards committees, such as that for cellphone

encryption, telling them that if they merely debated an

actually-secure protocol, they would be violating the export control

laws unless they excluded all foreigners from the room (in an

international standards committee!)."

* NSA employees participted throughout, and occupied leadership roles

in the committee and among the editors of the documents

* 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". See for example:

https://www.schneier.com/paper-ipsec.html

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.

* The protocol had major deployment problems, largely resulting from

changing the maximum segment size that could be passed through an

IPSEC tunnel between end-nodes that did not know anything about

IPSEC. This made it unusable as a "drop-in" privacy improvement.

* Our team (FreeS/WAN) built the Linux implementation of IPSEC, but

at least while I was involved in it, the packet processing code

never became a default part of the Linux kernel, because of

bullheadedness in the maintainer who managed that part of the

kernel. Instead he built a half-baked implementation that never

worked. I have no idea whether that bullheadedness was natural,

or was enhanced or inspired by NSA or its stooges.