---------- Forwarded message ----------
From: Theo de Raadt <[email protected]>
Date: Wed, Dec 22, 2010 at 1:04 AM
Subject: Re: Allegations regarding OpenBSD IPSEC
To: Kurt Knochner <[email protected]>
Cc: [email protected]
> without a 'hint' (true or fake),
Well, the allegations came without any facts pointing at specific code.
At the moment my beliefs are somewhat along these lines:
(a) 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.
(b) 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).
(c) 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.
(d) 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.
(e) 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.
(f) 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).
(g) I believe that NETSEC was probably contracted to write backdoors
as alleged.
(h) If those were written, I don't believe they made it into our
tree. They might have been deployed as their own product.
(i) If such NETSEC projects exists, I don't know if Jason, Angelos or
others knew or participated in such NETSEC projects.
(j) 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.
(k) 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-analysis/open-sauce/43995-openbsd-backdoor-claims-code-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: [email protected] 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: [email protected] 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 ..
_______________________________________________
bsd-india mailing list
[email protected]
http://www.bsd-india.org/mailman/listinfo/bsd-india
