On Mon, 19 Dec 2005, Theo de Raadt wrote:
> Until you can justify actual real scientific reasons why you cannot
> use it, I think you should use arc4random().
>
> And I am entirely serious. The entire idea in OpenBSD is to have many
> consumers, as this strengthens the source.
Thanks for your comments, but I will attempt to justify why I cannot use
arc4random() or /dev/arandom.
I'm working on Professor Rabin's HyperEncryption project. The goal is to
create a system for distributing random numbers to form one-time pads such
that even an adversary who can break whatever crypto you happen to have
devised is stopped by other limitations, such as limited storage or
limited access to your data lines (that is, you have several links and the
adversary can monitor some but not all of them). The idea is to offer a
system which is cheaper and more flexible than quantum cryptography, but
almost as secure (i.e. perfectly, information-theoretically secure with
very high probability in the ideal case, requiring more assumptions for
this ideal case than quantum cryptography, but not requiring a short,
private, dedicated fiber-optic line and $50k worth of hardware on either
end). Obviously, within these design goals, truly random numbers are
necessary, because a computationally unbounded opponent can break
arc4random(). Such an adversary can break other things, too, so we'll
have to do a whole bunch of other things (turning off SYN cookies comes to
mind), but the random numbers are a more immediate design parameter.
Now, the project isn't in production or anything yet; we have some
prototypes are exploring their design spaces, but a very important
parameter is the cost and data rate of commercially available high-quality
random number generators, and their software support under various
operating systems. Under a limited-access model, the rate is not too
important (while it adds to the amount of data that can be transmitted and
marginally to its security, it is not essential that the data rate be very
high), but 200B/s is still probably too slow.
An important security and maintenance feature of this system will be
whether it can be engineered cleanly. OpenBSD is considered a relatively
secure OS, has a wide variety of hardware random number generator support,
and perhaps most importantly is relatively easy to configure minimally on
embedded hardware. So, we're very interested in supporting it,
particularly on embedded hardware, but we need to know what kind of random
number generators work on it at an acceptable rate. It looks like this
will probably mean the VIA C3 or C7, but we'd like to give Hifn cards a
shot. Also, given the terrible performance of the Hifn card, it's not
clear that even the VIA C7 would be faster or whether the drivers are the
rate-limiting step, which is why I'm asking for clarification here. I
could, of course, write a VIA-specific user-mode RNG driver because their
chips allow that. This is a strong draw to VIA, but OS support would be
preferable.
@Jason Crawford, we have considered and even prototyped sound-card-based
solutions (mostly involving running a simple radio noise source into the
microphone port, which is likely to have less pure-tone noise than your
suggestion), and while they aren't out of the running yet they have two
important problems. First, it will be more difficult to determine whether
the output of this system is sufficiently random. We can run FIPS tests
in real time at the rates we're dealing with, but the audio system will
almost certainly not pass this or even come close. Massaging the data
into a form which is both "white" and sufficiently simple that a breakdown
will be detected is rather difficult. On the other hand, most hardware
RNGs create noise with only very local biases (in raw mode) which should
be easier to filter out without hiding breakages. Second, most embedded
boards do not have sound cards, an almost none have microphones.
Thanks a lot,
Mike Hamburg
