> On 07/13/2014 06:31 PM, Jean-Philippe Ouellet wrote:
> > On Sun, Jul 13, 2014 at 04:03:53PM +0200, Brent Cook wrote:
> >> On Jul 13, 2014, at 3:58 PM, Ted Unangst <t...@tedunangst.com> wrote:
> >>> @@ -411,6 +404,9 @@ static long
> >>> random_l(void)
> >>> {
> >>> int32_t i;
> >>> +
> >>> + if (use_arc4random)
> >>> + return arc4random() & 0x7fffffff;
> >>
> >> return arc4random() % ((unsigned)RAND_MAX + 1) ?
> >
> > No. RAND_MAX is for rand() not random().
> >
> > From posix for random():
> > The random() function shall use a non-linear additive feedback
> > random-number generator employing a default state array size of
> > 31 long integers to return successive pseudo-random numbers in
> > the range from 0 to 2^31 - 1.
> >
> This fwiw means that srandomdev needed fixing anyway, since a LFG needs
> at least one of the elements in the stare array to be odd (or, since
> random right shifts one position, at least one element with one of the
> two lowest bits set).
That is false. Please read the actual code. The new variation uses
srandomdev() as an indicator that random() gets hooked direct to
arc4random. The guts of the algorithm are never used again.
The old code may have that issue. We will no longer case because this
fixes the issue. You can bring this to the attention of the FreeBSD
developers, who created this interface.
> True, the chances of both happening are __ridiculously__ small, but hey,
> aren't openbsd devs paranoid? :)
Was that neccessary?
