On 07/16/2014 04:28 PM, Theo de Raadt wrote:
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.
I did, that's why "fwiw" and "needed", as in "look, you fixed a bug
without noticing".
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?
It wasn't, I was just surprised that nobody had noticed.
Sorry for the noise anyway.
