[backrow]

For those who might not be keeping up with tech@:

Kurt Knochner (who is not a developer) posted about his own audit of the IPSEC code; in response, Theo posted some more information on the situation.

At the moment my beliefs are somewhat along these lines:

1. NETSEC, as a company, was in that peculiar near-DC business of accepting contracts to do security and anti-security work from parts of the government.
2. For context: 1999-2001 was a period where lots of US govt departments pushed the boundaries, because crypto was moved from DOD to Commerce so that it could be exported "subject to some limits"; the result was that crypto use by private interests was set to explode, and thus many justifications, not just technologies, were being invented to let the US Govt continue wiretapping (they have always been addicted to it).
3. Gregory Perry did work at NETSEC, and interviewed and hired Jason just out of school; by the time Jason started working there Perry had been "evicted" from the company, for reasons unknown.
4. Jason did not work on cryptography specifically since he was mostly a device driver author, but did touch the ipsec layer because that layer does IPCOMP as well. Meaning he touched the data-flow sides of this code, not the algorithms.
5. After Jason left, Angelos (who had been working on the ipsec stack already for 4 years or so, for he was the ARCHITECT and primary developer of the IPSEC stack) accepted a contract at NETSEC and (while travelling around the world) wrote the crypto layer that permits our ipsec stack to hand-off requests to the drivers that Jason worked on. That crypto layer contained the half-assed insecure idea of half-IV that the US govt was pushing at that time. Soon after his contract was over this was ripped out. Soon after this the CBC oracle problem became known as well in published papers, and ipsec/crypto moved towards random IV generation (probably not viable before this, since we had lacked a high-quality speedy PRNG... arc4random). I do not believe that either of these two problems, or other problems not yet spotted, are a result of clear malice. So far the issues we are digging up are a function of the time in history.
6. Both Jason and Angelos wrote much code in many areas that we all rely on. Daily. Outside the ipsec stack. I forwarded the allegation which mentions them, but I will continue to find it hard to point my own fingers at them. Go read my original mail for points (a) - (c).
7. I believe that NETSEC was probably contracted to write backdoors as alleged.
8. If those were written, I don't believe they made it into our tree. They might have been deployed as their own product.
9. If such NETSEC projects exists, I don't know if Jason, Angelos or others knew or participated in such NETSEC projects.
10. If Jason and Angelos knew NETSEC was in that business, I wish they had told me. The project and I might have adjusted ourself to the situation in some way; don't know exactly how. With this view, I do not find Jason's mail to be fully transparent.
11. I am happy that people are taking the opportunity to audit an important part of the tree which many had assumed -- for far too long -- to be safe as it is.

> where would you start auditing the code? It's just too much.

Actually, it is a very small part of the tree. If we all do our part,
it will get better. It still won't be perfect. It is just too big. But
we've proven that if we start nibbling at a source tree looking for small
bugs or unclear things which need improvement, the results always eventually
pay off. So I can't suggest any specific place to start.

> Now, as I have started with it, I will continue to do so, at least
> with the crypto code and PRNG code.

After you sent out your mail, at least 10 people went and studied this
code. I've already found a small bug in a totally different side of
the random subsystem, and am looking at cleaning up a truly ugly function.

That is the best process we can hope for.

> > But looked at from the half-glass-full side, it is refreshing to see
> > people trying!
>
> :-)
>
> BTW: iTWire mentions, that two bugs have been found in the crypto
> code. Where can I find details on those bugs?
>
> http://www.itwire.com/opinion-and-an...e-audit-begins

These are the first two bugs which were found. The first one relates
to the CBC oracle problem mentioned earlier (it got fixed by angelos
in the software crypto stack, but the same problem was ignored in all
the drivers jason maintained. Neither Jason nor Angelos were working for
NETSEC at that time, so I think this was just an accident. Pretty serious
accident).

CVSROOT: /cvs
Module name: src
Changes by: mikeb@cvs.openbsd.org 2010/12/15 16:34:23

Modified files:
sys/arch/amd64/amd64: aesni.c via.c
sys/arch/i386/i386: via.c
sys/arch/i386/pci: glxsb.c
sys/dev/pci : hifn7751.c hifn7751var.h safe.c safevar.h
ubsec.c ubsecvar.h

Log message:
Bring CBC oracle attack countermeasure from r1.32 of cryptosoft.c to
the hardware crypto accelerator land. This fixes aes-ni, via xcrypt,
glxsb(4), hifn(4), safe(4) and ubsec(4) drivers.

Original commit message by angelos:

Don't keep the last blocksize-bytes of ciphertext for use as the next
plaintext's IV, in CBC mode. Use arc4random() to acquire fresh IVs per
message.

with and ok deraadt, ok markus, djm


CVSROOT: /cvs
Module name: src
Changes by: jsg@cvs.openbsd.org 2010/12/16 09:56:08

Modified files:
sys/crypto : cryptodev.h
lib/libssl/src/crypto/engine: hw_cryptodev.c

Log message:
move CRYPTO_VIAC3_MAX out of cryptodev.h and into the only
file it will be used from.

requested by/ok mikeb@


Other more recent commits have come out of this as well. Just go
look at the Changelog ..