What Less-Subtle Covert Influence Looks Like (and more NSA)

Famous privacy fanatic John Gilmore dissects the tactics the NSA used to corrupt and poison the IPSEC standard. Things like: – Putting people with open ties to the agency in leadership positions
– Using people with less-obvious ties to make “sure, that makes sense” suggestions that nevertheless reduced security
– Ensuring the standard was overly complicated… so complicated that outside cryptographers couldn’t possibly analyze it – Engineering the standard to be very hard to implement
– Maybe “encouraging” people to be bull-headed about not letting it become part of the Linux kernel

Also, you’ve heard of kicking a wasp’s nest? The BULLRUN/EDGEHILL revelations whacked the computer-security wasp’s nest with a baseball bat. Several times. While shouting slurs about the occupants’ genetic predispositions to mental retardation.

This may, if the computer security community coppers on to human-intelligence methods of influence, turn into the “Internet immune system” asserting itself. In the short run, it means there’s HOLY CRAP TONS OF STUFF GOING ON. Viennese villas getting surrounded by “fans of local architecture.” Helicopters pulling pre-election stunts over Germany’s Capital City of Crime. Etc.

Here’s some of the more insightful highlights…

So, I don’t go out of my way to use encryption. Some of you have, in the last year or two, asked for my PGP key and gotten told, “I don’t have one.”

The most obvious reason for this is that I’m not a cryptographer, and I’m not going to trust — or encourage others to trust — something neither of us really understands.

But here’s another, critically important reason. “In security, the worst case—the thing you most want to avoid—is thinking you are secure when you’re not. And that’s exactly what the NSA seems to be trying to perpetuate.” https://freedom-to-tinker.com/blog/felten/nsa-apparently-undermining-standards-security-confidence/

Schneier has an excellent piece summing up the “generation gap” aspect of SnowdenLeaks. He brings together a number of points others have raised and adds a sense of spot-on perspective. (Perhaps, the cynic in me thinks, the kind of perspective only a former Chekist would have. If so, here that’s a good thing.) Most remarkable is the insight that, perhaps despite everything, maybe Facialbook wasn’t all bad after all: “[The new generations have] overshared in the most compromising ways —
and they have got through it. It is a tougher sell convincing this crowd that government secrecy trumps the public’s right to know.” https://www.schneier.com/blog/archives/2013/09/government_secr_1.html


“Speaking as someone who followed the IPSEC IETF standards committee pretty closely, while leading a group that tried to implement it and make so usable that it would be used by default throughout the Internet, I noticed some things:

* 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:


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.”

%d bloggers like this: