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 theoretical design)?
Regards
Kurt Knochner
http://knochner.com/
able, different every time, different on all systems.
Regards
Kurt Knochner
http://knochner.com
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. The later
looks more complicated, but will certainly teach me more about openbsd
internals.
Regards
Kurt Knochner
http://knochner.com/
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
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
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 :
>> 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 en
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/
be
necessary, as buf will allways contain some good random data.
Reagards
Kurt Knochner
http://knochner.com/
ut
cryptography. One can't feel or see how code changes influence the
produced random values unless they are checked/tested.
Regards
Kurt Knochner
http://knochner.com/
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
>> t
o random value sequences and feed them into
the NIST test suite for random values (chi-square, diehard, etc.)
4.) Repeat those steps after the removal of the time value from the code.
5.) Try to interpret the outcome of the NIST tests. Maybe other people
(real cryptographers) should help with this
about situations very early in machine startup,
> where the state of things could be predictable.
O.K. I see... But isn't the value of nanotime() kind of "predictable" as well?
Regards
Kurt Knochner
http://knochner.com/
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 m
turn enough random data - see my other
post.
2.) don't forget to check if sizeof(ts) <= sizeof(buf), otherwise you
will create a buffer overrun.
Regards
Kurt Knochner
http://knochner.com/
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
Regards
Kurt Knochner
http://knochner.com/
p;rndlock);
However here, 1024 bytes (256 * 4) will be skipped. Maybe that's just a
misinterpretation of what a "word" is (byte or integer).
Maybe I'm paranoid and see problems where there are none. But then, this is
part of the crypto code and there should be no open questions about the
implementation details.
Regards
Kurt Knochner
http://knochner.com/
ess, as
the data structure will be overwritten again with the init data of the RC4
function.
AGAIN: I'm not saying that this is part of the backdoor nor that it weakens
the PRNG. HOWEVER, this does not look right and leaves some bad feeling for
me!
I think we will need some investigation on the effect of PRNG quality caused
by these two bugs.
Regards
Kurt Knochner
http://knochner.com/
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/
20 matches
Mail list logo
