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
> > 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.
>
"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
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
> > 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
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
> 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
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
> 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
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
10 matches
Mail list logo