Subject: Re: arc4random(9)
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 05/29/2002 13:19:29
>Why do you need a cryptographically strong generator for IVs?
Uhh... perhaps usually you don't. But sometimes, maybe you do. Short
answer: see rfc3217 and related drafts; decide for yourself how good a
high-quality RNG they really ask for. And whether it applies to an
Long answer: To quote Perry:
>Something like rc4
>generates bytes which are "random enough" for purposes like
>initialization vectors and such, but which are not "good enough" for
>doing something like generating crypto secrets. There are many places
>where you need lots of stuff that's better than ordinary
>non-cryptographic PRNG but where the needed quality isn't perfect
>(i.e. IVs, salts, garbage for sanitizing disk blocks after use, cover
>traffic generators, etc.)
Straight rc4 has problems even for IVs. (Fluhrer, Mantin, and Shamir,
and the related attacks on WEP). There is a 35% chance that the first
byte of an rc4 stream is the same as the first byte of the key; that's
what Thor is getting at. Not discarding the first few bytes after
a rekey is a bug, irrespective of whether OpenBSD has that bug or not.
I wasn't thinking of IPsec so much as more recent RFCs (and I-Ds)
which require high-quality randomness for IVs, e.g., rfc 3217, or
draft-ietf-smime-hmac-key-wrap-00.txt. Dunno how much of that is
relevant to in-kernel code, though..
Either way, the distinction between ``what netbsd thinks are good,
cryptographically-strong PRNGs'' and ``what FIPS-140 calls out''
is still valid.
Perry and I have disagreed over cryptography before. One instance was
Perry's suggestion to use swiched-off mikes as a high-quality
random-number source. Without analysis of where the bias in the A/Ds
lies, and de-skewing and/or compression, [see rfc1750] that's risky.
I beleive draft-ietf-avt-rtp-new-11.txt specifically warns against
what Perry suggested. (In theory, the phase difference between two
different oscillators also thermodynamically unpredicable; a 2+GHz CPU
cycle-counter, sampled at 10Mbit or 100Mbit packet-arrival interrupts,
*below* the jitter which NTP reports, should give a few bits of good
thermodynamic entropy. I dont know of any good studies of it, tho.
``Interesting research problem'' :-)