> On Sun, Jan 20, 2002 at 19:55:31 +0000, Mark Murray wrote: > > > > This works, but strikes me as overkill. This is salt, not cryptographic > > randomness, so 'srandom(junk)' is most likely better as a replacement > > for srandomdev() (where 'junk' can be time(), pid or anything similar). > > You can't call srandom() from the libraries for the same purposes as > srandomdev(), i.e. it damages user application current RNG state in the > same way.
Hmm. OK. Do you understand, though, why the salt does not need cryptographic randomness? Another patch of yours replaced sprintf with a faster strlcpy, but this uses the _much_ slower arc4random() which is not necessary IMO. How about just using pid's or something? The original crypt(3) salt quantised the time-of-day into 4096 pieces for the salt - how about doing something like that? UUEncode time()|pid()|getuid() might work just fine. > I mean this: > > 1) User call srandom(3) > > 2) Library calls srandomdev() or srandom(123) > > Second step is effectively damages srandom(3) RNG state. > > -- > Andrey A. Chernov > http://ache.pp.ru/ -- o Mark Murray \_ FreeBSD Services Limited O.\_ Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
