Date: Sun, 20 Jan 2002 13:32:37 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: "Andrey A. Chernov" <ache@nagual.pp.ru> Cc: Mark Murray <mark@grondar.za>, des@freebsd.org, current@freebsd.org Subject: Re: Step1, pam_unix srandomdev fix for review Message-ID: <3C4B3775.1AFA318@mindspring.com> References: <20020120185334.GA23348@nagual.pp.ru> <200201201955.g0KJtVt32805@grimreaper.grondar.org> <20020120200455.GC24138@nagual.pp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
"Andrey A. Chernov" wrote: > 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. > > I mean this: > > 1) User call srandom(3) > > 2) Library calls srandomdev() or srandom(123) > > Second step is effectively damages srandom(3) RNG state. Since the library is a totally encapsulated usage, it makes sense for it to save and restore state aroun its use of the functions, which would effectively allow concurrent use of the generator with other code that uses it. Other code that cares about the state should do the same. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C4B3775.1AFA318>