I am so sad.

8 years after the fact, people still forget that our kernel rc4 stream
is cut up among hundreds of consumers.

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, ....

After sharing a single pie with 200 people, you are using statistics
to claim it had no strawberries on it.

[ message continues ]

that's true, if one uses just /dev/arandom (as other consumers will
call arc4random() in the "background" as well). However if one changes
the code of arc4random() and arc4random_buf() to emit all generated
random values, we will get the whole sequence, from the very first
byte, no matter what "consumer" requestes data. Reading from
/dev/arandom will then generate the required amount of random values
for the statistic tests, while we can still record all values.

I'll see if I'll be able to do that, just for the sake of learning
something about the internals of openbsd.

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. The later
looks more complicated, but will certainly teach me more about openbsd
internals.

Regards
Kurt Knochner

http://knochner.com/

[ message continues ]

This isn't even remotely clever, but printf() and some base64 encoding
should work fine for a one-off experiment. There *is* a limit to how
much you can print before you fill up the dmesg; if insufficient, try
compiling with a CONFIG.MP_LARGEBUF like this:

---
include "arch/amd64/conf/GENERIC.MP"

option  MSGBUFSIZE=131072
---

You may wish to look at misc/ent.

		Joachim

[ message continues ]

-----Original Message-----
From: owner-tech@openbsd.org [mailto:owner-tech@openbsd.org] On Behalf Of
Joachim Schipper

or use syslog(3) to output to your destination of choice.

[ message continues ]

You should definitely check out this page if you hadn't already:
http://www.phy.duke.edu/~rgb/General/dieharder.php
The dieharder test suite already comes with input modules for reading 

Well if that's your goal, I think you probably need to patch the kernel 

In any case, generic statistical tests might detect really horrible 
brokenness but they're are not the thing to certify CSRNGs with. Somehow 
people managed to run them on RC4 for years before anyone noticed that 
the second byte of output was zero twice as often as it should be.

What could be really useful would be better models of the effective 
entropy contributed by kernel event classes going into the pool.

- Marsh

[ message continues ]

Really? So, how do you certify the IMPLEMENTATION (bold, not shouting)
of a CSRNG,  (not the theoretical design)?

Regards
Kurt Knochner

http://knochner.com/

[ message continues ]

'Certify' means different things to different people of course. Most
professionals don't insist on having the implementations that they use
But I've never heard of anybody using it unless they have to.

It's a really good question: how do you prove that something is
unpredictable?

In the US, it is the agency NIST. They coordinate and adopt standards
for deterministic and non-det pseudorandom number generation.
(There are some really fascinating documents on that site.)

NIST ran the competition which chose AES and are currently running one
to select SHA-3. They have some people who know a bit about the subject:
http://csrc.nist.gov/staff/rolodex/kelsley_john.html

NIST publishes some stuff about random generation from their statistical
engineering division:
http://itl.nist.gov/div898/pubs/ar/ar1998/node6.html
http://www.itl.nist.gov/div898/pubs/ar/ar2000/node9.html

But the computer security division covers the cryptographic side:
http://csrc.nist.gov/groups/ST/toolkit/random_number.html
http://csrc.nist.gov/groups/ST/toolkit/rng/index.html

They are careful to point out the distinction between statistical 

It looks like the FIPS standards are what cover the certification of an 
actual "cryptographic module implementation".
http://csrc.nist.gov/groups/STM/cmvp/inprocess.html

So the process would involve an approved design and you would have to 
submit your implementation to a NIST-approved "Cryptographic Security 
and Testing laboratory" for testing.

You can probably find some war stories about that process if you search 
around on line.

- Marsh

[ message continues ]

You can't.

So can we give this BS a rest?

[ message continues ]

There's no really good way to do this at the moment. Yes, that's a
problem.

		Joachim

[ message continues ]