Re: Can dhclient rely on /dev/random?
Policy Question: is a fast, high-quality /dev/random a gauranteed feature starting with 5.0? yes. More like Yes, effectively. It is a module, and its conceivable under the right (Wrong?) circumstances that this module is not loaded. This would not be the default case, and it breaks Much(tm) if you don't include it. The kernel-building individual would have had to have made a decision to not include the RNG, and as such is assumed to know what she is doing. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Can dhclient rely on /dev/random?
On Sat, 28 Dec 2002, Tim Kientzle wrote: I've clocked /dev/random on -current at just about 10MB/s (on a 1GHz AMD Duron). That's plenty fast enough for generating session keys. ;-) Sounds like it, I didn't realize it was that fast. :) If this code is just used for generating occasional keys, 4.x's /dev/random may well suffice. As I dig deeper, though, I'm starting to suspect that this code isn't actually used by dhclient at all. That would suggest a much simpler fix... ;-) Tim Warning! Warning! Under 4.x, you probably want to use /dev/urandom. The reason for this is that /dev/random is only guaranteed to give you values when it can guarantee that you're getting good randomness. And as 4.x doesn't harvest many entropy sources by default, there's little good randomness, and you'll get nothing! /dev/urandom's bad randomness is certainly better than no randomness at all. :) Of course, if dhclient doesn't need any randomness, then I guess you don't have to worry. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Can dhclient rely on /dev/random?
Tim Kientzle wrote: The obvious fix would alter dhclient to rely only on /dev/random for entropy. (It seems this code is common to bind as well.) The obvious fix, I think, is to just use the boot time as the start for the exponential backoff. The only place this might be a problem is in a big installation where a lot of machines come on at the same time. That's probably going to melt your building's wiring, anyway. 8-). Technical Question: is /dev/random sufficient for the cryptographic requirements of programs like dhclient, bind, etc? Uh, what cryptographic requirements of dhclient? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Can dhclient rely on /dev/random?
Terry Lambert wrote: Uh, what cryptographic requirements of dhclient? I'm not really sure. ;-) The dhclient source has a 'dst' directory with source for an HMAC/MD5 digest authentication toolkit. I haven't figured out exactly what it's used for, though. (Dynamic DNS updates for secure BIND? Some form of authenticated DHCP?) Maybe someone else around here knows. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Can dhclient rely on /dev/random?
I just noticed that dhclient's randomness package uses, among other things, a variety of system commands (ps, netstat, etc) to harvest entropy. Unfortunately, dhclient is used in many situations where these commands are not available: sysinstall floppy, diskless client, /rescue, etc. The obvious fix would alter dhclient to rely only on /dev/random for entropy. (It seems this code is common to bind as well.) Policy Question: is a fast, high-quality /dev/random a gauranteed feature starting with 5.0? Technical Question: is /dev/random sufficient for the cryptographic requirements of programs like dhclient, bind, etc? I believe both of these are answered 'yes'. If so, I'll work up a patch to alter these programs to rely solely on /dev/random. I suppose that patch should be sent to the ISC folks, since those programs are vendor imports. (?) (I'm envisioning a FAST_GOOD_DEV_RANDOM compile-time switch; if set, /dev/random would be the only source of entropy used.) Any pointers/suggestions appreciated, Tim Kientzle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Can dhclient rely on /dev/random?
On Sat, 28 Dec 2002, Tim Kientzle wrote: Policy Question: is a fast, high-quality /dev/random a gauranteed feature starting with 5.0? Yes. Technical Question: is /dev/random sufficient for the cryptographic requirements of programs like dhclient, bind, etc? Yes. I believe both of these are answered 'yes'. If so, I'll work up a patch to alter these programs to rely solely on /dev/random. I suppose that patch should be sent to the ISC folks, since those programs are vendor imports. (?) (I'm envisioning a FAST_GOOD_DEV_RANDOM compile-time switch; if set, /dev/random would be the only source of entropy used.) Any pointers/suggestions appreciated, Tim Kientzle The only problem is that /dev/urandom and /dev/random might be too slow for direct use whereever random data is needed. However, they are certainly a lot better for seeding an RC4 generator (or something similar) than netstat / ps / etc would be. As such, you may even want to use /dev/urandom under 4.x, although it's nowhere near as good as the /dev/(u)random on 5.x. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Can dhclient rely on /dev/random?
In message [EMAIL PROTECTED], Tim Kientzle writes: I just noticed that dhclient's randomness package uses, among other things, a variety of system commands (ps, netstat, etc) to harvest entropy. Unfortunately, dhclient is used in many situations where these commands are not available: sysinstall floppy, diskless client, /rescue, etc. The obvious fix would alter dhclient to rely only on /dev/random for entropy. (It seems this code is common to bind as well.) Policy Question: is a fast, high-quality /dev/random a gauranteed feature starting with 5.0? yes. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Can dhclient rely on /dev/random?
Mike Silbersack wrote: On Sat, 28 Dec 2002, Tim Kientzle wrote: Technical Question: is /dev/random sufficient for the cryptographic requirements of programs like dhclient, bind, etc? Yes. The only problem is that /dev/urandom and /dev/random might be too slow ... I've clocked /dev/random on -current at just about 10MB/s (on a 1GHz AMD Duron). That's plenty fast enough for generating session keys. ;-) ... you may even want to use /dev/urandom under 4.x, although it's nowhere near as good as the /dev/(u)random on 5.x. If this code is just used for generating occasional keys, 4.x's /dev/random may well suffice. As I dig deeper, though, I'm starting to suspect that this code isn't actually used by dhclient at all. That would suggest a much simpler fix... ;-) Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
