On Tue, Dec 14, 2010 at 5:54 PM, Theo de Raadt
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 network stack, in partic
On Dec 31, 2010, at 0:57, Otto Moerbeek 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 sele
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.
> 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
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-misc&m=1244135339134
2010/12/21 Kurt Knochner
> 2010/12/21 Theo de Raadt
> > > 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 to the point where they stop blin
Otto Moerbeek 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 Fri, Dec 24, 2010 at 07:53:52PM +, martin tarb wrote:
> Otto Moerbeek drijf.net> writes:
> > Please also check what djm@ wrote in one of the first replies to Theo
> > original mail:
> >
> > http://marc.info/?l=openbsd-tech&m=129237675106730&w=2
> >
> > -Otto
>
>
> Yep, I did see th
Otto Moerbeek drijf.net> writes:
> Please also check what djm@ wrote in one of the first replies to Theo
> original mail:
>
> http://marc.info/?l=openbsd-tech&m=129237675106730&w=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:27:02PM +, martin tarb wrote:
> Theo de Raadt 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
Theo de Raadt 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
> How much did you get?
> Is it safe for the boot process to generate keys now?
If you can only read.
On 23 December 2010 22:24, Marsh Ray wrote:
> It's a really good question: how do you prove that something is
> unpredictable?
>
> In the US, it is the agency NIST.
You can't.
So can we give this BS a rest?
On Thu, Dec 23, 2010 at 11:39:59AM +0100, Kurt Knochner wrote:
> 2010/12/22 Marsh Ray :
> > 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 shou
On 12/23/2010 04:39 AM, Kurt Knochner wrote:
2010/12/22 Marsh Ray:
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
shouting) of a CSRNG, (not the t
2010/12/22 Marsh Ray :
> Well if that's your goal, I think you probably need to patch the kernel to
> DMA the stuff into video RAM and offload the processing of it there. :-) Or
> something else, be creative. Try to write a backdoor
good ideas, I will consider them ;-)
> In any case, generic stat
2010/12/23 Clint Pachl :
> 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?
run it through
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 pat
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 thi
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 th
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 t
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
On Wed, Dec 22, 2010 at 4:49 PM, Clint Pachl wrote:
> Would it be possible to use what randomness the system does have to seed
> some reader that pseudo-randomly reads arbitrary bits from the loaded kernel
> image in RAM?
>
> This may differ per system, but doesn't uninitialized RAM start in an
>
Salvador Fandiqo wrote:
On 12/22/2010 01:46 AM, Theo de Raadt wrote:
2010/12/21 Theo de Raadt:
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.
Go
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 y
-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
On Wed, Dec 22, 2010 at 04:29:59PM +0100, Kurt Knochner wrote:
> 2010/12/22 Theo de Raadt :
> > 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
2010/12/22 Theo de Raadt :
> 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 uses just /dev/aran
On 12/22/2010 01:46 AM, Theo de Raadt wrote:
2010/12/21 Theo de Raadt:
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 th
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 develo
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
> implementatio
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 coun
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.
--
Best wishes,
Vadim Zhukov
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a
2010/12/22 Theo de Raadt :
>> > 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]
>
> Unfo
> > 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 :
>> 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 startup.
> No. You misrea
.. 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 :
> 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 exists today.
>
> Is
> 2010/12/22 Theo de Raadt :
> >> 2010/12/21 Kurt Knochner :
> >> > 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 valu
2010/12/22 Theo de Raadt :
>> 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 exactly-how-a-stream-cipher-works way
>
2010/12/22 Theo de Raadt :
>> 2010/12/21 Kurt Knochner :
>> > 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 i
> 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/21 Kurt Knochner :
> > 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 irrelevant because get
> On Tue, Dec 21, 2010 at 4:30 PM, Kurt Knochner
> 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 of /dev/arand
> 2010/12/21 Theo de Raadt :
> > 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 gives some i
2010/12/21 Kurt Knochner :
> 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.
Reagards
Kurt Knochner
http://knochner.com/
2010/12/21 Theo de Raadt :
> 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.
Good. That gives some information about system entropy, which will be
"good" at all times, except
On Tue, Dec 21, 2010 at 4:30 PM, Kurt Knochner 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 of /dev/arandom if you like,
2010/12/21 Ted Unangst :
> You can analyze the numbers coming out of /dev/arandom if you like,
much easier than rewriting the code.
> but the scheme basically depends on the security of rc4, which is
> still widely used. I realize this is proof by assertion, but if you
> could decode an rc4 stre
On Tue, Dec 21, 2010 at 07:45:09PM +0100, Kurt Knochner wrote:
> A last thing:
>
> From: src/lib/libc/crypt/arc4random.c
>
> arc4_stir(void)
> {
>
>
> /*
> * Discard early keystream, as per recommendations in:
> * http://www.wisdom.weizmann.ac.il/~itsik/RC4/Pa
On Tue, Dec 21, 2010 at 2:30 PM, Kurt Knochner 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?
>
> Sam from FreeBSD imported my rng tester and hooked it up to Fr
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 some
On Tue, Dec 21, 2010 at 4:00 PM, Joachim Schipper
wrote:
> If our RC4 state is , an attacker may be able to
> predict *most* of the RC4 state through the first couple of rounds
> (until sufficiently interferes with the known state).
>
> It *seems harder* (but I'm not an expert on this kind of thi
2010/12/21 Ted Unangst :
> On Tue, Dec 21, 2010 at 2:54 PM, Kurt Knochner
> 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
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.
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
> 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
> It *seems harder* (but I'm not an expert on this kind of thing!) to
> predict the first couple of rounds if is hashed (which
> means that you have to re-do the complete calculation for each possible
> , which may not necessarily be the case above), and if
> this hashing is used to distribute the
On Tue, Dec 21, 2010 at 3:04 PM, Joachim Schipper
wrote:
> On Tue, Dec 21, 2010 at 08:27:49PM +0100, Kurt Knochner wrote:
>> 2010/12/21 Joachim Schipper :
>> > + get_random_bytes(buf, sizeof(buf));
>> > + nanotime(&ts);
>> > + for (i = 0; i < sizeof(ts); i++)
>> > +
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 en
On Tue, Dec 21, 2010 at 2:54 PM, Kurt Knochner 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, diehard, etc.)
You ar
> 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?
> - 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 buffer should make attacks more difficult.
I do not understand wh
>"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 don't, This is voodoo. To do it once might
add something, but to
On Tue, Dec 21, 2010 at 08:27:49PM +0100, Kurt Knochner wrote:
> 2010/12/21 Joachim Schipper :
> > + get_random_bytes(buf, sizeof(buf));
> > + nanotime(&ts);
> > + for (i = 0; i < sizeof(ts); i++)
> > + buf[i] ^= ((uint8_t *) &ts)[i];
>
> I like the idea of using XO
> 2010/12/21 Otto Moerbeek :
> > 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
> afte
2010/12/21 Otto Moerbeek :
> 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 the second cal
> 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
On Tue, Dec 21, 2010 at 08:36:35PM +0100, Kurt Knochner wrote:
> 2010/12/21 Otto Moerbeek :
> >> 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 col
2010/12/21 Otto Moerbeek :
>> 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 collected bytes will have
> enough entropy. Think about situations very early
2010/12/21 Kurt Knochner :
> 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, just to make sure later
2010/12/21 Joachim Schipper :
> + get_random_bytes(buf, sizeof(buf));
> + nanotime(&ts);
> + for (i = 0; i < sizeof(ts); i++)
> + buf[i] ^= ((uint8_t *) &ts)[i];
I like the idea of using XOR. However, there are two issues:
1.) if nanotime() was called because of no
On Tue, Dec 21, 2010 at 07:45:09PM +0100, Kurt Knochner wrote:
> 2010/12/21 Otto Moerbeek
>
> > > 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. Ple
2010/12/21 Theo de Raadt
>
> > 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 trusting and
> in
On Tue, Dec 21, 2010 at 06:51:03PM +0100, Otto Moerbeek wrote:
> On Tue, Dec 21, 2010 at 05:59:33PM +0100, Kurt Knochner wrote:
> > OpenBSD uses arc4random() and arc4random_buf() all over the code to generate
> > random numbers. This code is defined in src/sys/dev/rnd.c.
> > [arc4stir] initializes
2010/12/21 Otto Moerbeek
> > 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. Please consider: this buffer will be used as
key
> > for rc4_keysetup() and thus
> 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 trusting and
instead go audit the code
But looked at
On Tue, Dec 21, 2010 at 11:59 AM, Kurt Knochner
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
> key setup. It'
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 fo
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 pla
Hi,
I think I might have found two "bugs" in the code of src/sys/dev/rnd.c. I
put up a description here.
http://bit.ly/hNLDqC
Can you please comment on my findings?
Thank you!
Regards
Kurt Knochner
http://knochner.com/
On Fri, Dec 17, 2010 at 11:39 PM, Pawel Veselov 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
> > are wrong to in
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 comm
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
> On Fri, Dec 17, 2010 at 7:59 AM, Theo de Raadt 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, Perry ha
On Fri, Dec 17, 2010 at 7:59 AM, Theo de Raadt
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 know or pretty damn w
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
> On Thu, Dec 16, 2010 at 3:30 PM, Marc Espie 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.
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 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 Ever heard ab
> > Here's a tip: when a government organization works with private
> > contractors to help them spy on other government organizations, those
> > NDAs don't fucking expire.
> >
> > Jesus.
>
> That is what I would expect.
>
> >From memory, in my part of the World if you did this sort of work for
>
> 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 mis
On Friday, 17 December 2010, (private) HKS wrote:
> On Thu, Dec 16, 2010 at 4:47 AM, Joachim Schipper
> wrote:
>> On Wed, Dec 15, 2010 at 07:04:27PM +, Kevin Chadwick wrote:
>>> "Jason L. Wright" wrote:
>>> >I cannot fathom his motivation for writing such falsehood
>>
>>> >The real work on O
On Thu, Dec 16, 2010 at 4:47 AM, Joachim Schipper
wrote:
> On Wed, Dec 15, 2010 at 07:04:27PM +, Kevin Chadwick wrote:
>> "Jason L. Wright" 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
The item I find interesting in all this is one I have not seen
commented on:
"the FBI implemented a number of backdoors and
side channel key leaking mechanisms into the OCF,
for the express purpose of monitoring the site to
site VPN encryption system implemente
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
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, "Ma
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!! what
On Wed, Dec 15, 2010 at 07:04:27PM +, Kevin Chadwick wrote:
> "Jason L. Wright" 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 people who
>
On Wed, 15 Dec 2010 14:57:24 -0700
Tobias Weingartner 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 direction. I certain
1 - 100 of 117 matches
Mail list logo
