
Speculation on "BULLRUN" - danieldk
http://www.mail-archive.com/cryptography@metzdowd.com/msg12325.html
======
tytso
I was chair of the IPSEC working group at the IETF, and I think I know what
John Gilmore was referring to with respect to the question of the
Initialization Vector. The person who expressed a concern with a per-packet IV
(which by the way had indeed done a lot of consulting for the NSA; nice guy,
though) didn't like the idea because it's too easy for people to screw up and
use an incrementing counter for the IV. This is bad, because if the first
couple of bytes in the packet are mostly fixed (becuase you are encapsulating
a TCP or UDP packet, for example), the resulting plaintext in the first block
of these packets will have a very low hamming distance between them, and this
can enable certain cryptoanalytic attacks (i.e., such as differential
cryptoanalysis). He was not advocating using the same IV across the entire
session, in the sense that we would use the same IV for each packet (which
would have been a cryptographic disaster), but rather we use the previous
packet's cipherblock as the IV for the next packet (i.e., just keep chaining
the cipherblocks).

As is often the case in standards bodies when there is disagreement, neither
side won, and we left things unspecified. The RFC doesn't constrain how the IV
should be chosen, so you can initialize the IV either way.

There was language indicating that the IV should never be the same, as well as
an additional method of generating the IV, by using a Linear Feedback Shift
Register (LFSR), which also will eliminate the potential problem of related
plaintext being sent to the crypto algorithm. So although the RFC doesn't say
this, I would recommend either the use of a LFSR, or the last cipherblock in
the previous packet encrypted using that key, and to avoid using a simple
counter in your IPSEC implementation for the Initialization Vector (IV) in
each packet.

So to be fair, in this particular case, the person with "known associations
with the NSA" was actually trying to make things better, although he did feel
constrained in not explaining all of his reasons in the open wg meeting. Which
no doubt tripped Gilmore's paranoia, and I can't blame him for that either.

~~~
pkl2
> which by the way had indeed done a lot of consulting for the NSA; nice guy,
> though

Brings up an interesting point. Going forward should it be disqualifying to be
currently working for the NSA to be on one of these committees? To have
formerly worked for them? To done a lot of consulting? To have done any
consulting? To have ever had a security clearance?

Witchhunts have a deservedly negative connotation, but what if you are
actually surrounded by witches?

~~~
tytso
The hard part is that the NSA has two missions --- cracking foreign crypto,
and protecting US crypto. When an NSA employee speaks, we will have no idea
whether he or she is speaking with the "protect US crypto" hat on, or the
"SIGINT enablement" hat on.

I'd say the more important thing is that we not trust any one single person
(or corporation). Everything needs to be open, and everything needs to be
studied and verified by independent authorities.

This also applies to how you implement your security. You want two person
controls for everything, and separation of roles --- those people who can
bypass file access controls had better not also be able to wipe log records.
The NSA is relearning that lesson the hard way as they try to figure out what
records Snowden might have leaked --- apparently Snowden had the ability to
impersonate other users, as well as wipe the log records which were
_hopefully_ being made when person A uses an "su"-like command to impersonate
person B.

After all, when someone stands up to give a suggestion at a standards meeting,
or when someone goes through the hiring process to be one of your sysadmins,
they won't be wearing a sign saying, "I do a huge amount of consultant work
with the NSA and I have Top Secret/SCI/POLY clearance". Neither will job
applicants have signs saying, "I'm getting paid by the Chinese MSS", or "I'm
here to steal your SSL private keys".

~~~
NelsonMinar
Unfortunately the NSA has irrevocably damaged their ability to fulfill the
"protect US crypto" mission.

Thanks for all the details on the process tytso, not to mention your work for
all these years.

------
ChuckMcM
The author, John Gilmore, shared these sorts of stories with me when I was
complaining about the NSA intervention on the crypto work I was doing on Java.
Sun said I had to have them sign off that we were 'compliant' (which means
they would tell the State Department to sign off on our export license) and
that was a total PITA. At the time I was working on an end to end loadable
strong encryption package [1].

[1]
[http://patents.justia.com/patent/6546487](http://patents.justia.com/patent/6546487)
\- if that looks complex and twisted, it is. The original version wasn't
"compliant."

~~~
ewoodrich
The Sun patent appears to be listed on Oct 19, 1999. Out of curiosity, when
did the compliance discussions with the NSA occur?

(I'm quite interested in '90s crypto/political interaction, and had thought
that by '99, the NSA and State/Export restrictions had been mostly lifted, but
I'd love to learn more from the inside).

~~~
ChuckMcM
I was building a strong crypto package for Java in '93-'94\. It was part of a
capabilities system for Java which would have had the JVM unable to
decrypt/instantiate methods in classes for which capabilities had not been
granted. I modelled it on the Joule system which Mark Miller had worked on
earlier. In late 1991/ early 1992 Sun had engaged RSA Data Security for a
license to use their asymmetric crypto system we know as the RSA algorithm. I
had started that because I was building a high trust authentication system for
our name service (NIS+) and I really wanted to be able to pass around public
keys for servers that a client trusted to be legitimate. When I started
working on Java security in 1993 I sought to use some of those same techniques
in creating a way for the JVM to "load" a cryptographic class which it could
trust, and the class could validate that the JVM loadinging was trustable as
well (avoiding MITM attacks). Since I had already been engaged with the issues
of shipping crypto code in ONC-RPC, I knew it would be an issue to release
source code that implemented arbitrarily strong RSA so when it came up, the
NSA came out to talk to us. Our "rep" was a woman (and I'm not making this up)
named Cindie Spies. She understood what I wanted to do but wasn't particularly
keen on us doing it. We went back and forth with me sending code to her, and
her sending back suggestions. It was a tedious process and ultimately moot
since the capabilities version of Java never actually shipped.

~~~
ewoodrich
Fascinating stuff. The "Cindie Spies" negotiations (and not just the spot-on
name) provide good context for what it would be like developing crypto in a
tumultuous, formative period for our current security technology/regulations.

------
obituary_latte
-1 on the title change. "Linux ipsec" vs "bullrun"? Really? Someone just flexing?

------
zeteo
I may be digressing but the symbolism they chose for these names is rather
spooky. The US program is named after the first battle in the American Civil
War, and its UK correspondent after the first in the English Civil War.

~~~
regularfry
How are project or operation names chosen? I'd always assumed they had to be
randomly selected so knowing the name wouldn't give you any clue (even
accidentally) to the content.

~~~
dsl
You are correct, they are randomly chosen. See my previous comment:
[https://news.ycombinator.com/item?id=5841740](https://news.ycombinator.com/item?id=5841740)

------
rdl
It does seem a pretty fair that the IPSEC process, and IPSEC in general, has
been an utter clusterfuck. Raccoon, etc. are horrible (really anything with
IKE). Free S/WAN had its own problems, but at least Hugh was fairly
reasonable. That doesn't necessarily point to NSA, though.

(most of this criticism applies to DNSSEC too)

~~~
tytso
I can't _prove_ that there were people who was purposely delaying consensus to
give their product more time to make it to market. But there were those who
had their suspicions...

------
yuhong
Ah, crypto back in the late 1990s, the period when NSA was trying to restrict
export of encryption stronger than 40-bit. The funny thing is that 56-bit
crypto is still in use in the form of PPTP with MS-CHAPv2. What is even worse
is they thought it was non-exportable 128-bit encryption at the time, the
actual 40-bit and 56-bit versions are even worse.

------
riobard
So PPTP is insecure, and IPSec is fundamentally broken… How about OpenVPN? Is
that compromised too?

~~~
ghshephard
IPSec is not fundamentally broken, it's just needlessly complex.

~~~
cpeterso
Is there a simple (and auditable) subset of IPSec that could still compatible
with IPSec clients using a full/complex stack?

~~~
wiml
As I understand it most of the terribleness is in the key agreement stuff; the
actual packet processing is a little ugly but is practical. So you could in
theory set up (and regularly update) SAs manually with setkey(8), instead of
having racoon do it. For a small network you could presumably lash together
some cronjobs to keep this working. Would that be as secure as IKEv2 as
actually implemented? I dunno :)

------
tjaerv
Upstream source:
[http://www.metzdowd.com/pipermail/cryptography/2013-Septembe...](http://www.metzdowd.com/pipermail/cryptography/2013-September/017218.html)

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

Who knows, maybe he was paranoid of others because he was incompetent. He
could look at your code and its complexity would astound him, therefore you're
trying to confuse him and mislead him into accepting your code without knowing
what it was doing. He may have already known that there were NSA employees in
kernel development.

------
Zigurd
It will be interesting to see if the NSA can still push their way into
standards bodies. I wonder if similar techniques were used on WebRTC security.

------
eps
I vaguely remember some incident back in early '00 when they found some
"interesting" patch in FreeS/WAN code added by someone who was either
consulting or tied otherwise with NSA. There was a flurry of discussion on a
mailing list followed, I think, by the patch reversal.

Does anyone know what I am referring to?

------
jacoblyles
This sounds like a good time to start doing crypto research outside of the
United States.

------
guelo
Oh well. Is OpenVPN still considered solid?

------
JulianMorrison
I think someone needs to set up a fresh committee, and fix IPSEC, and
deprecate the existing version.

------
fosap
IPSec is a kind of broken, what happend to CurveCP btw?

