Re: Step1, pam_unix srandomdev fix for review

2002-01-20 Thread Peter Jeremy
On 2002-Jan-20 21:51:07 +, Mark Murray <[EMAIL PROTECTED]> wrote: >> > 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 effectivel

Re: Step1, pam_unix srandomdev fix for review

2002-01-20 Thread Mark Murray
> > 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. >

Re: Step1, pam_unix srandomdev fix for review

2002-01-20 Thread Terry Lambert
"Andrey A. Chernov" wrote: > On Sun, Jan 20, 2002 at 19:55:31 +, 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 any

Re: Step1, pam_unix srandomdev fix for review

2002-01-20 Thread Andrey A. Chernov
On Sun, Jan 20, 2002 at 20:34:35 +, Mark Murray wrote: > > > 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

Re: Step1, pam_unix srandomdev fix for review

2002-01-20 Thread Mark Murray
> > 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. Some

Re: Step1, pam_unix srandomdev fix for review

2002-01-20 Thread Andrey A. Chernov
On Sun, Jan 20, 2002 at 20:17:21 +, 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

Re: Step1, pam_unix srandomdev fix for review

2002-01-20 Thread Mark Murray
> On Sun, Jan 20, 2002 at 19:55:31 +, 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). > > Y

Re: Step1, pam_unix srandomdev fix for review

2002-01-20 Thread Andrey A. Chernov
On Sun, Jan 20, 2002 at 19:55:31 +, 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

Re: Step1, pam_unix srandomdev fix for review

2002-01-20 Thread Mark Murray
> Bug: > srandomdev() can't be used in libraries because it touch internal RNG > state which may be used by user program which not want true randomness but > pseudo one. > > Fix: > srandomdev() removed, random() replaced by arc4random() which initialize > itself from true randomness automaticall

Step1, pam_unix srandomdev fix for review

2002-01-20 Thread Andrey A. Chernov
Bug: srandomdev() can't be used in libraries because it touch internal RNG state which may be used by user program which not want true randomness but pseudo one. Fix: srandomdev() removed, random() replaced by arc4random() which initialize itself from true randomness automatically. --- pam_uni