> 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

Reply via email to