Date: Sun, 20 Jan 2002 20:17:21 +0000 From: Mark Murray <mark@grondar.za> To: "Andrey A. Chernov" <ache@nagual.pp.ru> Cc: des@freebsd.org, current@freebsd.org Subject: Re: Step1, pam_unix srandomdev fix for review Message-ID: <200201202017.g0KKHLt33050@grimreaper.grondar.org> In-Reply-To: <20020120200455.GC24138@nagual.pp.ru> ; from "Andrey A. Chernov" <ache@nagual.pp.ru> "Sun, 20 Jan 2002 23:04:56 %2B0300." References: <20020120200455.GC24138@nagual.pp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 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?200201202017.g0KKHLt33050>