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
