On Tue, 20 Dec 2005 00:52:13 -0500 (EST), Michael Alexander Hamburg <[EMAIL PROTECTED]> wrote:
>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 Michael, The best thing you can do is call HiFn and discuss your design requirements with them rather than trying to guess what the throughput/rate is for their products. The guy you want to talk to is probably Russell Dietz (RDietz<AT>hifn.com) VP of Engineering (cc'd). I once met him for lunch to discuss opening up documentation. Though HiFn doesn't quite understand the importance of making their docs freely available without EULAs and legal click-through hoops so OpenBSD and other open source projects can properly develop drivers, none the less, the folks working at HiFn are still very nice people. Kind Regards, JCR
