On Sun, Jan 20, 2002 at 20:17:21 +0000, Mark Murray wrote: > > Hmm. OK. Do you understand, though, why the salt does not need > cryptographic randomness?
Yes. > 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? 1) arc4random() is not slower than random(), so it not _increase_ existent PAM slowness. 2) I care here not about PAM, but about user application which RNG state current code damages. 3) I treat arc4random() replacement as bugfix for _application_ which not makes PAM code worse than it already is. > 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 agree. But I don't plan to improve PAM in this my fix, I just want to unbreak application first. Someone else can do what you suggest afterwards. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
