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/malloc.3 26 May 2010 08:22:11 -0000 1.68 +++ lib/libc/stdlib/malloc.3 22 Dec 2010 06:02:47 -0000 @@ -235,7 +235,7 @@ Unused pages on the freelist are read and write protected to cause a ...

I was just asking if the implementation of the RC4 based PRNG is done correctly and if there has been a test of the quality of the PRNG output. It just looked strange for me to seed the algorithm of the PRNG with a plain time value, though it's just a few bytes at the beginning of a larger block of data. So, if you believe the implementation of the PRNG is correct, there is no need to further I did not say, that anything you generate is crap.

Damn, you're right. It seems my grep pattern was "initialized" in the After adjusting my grep pattern, I found several more locations. A lot of those need the filesystem. However at least one (for sure much more) is indeed calling arc4random while there is no filesystem mounted. True (that it's false). So, I guess the discussion about the use of nanotime() is finished, as there is "common agreement" that it has no influence on the PRNG, right?

It's up to you to make that decision. You know the code better than anybody else.

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

[list of 16] No, there is much more than that. Processes get started and initialize their libc-based prng's, as well as other state, including The MD5 is required.

Holy cow, you are dense. I am going to throw out estimates here because (a) it has been a long time since we tested, and (b) so much can vary machine to machine. Without a hardware RNG device, a typical i386 desktop machine can provide (based on interrupt sources) around 1800 bytes of base entropy to the MD5 thrasher -- per minute. Meanwhile, OpenBSD is consuming about 80 KB of arc4random output per minute. How do you convert 1800 bytes of input to 81920 bytes of output, while giving ...

That is completely irrelevant because get_random_bytes() is only used as the *source material* for a RC4-based PRNG. WE HAVE THREE LAYERS OF PRNG.

Four days ago, if you were using a particular set of hardware drivers, then yes. But the software ipsec stack was fixed for this NINE YEARS AGO. No. The upper bits are 'more known'. The lower bits are 'less known'. We don't save entropy over boots. You are speaking of one specific way of solving this, and we don't do that. You can read the code in /etc/rc and /etc/rc.shutdown. At shutdown, we save a block of OUTPUT from the PRNG. At boot, right after some extremely early system ...

i think this is reasonable, though i'd maybe change the "It" to "This option" (both here and -p). anyone else agree?

fixed, thanks.

Perhaps that's why you seem unwilling to listen to what you are being told. Can you please stop wasting time asking questions before you bother to read about what you are asking? You have flipped the bozo bit. You're on your own until you bother doing some of your homework. -kj

Yes. I agree.

The keynote.{1,3,4,5} man pages reference a paper entitled "Decentralized Trust Management" by M. Blaze, J. Feigenbaum, and J. Lacy, but the name of the conference is incorrect. That paper was presented at the IEEE Symposium on Security and Privacy [1, 2], and not the "IEEE Conference on Privacy and Security." [1] http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=502679 [2] http://www.crypto.com/papers/ The following diff fixes the conference name. Lawrence Index: ...

On Wed, 22 Dec 2010 05:08:56 -0600 There was a thread "called how to use /dev/srandom" where theo sent this, which may be relevant? ======================================================================= For those who don't want to go read the code, the algorith on the very back end is roughly this: (a) collect entropy until there is a big enough buffer (b) fold it into the srandom buffer, eventually That is just like the past. But the front end is different. From the ...

[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 sample an almost arbitrary amount of output from your PRNG by making new IPsec connections. As I understand it, each now sends 128 bits or so of output as plaintext over the wire in the IV. :-) * How ...

Consider the possibility that I have, in fact, read a little bit about it and am asking some of these questions because I suspect you don't actually have a good answer for them. People who are deeply convinced of This one does it in 2^26 bytes: http://www.iacr.org/cryptodb/data/paper.php?pubkey=2597 Let's see, (libc)arc4random.c says: > arc4_count = 1600000; That's about 2^20 so you'd get 41 reseedings generating that much input data. But how much would these reseedings disrupt ...

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

Applied Cryptography only has a sketch. Details have to be filled in. In summary, the kernel arc4 is reseeded completely with bytes from the entropy pool periodically, while the libc arc4 is seeded once with bytes form the kernel arc4 at first use after process startup and then stirred with a sequence of random bytes obtained from the kernel after every x bytes produced. I can maybe guess why it is this way, but I'd like knowledgeable person to comment on this. Note that the ...

Now that it's amateur suggestion hour (no offense Salva), I'm going to take a shot. 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 "unknown state?" If so, could that be added to the entropy pool if it is determined to be random (i.e. not initialized to zeros)?

eh3<d9g62h7/h!i 7e
f3 h*2g(g.go<fd>e-8e!ei
g(g62h7/eh3<ge8e 4h6(e"o<e
e:e1,f<e0h*e71d<
f%-i 7e.f e9+e )gh*2g(cf,h*2g(e0fd>f4e$i
g(eh3<gih7/hf9e<o<f ef,f(ee
ggf%-f8ifef4i+c h*2g(fio<99/e9412f31f%(d:) 13:30~17:6:30 [d8 e0f] h*2g(e'e.9o< eh3<h6(e"he8e 4h&f(! eh3<e8e 4h&
e&e
? eh3<e%e#gf/h< f6h2;hg:d=h&
eh3<? eh3<e8e ...

I think we'd much rather just have a good random generator, than rely on one of uncertain quality. If the system really, really, really needs random numbers before entropy is available, then we should fix that problem, not try to magic up some entropy.

On Wed, 22 Dec 2010 09:03:57 +0100 So the names in 2) should be removed from the pf.conf man page and the names in 3) should be added, then? How about something like this (text is mostly a copy of that in the pfctl man page for the -x option): Index: pf.conf.5 =================================================================== RCS file: /cvs/src/share/man/man5/pf.conf.5,v retrieving revision 1.482 diff -u -p -r1.482 pf.conf.5 --- pf.conf.5 15 Dec 2010 14:06:05 -0000 1.482 +++ pf.conf.5 22 ...