From owner-freebsd-questions@FreeBSD.ORG Wed Mar 2 10:06:29 2005 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14E3016A4CE for ; Wed, 2 Mar 2005 10:06:29 +0000 (GMT) Received: from mail.freebsd-corp-net-guide.com (mail.freebsd-corp-net-guide.com [65.75.192.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 718C343D53 for ; Wed, 2 Mar 2005 10:06:28 +0000 (GMT) (envelope-from tedm@toybox.placo.com) Received: from tedwin2k (nat-rtr.freebsd-corp-net-guide.com [65.75.197.130]) j22A6Ub26518; Wed, 2 Mar 2005 02:06:31 -0800 (PST) (envelope-from tedm@toybox.placo.com) From: "Ted Mittelstaedt" To: "Loren M. Lang" Date: Wed, 2 Mar 2005 02:06:25 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 In-Reply-To: <20050302051151.GC30896@alzatex.com> Importance: Normal cc: Rob cc: FreeBSD questions cc: Kris Kennaway Subject: RE: /dev/io , /dev/mem : only used by Xorg? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 10:06:29 -0000 > -----Original Message----- > From: owner-freebsd-questions@freebsd.org > [mailto:owner-freebsd-questions@freebsd.org]On Behalf Of Loren M. Lang > Sent: Tuesday, March 01, 2005 9:12 PM > To: Ted Mittelstaedt > Cc: FreeBSD questions; Loren M. Lang; Rob; Kris Kennaway > Subject: Re: /dev/io , /dev/mem : only used by Xorg? > > > I don't seem to have rndcontrol on 5.3, is that an old command? > I think you missed the back and forth on this between me and Kris? answer, no - the random device in 5.3 was rewritten to probe for ethernet and other random irq's > > > > Another strange thing is that /dev/random should block when it > > runs out of entropy - it doesen't seem to do so, however. And the > > device doesen't seem to gain entropy that quickly. > > Then how is /dev/random differ from /dev/urandom? > The current philosophy in random devices is to make both of these be the same, and use a better random number generator that generates random numbers faster, thus removing the need for separate devices. Here is a section of the readme from the Solaris patch 112439-02 which adds a random device to Solaris 2.6, it illustrates the typical older behavior of the two devices: Applications retrieve random bytes by reading /dev/random or /dev/urandom. The /dev/random interface returns random bytes only when sufficient amount of entropy has been collected. If there is no entropy to produce the requested number of bytes, /dev/random blocks until more entropy can be obtained. Non-blocking I/O mode can be used to disable the blocking behavior. The /dev/random interface also supports poll(2). Note that using poll(2) will not increase the speed at which random numbers can be read. Bytes retrieved from /dev/random provide the highest quality random numbers produced by the generator, and can be used to generate long term keys and other high value keying material. The /dev/urandom interface returns bytes regardless of the amount of entropy available. It does not block on a read request due to lack of entropy. While bytes produced by the /dev/urandom interface are of lower quality than bytes pro- duced by /dev/random, they are nonetheless suitable for less demanding and shorter term cryptographic uses such as short term session keys, paddings, and challenge strings. You see, the problem with this from an application developers perspective is that if you are designing an app that MUST only use high quality random numbers, then you have to read /dev/random not /dev/urandom - but if /dev/random's prng runs out of randomness, it will block, thus your application hangs until it unblocks. If you try to get around that by reading in nonblocking mode then your app won't hang, but you will get an error when the device runs out of numbers and you try to keep reading it. Thus your app will still have to set waiting around for more numbers. /dev/urandom allowed app developers to ignore all that because then the /dev/urandom device runs out of random numbers it just gives non-random numbers - while this of course makes your app insecure, most app developers don't give a shit since their customers don't know any better. FreeBSD did away with the blocking in /dev/random because a number of app developers didn't understand I/O and the FreeBSD core group got tired of hearing the complaints - reasoning (correctly) that if the app developer didn't bother to understand anything about random number generators then it didn't make any difference if the device fed them non-random numbers on occasion. > > > > The FreeBSD random device is a port of the same Linux code. > > I'm pretty sure that the linux code is GPLed, and I'd expect that > FreeBSD uses a BSD version. Are they actually from the same code? > Yes they are. However the author of the code, Theodore Ts'o, was well aware of the problems of GPL when he wrote it, and released the code with effectively 2 licenses, one BSD the other GPL. Of course Linux people subsequently applied the GPL to their version but that doesen't affect us, see the file /usr/src/sys/kern/kern_random.c in FreeBSD 4. There is at least one other random device that was written for Solaris that uses this code also. (andi's SUNrand) I also strongly suspect that Sun used this code in their patch 112439 since my testing of the Sun device and the FreeBSD device showed they fell down almost the same way. The 5.X random generator is a different animal, it is based on the Yarrow prng as well as more sensible hardware detection and use. Keep in mind that until 1995 when everyone started using UNIX servers for running SSL webservers on the Internet, almost nobody gave a damn about needing a random device under UNIX or any other operating system. > > Every doc I've heard of using prng on linux always suggests that the > native entropy source is better? Is this because the linux version has > better hooks in the kernel and always uses interrupts as a source? > The docs your reading are wrong or not really telling the whole story. For starters it isn't possible in a computer to get a source of randomness by just looking at interrupts, that will generate random numbers as fast as they are needed. Random devices (ideally) use interrupts as inputs to pseudorandom number generators (prngs) which are able to generate much larger quantities of random numbers at a much higher rate of speed. So it still boils down to who has the best algorithm for the prng. if the native random device uses a simple prng that cannot generate random numbers as fast as needed, even if the inputs to it are random, such as an interrupts, then it isn't going to be as good as a non-native prng that uses the same random inputs and uses a better algorithm. Ted