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 Tue, Dec 21, 2010 at 11:08:29PM -0700, Anthony J. Bentley wrote:
> Hi,
>
> This looks like a typo, almost changes the meaning of the sentence:
>
> Index: lib/libc/stdlib/malloc.3
> ===
> RCS file: /cvs/src/lib/libc/stdlib/malloc.
Hi,
This looks like a typo, almost changes the meaning of the sentence:
Index: lib/libc/stdlib/malloc.3
===
RCS file: /cvs/src/lib/libc/stdlib/malloc.3,v
retrieving revision 1.68
diff -u lib/libc/stdlib/malloc.3
--- lib/libc/stdlib/m
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
Wow. You really are not reading the same code, are you.
> [Just been following the discussions on the web archives, so sorry that
> I'm replying out of the email thread]
>
> * MD5 is used all the time in PRNGS. The collisions demonstrated aren't
> an issue if the attacker has almost no control
[Just been following the discussions on the web archives, so sorry that
I'm replying out of the email thread]
* MD5 is used all the time in PRNGS. The collisions demonstrated aren't
an issue if the attacker has almost no control over the input.
* An unauthenticated attacker may be able to sam
.. 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/
[IMAGE]*Los precio estan expresados en pesos argentinos e incluye IVA.
En caso de no querer recibir mas este correo por favor presione AQUI .
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
A few things that has me confused ...
1) pf(4) says DIOCSETDEBUG has enum { PF_DEBUG_NONE, PF_DEBUG_URGENT, ...
but these names are not in pfvar.h nor anywhere else in the source tree
(AFAICT). What should the legal values (or names) be?
2) pf.conf(5) says "set debug" can be one of loud, misc, n
> 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
Return-path: refertofriend-er...@reply.yahoo.com
Leslie (con...@yahoo.com) ti ha inviato un articolo
Testo del messaggio:
■學習圖像記憶法1600元■
■保證國立大學師資■
■東風衛視節目的老師親自錄的■
■保證完整學習9片VCD還有教材■
■想了解更多資訊嗎?■
■請按下面網址進入網站■
PBMS school Eurocup - Trevi
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/
I've been successfully running with this since Nov 24th. Definately
changes the behavior as advertised and has no issues that I have
seen in my testing, using duid's on svnd(4) on i386.
Penned by Joel Sing on 20101221 6:30.49, we have:
| When a vnd(4) device is configured the devi
On Mon, Nov 29, 2010 at 02:22:35PM -0800, Chris Kuethe wrote:
>Currently bioctl invokes readpassphrase(3) with RPP_REQUIRE_TTY, which
>means that there must be a controlling tty to read the password from.
>This diff adds an option (-s) to force bioctl to read the passphrase
>from stdin. Without thi
When a vnd(4) device is configured the device name is always configured as
vndX, even when it is created as a "safe" vnd (or svndX). This device name
is also used as the name for the disk:
$ vnconfig -c svnd0 /tmp/test
$ sysctl hw.disknames
hw.disknames=sd0:19291b8cb83eb8b8,cd0:,vnd0:
When DUIDs
On Tue, Dec 21, 2010 at 12:53 PM, Kenneth R Westerback
wrote:
> Just a note to remind everyone that you can change your fstab to
> use DUIDs rather than wd* and sd*, thus making it easier to survive
> the flips between wd and sd when changing BIOS settings.
>
> Using wd0 as an example, just 'disk
On Tue, Dec 21, 2010 at 11:27:30AM +0100, Mark Kettenis wrote:
> We still have some some issues with SATA/AHCI on NVIDIA chipsets. If
> you have a machine, could you send me the following information:
>
> * dmesg
> * output of 'pcidump -vxx'
> * BIOS setting (IDE/SATA/AHCI/RAID) if your BIOS prov
On Tue, 21 Dec 2010 11:27:30 +0100 (CET)
Mark Kettenis wrote:
> We still have some some issues with SATA/AHCI on NVIDIA chipsets. If
> you have a machine, could you send me the following information:
>
> * dmesg
> * output of 'pcidump -vxx'
> * BIOS setting (IDE/SATA/AHCI/RAID) if your BIOS pro
We still have some some issues with SATA/AHCI on NVIDIA chipsets. If
you have a machine, could you send me the following information:
* dmesg
* output of 'pcidump -vxx'
* BIOS setting (IDE/SATA/AHCI/RAID) if your BIOS provides that opportunity
* short description of any changes (BIOS settings, ke
On Tue, Dec 21, 2010 at 09:34:01AM +0100, David Coppa wrote:
> On Tue, Dec 21, 2010 at 2:23 AM, Fernando Quintero
> wrote:
> > some comment?
> >
> > http://seclists.org/bugtraq/2010/Dec/200
>
> I'm not able to provide a solution, but this is of course a bug that
> needs to be fixed.
If you look
On Tue, Dec 21, 2010 at 2:23 AM, Fernando Quintero
wrote:
> some comment?
>
> http://seclists.org/bugtraq/2010/Dec/200
I'm not able to provide a solution, but this is of course a bug that
needs to be fixed.
I think claudio@ or henning@ are the right persons to ping...
Ciao,
David
66 matches
Mail list logo
