Date: Thu, 26 Jan 2012 18:48:48 +0000 From: Mark Murray <markm@FreeBSD.org> To: David Schultz <das@FreeBSD.ORG> Cc: svn-src-head@FreeBSD.ORG, svn-src-all@FreeBSD.ORG Subject: Re: svn commit: r230230 - head/sys/dev/random Message-ID: <E1RqUNN-000OwI-0g@groundzero.grondar.org> In-Reply-To: <20120126175243.GA19199@zim.MIT.EDU> References: <E1Rny2A-000C3x-O6@groundzero.grondar.org> <20120126143819.GA88677@vniz.net> <20120126155626.GA92229@vniz.net> <201201261132.38320.jhb@freebsd.org> <20120126165521.GA92622@vniz.net> <20120126175243.GA19199@zim.MIT.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
David Schultz writes: > > Although current version with current kernel flags works, I forget > > it is implementation defined in general and not always equal to > > sizeof(int), f.e. with gcc --short-enums. I'll remade it with > > #defines, thanx again. > > Why complicate things with atomics at all? A race might result in > arc4random(9) being seeded multiple times, but that's harmless. > > The race that worries me is that consumers that call arc4random() > before it is properly seeded will get predictable numbers. To fix > that robustly, we'd either have to move arc4random() into the random > module (tricky given all the places where it's used), or make the > random module a mandatory part of the kernel. There is a VERY old problem here, and it is of the chicken vs egg variety. The random device won't unlock until it has enough entropy, and there are things in the kernel that appear to need "random enough" numbers earlier than that. It ought to be possible to unlock the CSPRNG by harvesting entropy earlier, but this is hard work. Very hard work. Unless you have entropy-generating hardware. In the meanwhile, you are left with other alternatives; reseed arc4random() with some early entropy; try to move entropy consumers to later in the boot sequence; try to not depend on entropy early on, and correct for this later (where necessary). There are loads of other alternatives. What you can't do is unlock before you have enough entropy, and that won't happen until the running kernel has had some time to accumulate this. I am in favour of treating arc4random() as a PRNG with (say) the date/time, the TSC register and other easy-to-get data as the first seed. After that its treated as a CSPRNG. This requires that early consumers know the limitations and adapt to them. The notion of making arc4random() block would be silly; the point of the thing is that it always returns numbers, and after the random device seeds, it should always be good. > OpenSSL addresses the issue by providing two APIs: RAND_bytes() > requires a good entropy source and produces cryptographically strong > pseudorandomness. RAND_pseudo_bytes() produces "good" (but not > necessarily unpredictable) randomness, even in the absence of an > entropy source. Applications call one interface or the other, > depending on whether they require cryptographic- quality randomness. You are treading on graves here :-). An ancient bikeshed is buried in the vicinty. M -- Mark R V Murray Cert APS(Open) Dip Phys(Open) BSc Open(Open) BSc(Hons)(Open) Pi: 132511160
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1RqUNN-000OwI-0g>