On Tue, Dec 14, 2010 at 5:54 PM, Theo de Raadt dera...@cvs.openbsd.org
wrote:
I have received a mail regarding the early development of the OpenBSD
IPSEC stack. B It is alleged that some ex-developers (and the company
they worked for) accepted US government money to put backdoors into
our
On Dec 31, 2010, at 0:57, Otto Moerbeek o...@drijf.net wrote:
On Thu, Dec 30, 2010 at 08:41:10PM -0700, Kjell Wooding wrote:
Note that this assumes that there is no backdoor in random(6) (or
arc4random_uniform, which it calls) designed to prevent the source file
with the backdoor from being
2010/12/21 Kurt Knochner cdowl...@googlemail.com
2010/12/21 Theo de Raadt dera...@cvs.openbsd.org
regarding the allegations about a backdoor beeing planted into OpenBSD,
I
did a code review myself [...]
It is unfortunate that it required an allegation of this sort for
people to get
On Thu, Dec 30, 2010 at 09:38:41AM +0100, Janne Johansson wrote:
without a 'hint' (true or fake), where would you start auditing the
code? It's just too much.
Ted Unangst already solved that for all the potential lookers:
Quote from http://marc.info/?l=openbsd-miscm=124413533913404w=2
Note that this assumes that there is no backdoor in random(6) (or
arc4random_uniform, which it calls) designed to prevent the source file
with the backdoor from being selected with the above command.
That's true. I would submit a patch, but it would require every developer to
carry around a
On Thu, Dec 30, 2010 at 08:41:10PM -0700, Kjell Wooding wrote:
Note that this assumes that there is no backdoor in random(6) (or
arc4random_uniform, which it calls) designed to prevent the source file
with the backdoor from being selected with the above command.
That's true. I would
Theo de Raadt deraadt at cvs.openbsd.org writes:
regarding the allegations about a backdoor beeing planted into OpenBSD, I
did a code review myself [...]
By the way...
It is unfortunate that it required an allegation of this sort for
people to get to the point where they stop blindly
On Fri, Dec 24, 2010 at 07:27:02PM +, martin tarb wrote:
Theo de Raadt deraadt at cvs.openbsd.org writes:
regarding the allegations about a backdoor beeing planted into OpenBSD, I
did a code review myself [...]
By the way...
It is unfortunate that it required an
Otto Moerbeek otto at drijf.net writes:
Please also check what djm@ wrote in one of the first replies to Theo
original mail:
http://marc.info/?l=openbsd-techm=129237675106730w=2
-Otto
Yep, I did see that one, though that one does focus on (intentional) bugs in the
the main crypto
On Fri, Dec 24, 2010 at 07:53:52PM +, martin tarb wrote:
Otto Moerbeek otto at drijf.net writes:
Please also check what djm@ wrote in one of the first replies to Theo
original mail:
http://marc.info/?l=openbsd-techm=129237675106730w=2
-Otto
Yep, I did see that one,
Otto Moerbeek otto at drijf.net writes:
Huh, I quote:
So a subverted developer would probably need to work on the network stack.
I can think of a few obvious ways that they could leak plaintext or key
material:
and then Damien gives a few examples of how that could be accomplished.
On 12/23/2010 06:39 AM, Marsh Ray wrote:
On 12/22/2010 03:49 PM, Clint Pachl wrote:
Salvador Fandiqo wrote:
Could a random seed be patched into the kernel image at installation
time?
Admittedly this is not entropy, this is a just secret key and anyone
with access to the machine would be able
Salvador Fandiqo wrote:
On 12/23/2010 06:39 AM, Marsh Ray wrote:
On 12/22/2010 03:49 PM, Clint Pachl wrote:
Salvador Fandiqo wrote:
Could a random seed be patched into the kernel image at installation
time?
Admittedly this is not entropy, this is a just secret key and anyone
with access to
On 2010-12-23 09:44, Clint Pachl wrote:
Salvador Fandiqo wrote:
On 12/23/2010 06:39 AM, Marsh Ray wrote:
On 12/22/2010 03:49 PM, Clint Pachl wrote:
Salvador Fandiqo wrote:
Could a random seed be patched into the kernel image at installation
time?
Admittedly this is not entropy, this is a
On Thu, Dec 23, 2010 at 10:43:49AM +0100, olli hauer wrote:
On 2010-12-23 09:44, Clint Pachl wrote:
Salvador Fandiqo wrote:
On 12/23/2010 06:39 AM, Marsh Ray wrote:
On 12/22/2010 03:49 PM, Clint Pachl wrote:
Salvador Fandiqo wrote:
Could a random seed be patched into the kernel image
2010/12/23 Clint Pachl pa...@ecentryx.com:
The last time I installed FreeBSD about 5 years ago, it asked me to pound on
the keyboard for like 60 seconds during installation (or at first boot,
can't remember) in order to build up some randomness. I wonder what kind
of entropy that provided?
On 12/23/2010 04:39 AM, Kurt Knochner wrote:
2010/12/22 Marsh Rayma...@extendedsubset.com:
In any case, generic statistical tests might detect really
horrible brokenness but they're are not the thing to certify CSRNGs
with.
Really? So, how do you certify the IMPLEMENTATION (bold, not
How much did you get?
Is it safe for the boot process to generate keys now?
If you can only read.
On Tue, Dec 21, 2010 at 07:45:09PM +0100, Kurt Knochner wrote:
The in libc the rc4 state is only initialized once at the first call of
arc4_stir() and then there are consecutive calls to arc4_addrandom() which
is the equivalent of rc4_crypt(). So, there is a difference in the
implementation.
On Wed, Dec 22, 2010 at 08:28:51AM +0300, Vadim Zhukov wrote:
On 21 December 2010 G. 22:59:22 Theo de Raadt wrote:
Go look at the function random_seed() in /usr/src/etc/rc
And it's definitely worth looking... Patch below.
Believe it or not, but this diff has been circling around developers
On 12/22/2010 01:46 AM, Theo de Raadt wrote:
2010/12/21 Theo de Raadtdera...@cvs.openbsd.org:
HANG ON.
Go look at the function random_seed() in /usr/src/etc/rc
Then look at when it is called.
so, the current state of the PRNG will be preserved during reboots.
That statement is false.
2010/12/22 Theo de Raadt dera...@cvs.openbsd.org:
Go ahead, do a FIPS check on it. You will be doing a FIPS check on
4096 bytes here, then a gap of unknown length, then 4096 bytes here,
then a gap of unknown length, then 4096 bytes here, then a gap of
unknown length,
that's true, if one
On Wed, Dec 22, 2010 at 04:29:59PM +0100, Kurt Knochner wrote:
2010/12/22 Theo de Raadt dera...@cvs.openbsd.org:
Go ahead, do a FIPS check on it. You will be doing a FIPS check on
4096 bytes here, then a gap of unknown length, then 4096 bytes here,
then a gap of unknown length, then 4096
-Original Message-
From: owner-t...@openbsd.org [mailto:owner-t...@openbsd.org] On Behalf Of
Joachim Schipper
Subject: Re: Allegations regarding OpenBSD IPSEC
On Wed, Dec 22, 2010 at 04:29:59PM +0100, Kurt Knochner wrote:
Do you have a hint, how I could emit the random values from
On 12/22/2010 09:29 AM, Kurt Knochner wrote:
Do you have a hint, how I could emit the random values from arc4random
in a clever way? I thought of using an internal buffer and accessing
that through sysctl or another device, e.g. /dev/randstream.
You should definitely check out this page if
Salvador Fandiqo wrote:
On 12/22/2010 01:46 AM, Theo de Raadt wrote:
2010/12/21 Theo de Raadtdera...@cvs.openbsd.org:
HANG ON.
Go look at the function random_seed() in /usr/src/etc/rc
Then look at when it is called.
so, the current state of the PRNG will be preserved during reboots.
That
On 12/22/2010 03:49 PM, Clint Pachl wrote:
Salvador Fandiqo wrote:
Could a random seed be patched into the kernel image at installation
time?
Admittedly this is not entropy, this is a just secret key and anyone
with access to the machine would be able to read it,
How is it different than any
Hi,
upfront: sorry for double posting!! Some people told me, that I should send
my findings directly to the list instead of a link. Sorry if I violated the
netiquette on the list!
So, here we go again (text from the forum where I posted it).
regarding the allegations about a backdoor beeing
On Tue, Dec 21, 2010 at 05:59:33PM +0100, Kurt Knochner wrote:
Hi,
upfront: sorry for double posting!! Some people told me, that I should send
my findings directly to the list instead of a link. Sorry if I violated the
netiquette on the list!
So, here we go again (text from the forum
On Tue, Dec 21, 2010 at 11:59 AM, Kurt Knochner cdowl...@googlemail.com
wrote:
This initializes the RC4 context with some random data, gathered by system
enthropy, that is mainly done by get_random_bytes().
== Bug #1
HOWEVER: Have a look at the buffer that's beeing used as a seed for the RC4
2010/12/21 Theo de Raadt dera...@cvs.openbsd.org
regarding the allegations about a backdoor beeing planted into OpenBSD, I
did a code review myself [...]
By the way...
It is unfortunate that it required an allegation of this sort for
people to get to the point where they stop blindly
On Tue, Dec 21, 2010 at 07:45:09PM +0100, Kurt Knochner wrote:
2010/12/21 Otto Moerbeek o...@drijf.net
So, there is a lot of effort in get_random_bytes() to get real random
data
for the buffer and then the value of nanotime() is prepended to the
buffer?
That does not look right.
2010/12/21 Kurt Knochner cdowl...@googlemail.com:
2.) don't forget to check if sizeof(ts) = sizeof(buf), otherwise you
will create a buffer overrun.
O.K. this one is not THAT critical, as buf is defined locally as
u_int8_t buf[256]; However I tend to make those superflous checks in
my code,
On Tue, Dec 21, 2010 at 08:36:35PM +0100, Kurt Knochner wrote:
2010/12/21 Otto Moerbeek o...@drijf.net:
get_random_bytes() calls extract_entropy() which is a a loop around nbytes,
thus get_random_bytes() will most certainly deliver enough entropy.
extract_entropy() does not guarantee the
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
2010/12/21 Otto Moerbeek o...@drijf.net:
Yes, predictable, but different for each call.
hm... predictable is not a good term in the domain of a PRNG.
However the time value will not be used by itself. It is part of an
encrypt operation with itself + buf and a previous RC4 state, at least
after
No. Unless you know something I don't, This is voodoo. To do it once might
add something, but to do it multiple times, with strongly correlated inputs
seems potentially dangerous. Especially since you are XORing them. Does
anyone elsewhere in the cryptographic world do something like this?
On Tue, Dec 21, 2010 at 2:54 PM, Kurt Knochner cdowl...@googlemail.com wrote:
2.) Repeat that procedure a few times, i.e. reboot, ipsec, store,
reboot, ipsec, store, etc.
3.) Take all those pseudo random value sequences and feed them into
the NIST test suite for random values (chi-square,
On Tue, Dec 21, 2010 at 01:33:46PM -0700, Theo de Raadt wrote:
- Instead of XOR'ing the results of nanotime into the buffer, XOR
MD5(time), MD5(time + 1ns), MD5(time + 2ns) etc into the buffer. This
does not increase entropy, but having more-or-less uncorrelated data
in the entire
On Tue, Dec 21, 2010 at 3:04 PM, Joachim Schipper
joac...@joachimschipper.nl wrote:
On Tue, Dec 21, 2010 at 08:27:49PM +0100, Kurt Knochner wrote:
2010/12/21 Joachim Schipper joac...@joachimschipper.nl:
+ get_random_bytes(buf, sizeof(buf));
+ nanotime(ts);
+ for (i = 0; i
It *seems harder* (but I'm not an expert on this kind of thing!) to
predict the first couple of rounds if nanotime_noise is hashed (which
means that you have to re-do the complete calculation for each possible
nanotime_noise, which may not necessarily be the case above), and if
this hashing
This was based on the following intuition, which has very little to do
with hashing at all:
It *seems harder* (but I'm not an expert on this kind of thing!)
Again, though, this is just intuition,
.
Then no offense Jochim - stop suggesting it.. intuition like this is
what
On Tue, Dec 21, 2010 at 01:33:46PM -0700, Theo de Raadt wrote:
I do not understand what hashing principle you are basing this on.
On closer reflection, neither do I (MD5 in CTR mode? Cute, but not
necessarily a good idea). Can we just pretend I never sent that message?
Joachim
On Tue, Dec 21, 2010 at 12:34:54PM -0700, Theo de Raadt wrote:
[...]
Other more recent commits have come out of this as well. Just go
look at the Changelog ..
we're a bit late on the changelog right now, it stops on 5th of
december, gonna work on it very soon, sorry for the delay.
2010/12/21 Ted Unangst ted.unan...@gmail.com:
On Tue, Dec 21, 2010 at 2:54 PM, Kurt Knochner cdowl...@googlemail.com
wrote:
2.) Repeat that procedure a few times, i.e. reboot, ipsec, store,
reboot, ipsec, store, etc.
3.) Take all those pseudo random value sequences and feed them into
the
On Tue, Dec 21, 2010 at 4:00 PM, Joachim Schipper
joac...@joachimschipper.nl wrote:
If our RC4 state is nanotime_noiseknown, an attacker may be able to
predict *most* of the RC4 state through the first couple of rounds
(until nanotime_noise sufficiently interferes with the known state).
It
On Tue, Dec 21, 2010 at 01:24:55PM -0700, Kjell Wooding wrote:
MD5(time), MD5(time + 1ns), MD5(time + 2ns) etc into the buffer. This
does not increase entropy, but having more-or-less uncorrelated data
in the entire buffer should make attacks more difficult.
No. Unless you know something I
On Tue, Dec 21, 2010 at 2:30 PM, Kurt Knochner cdowl...@googlemail.comwrote:
yes, that's true. However, it's just a starting point. Do we currently
know that they have a good distribution? Is there any documented test
for the quality of the PRNG?
Sam from FreeBSD imported my rng tester and
2010/12/21 Theo de Raadt dera...@cvs.openbsd.org:
HANG ON.
Go look at the function random_seed() in /usr/src/etc/rc
Then look at when it is called.
so, the current state of the PRNG will be preserved during reboots.
That statement is false.
Good.
No. You misread the code.
That
On Tue, Dec 21, 2010 at 4:30 PM, Kurt Knochner cdowl...@googlemail.com
wrote:
yes, that's true. However, it's just a starting point. Do we currently
know that they have a good distribution? Is there any documented test
for the quality of the PRNG?
You can analyze the numbers coming out
2010/12/21 Kurt Knochner cdowl...@googlemail.com:
instead of just prepending it. MD5 and the like does not seem to be
necessary, as buf will allways contain some good random data.
I wanted to say: get_random_bytes() will allways return enough good
random values.
That is completely
Is there any documented test for the quality of the PRNG?
Are you talking about our use of MD5, or our use of RC4?
If you are talking about our RC4, then there is; I will put it this
way: If our use of RC4 in this exactly-how-a-stream-cipher-works way
is bad, then every other use on this planet
2010/12/22 Theo de Raadt dera...@cvs.openbsd.org:
Is there any documented test for the quality of the PRNG?
Are you talking about our use of MD5, or our use of RC4?
RC4.
If you are talking about our RC4, then there is; I will put it this
way: If our use of RC4 in this
2010/12/22 Theo de Raadt dera...@cvs.openbsd.org:
2010/12/21 Kurt Knochner cdowl...@googlemail.com:
instead of just prepending it. MD5 and the like does not seem to be
necessary, as buf will allways contain some good random data.
I wanted to say: get_random_bytes() will allways return
2010/12/22 Theo de Raadt dera...@cvs.openbsd.org:
12 to 16 bytes of kind-of-known but not really known data are mixed with
256 - (12 to 16) bytes of data to from the initial state of RC4, which is
then filtered by dropping the first 256 or 256*4 bytes of data as written
in the best paper that
.. steam ciphers is bad ...
Steam has much more entropy than a pseudo-number generator, in which
case our implementation is obsolete.
-Matt
2010/12/22 Theo de Raadt dera...@cvs.openbsd.org:
so, the current state of the PRNG will be preserved during reboots.
That statement is false.
you're right. As you posted in the other thread, the output of the
PRNG is saved during shutdown and that file is loaded as entropy data
during
Where do we invent entropy from when the kernel has only
been running for 0.01 of a second?
O.K. where do you need ramdom bytes during that state of the kernel?
All locations where arc4random* is called in the kernel are these:
[list of 16]
Unfortunately it looks like you missed a
2010/12/22 Theo de Raadt dera...@cvs.openbsd.org:
Where do we invent entropy from when the kernel has only
been running for 0.01 of a second?
O.K. where do you need ramdom bytes during that state of the kernel?
All locations where arc4random* is called in the kernel are these:
[list of
On Wed, Dec 22, 2010 at 08:28:51AM +0300, Vadim Zhukov wrote:
# if there's no /var/db/host.random, make one through /dev/urandom
^
if [ ! -f /var/db/host.random ]; then
- dd if=/dev/urandom of=/var/db/host.random bs=1024
On Thu, Dec 16, 2010 at 3:30 PM, Marc Espie es...@nerim.net wrote:
I'm not going to comment on the mail itself, but I've seen a lot of
incredibly
dubious articles on the net over the last few days.
- use your brains, people. Just because a guy does say so doesn't mean
there's
a backdoor. B
Does anyone know if there was an ultimate outcome to the investigation
of side channels supposedly put into DSA by the NSA?
On Thu, Dec 16, 2010 at 3:30 PM, Marc Espie es...@nerim.net wrote:
I'm not going to comment on the mail itself, but I've seen a lot of
incredibly
dubious articles on the net over the last few days.
- use your brains, people. Just because a guy does say so doesn't mean
there's
a
On Fri, Dec 17, 2010 at 08:59:13AM -0700, Theo de Raadt wrote:
This is not to point finger at Theo for creating all this commotion, of
course;
this commotion can, however, be, an unintended accident, but the fact that
it came from Theo gave it a lot of credibility.
Whoa, wait a second
On Fri, Dec 17, 2010 at 7:59 AM, Theo de Raadt dera...@cvs.openbsd.org
wrote:
[skipped]
I have to say that Perry here is credited with one thing he actually did
not
do -- publish this to the world. There has been talk of alterior motives
here,
but for any of these motives, Perry had to
On Fri, Dec 17, 2010 at 7:59 AM, Theo de Raadt dera...@cvs.openbsd.org wr=
ote:
[skipped]
I have to say that Perry here is credited with one thing he actually di=
d not
do -- publish this to the world. There has been talk of alterior motive=
s here,
but for any of these motives,
Theo,
this thread is DEAD. Drop it.
No one believes in backdoors planted into OpenBSD.
I se commits - you dig all over the place.
If backdoor existed, then it is gone cause of this digging.
Without proof its just a plain BS.
P.S.
I lost my interest for a while ago now.
On Dec 17, 2010, at
I agree with Marc - it's hopeless We live in a world where spin is
king. Anything you say can and will be twisted against you.
On 12/17/10 9:39 AM, Marc Espie wrote:
On Fri, Dec 17, 2010 at 08:59:13AM -0700, Theo de Raadt wrote:
This is not to point finger at Theo for creating all this
On Fri, Dec 17, 2010 at 11:39 PM, Pawel Veselov pawel.vese...@gmail.com wrote:
Whoa, wait a second here. B If you think I gave it credibility, you
need to go back and read my words again. B I called it an allegation,
and I stick with that. B I was extremely careful with my words, and you
On Wed, Dec 15, 2010 at 07:04:27PM +, Kevin Chadwick wrote:
Jason L. Wright ja...@thought.net wrote:
I cannot fathom his motivation for writing such falsehood
The real work on OCF did not begin in earnest until February 2000.
I can't see how this gives you credibility but maybe the
I'm not going to comment on the mail itself, but I've seen a lot of incredibly
dubious articles on the net over the last few days.
- use your brains, people. Just because a guy does say so doesn't mean there's
a backdoor. Ever heard about FUD ?
- of course OpenBSD is going to check. Geeez!!
I about talked myself out of believing that this happened after explaining
this to a cow-orker today. They were quite surprised i'd buy into something
this speculative and far fetched at all. After listening to him generalize
it back to me it seems even sillier.
Brandon
On Dec 16, 2010 6:34 PM,
On Fri, 17 Dec 2010 00:30:27 +0100, Marc Espie wrote:
if you read french, go check
http://www.macgeneration.com/news/voir/180982/un-systeme-espion-du-fbi-dans-openbsd
and be amazed at how clueless those writers are.
Gee, even the google page translation makes it clearer than my rusty
frangais
On Thu, Dec 16, 2010 at 4:47 AM, Joachim Schipper
joac...@joachimschipper.nl wrote:
On Wed, Dec 15, 2010 at 07:04:27PM +, Kevin Chadwick wrote:
Jason L. Wright ja...@thought.net wrote:
I cannot fathom his motivation for writing such falsehood
The real work on OCF did not begin in earnest
On Friday, 17 December 2010, (private) HKS hks.priv...@gmail.com wrote:
On Thu, Dec 16, 2010 at 4:47 AM, Joachim Schipper
joac...@joachimschipper.nl wrote:
On Wed, Dec 15, 2010 at 07:04:27PM +, Kevin Chadwick wrote:
Jason L. Wright ja...@thought.net wrote:
I cannot fathom his motivation
I about talked myself out of believing that this happened after explaining
this to a cow-orker today. They were quite surprised i'd buy into something
this speculative and far fetched at all. After listening to him generalize
it back to me it seems even sillier.
I think you are totally
On Wed, 15 Dec 2010 07:48:46 +0100
Otto Moerbeek o...@drijf.net wrote:
On Tue, Dec 14, 2010 at 10:26:44PM -0500, Brandon Mercer wrote:
If this type of thing really did happen and this actually is going
on something as simple as systrace or dtrace would have found it
correct? Surely folks
Unless of course someone was capturing the entire stream as it traversed the
internet and then simply extracted the keys later on.
On Dec 15, 2010 5:22 AM, Gregory Edigarov g...@bestnet.kharkov.ua wrote:
On Wed, 15 Dec 2010 07:48:46 +0100
Otto Moerbeek o...@drijf.net wrote:
On Tue, Dec 14,
On 2010/12/15 12:20, Gregory Edigarov wrote:
On Wed, 15 Dec 2010 07:48:46 +0100
Otto Moerbeek o...@drijf.net wrote:
On Tue, Dec 14, 2010 at 10:26:44PM -0500, Brandon Mercer wrote:
If this type of thing really did happen and this actually is going
on something as simple as systrace
Subject: Allegations regarding OpenBSD IPSEC
Every urban lengend is made more real by the inclusion of real names,
dates, and times. Gregory Perry's email falls into this category. I
cannot fathom his motivation for writing such falsehood (delusions
of grandeur or a self-promotion attempt
The IPSEC allegations have produced a flurry of blog posts and
suchlike, mostly just rehashing the contents of Theo's original
message. However, I've found two followups that are interesting for
their own separate reasons:
in http://blogs.csoonline.com/1296/an_fbi_backdoor_in_openbsd , there
On Wed, Dec 15, 2010 at 11:33 AM, Peter N. M. Hansteen pe...@bsdly.net
wrote:
The IPSEC allegations have produced a flurry of blog posts and
suchlike, mostly just rehashing the contents of Theo's original
message. However, I've found two followups that are interesting for
their own separate
patrick keshishian pkesh...@gmail.com writes:
It is easy to shoot one's mouth off like that about bounty offered,
given the ridiculously constrained conditions the bounty is offered
under. He might as well offered a million USD. No one will be able to
prove this under these restrictions.
I
On Wed, Dec 15, 2010 at 3:36 PM, Damien Miller d...@mindrot.org wrote:
On Wed, 15 Dec 2010, patrick keshishian wrote:
It is easy to shoot one's mouth off like that about bounty offered,
given the ridiculously constrained conditions the bounty is offered
under. He might as well offered a
On Wed, 15 Dec 2010 10:27:31 -0800
Jason L. Wright ja...@thought.net wrote:
I
cannot fathom his motivation for writing such falsehood (delusions
of grandeur or a self-promotion attempt perhaps?)
Perhaps,
Promote his domains rank in google or the facebook link? (Does anyone
know if he always
On Wed, Dec 15, 2010 at 12:36 PM, Damien Miller d...@mindrot.org wrote:
On Wed, 15 Dec 2010, patrick keshishian wrote:
It is easy to shoot one's mouth off like that about bounty offered,
given the ridiculously constrained conditions the bounty is offered
under. He might as well offered a
On Wednesday, December 15, Kevin Chadwick wrote:
The real work on OCF did not begin in earnest until February 2000.
I can't see how this gives you credibility but maybe the people who
worked with you at the time can understand how your evidence supports
what you say.
I've known Jason for
On Wed, 15 Dec 2010 14:57:24 -0700
Tobias Weingartner weing...@tepid.org wrote:
So in this case, you're the one that is out of
line.
If your talking to me then I tried to make it clear that I was sitting
on the fence. I was going to go further but then figured that would be
leaning in one
I have received a mail regarding the early development of the OpenBSD
IPSEC stack. It is alleged that some ex-developers (and the company
they worked for) accepted US government money to put backdoors into
our network stack, in particular the IPSEC stack. Around 2000-2001.
Since we had the
I wonder a lot about the motives of the original sender sending that message.
Is it simply a way to spread FUD and discredit openbsd?
Is it a personal gripe with the accused?
Is it an attempt to manipulate what is used in the market?
Is it outright lies
Is it outright truth and genuine altruism?
On Tue, 14 Dec 2010, Bob Beck wrote:
I wonder a lot about the motives of the original sender sending that message.
Ignoring motive, and looking at opportunity:
We have never allowed US citizens or foreign citizens working in the US
to hack on crypto code (Niels Provos used to make trips to
If this type of thing really did happen and this actually is going on
something as simple as systrace or dtrace would have found it correct?
Surely folks have monitored and audited the actual function and traffic that
goes across the wire... conversely amd has a debugger that'll get you
access to
On Tue, Dec 14, 2010 at 10:26:44PM -0500, Brandon Mercer wrote:
If this type of thing really did happen and this actually is going on
something as simple as systrace or dtrace would have found it correct?
Surely folks have monitored and audited the actual function and traffic that
goes across
93 matches
Mail list logo
