Random number generators

Pedro Giffuni pfg at FreeBSD.org
Tue Mar 17 12:10:56 UTC 2015

> Il giorno 17/mar/2015, alle ore 01:03, Steve Kargl <sgk at troutmask.apl.washington.edu> ha scritto:
> On Mon, Mar 16, 2015 at 11:22:31PM -0500, Pedro Giffuni wrote:
>> Hi;
>> FreeBSD libc random functions are not too bad but in general I was having some thoughts about how the random generator functions in libc are slow and predictable and how just about every application nowadays is including "Mersenne Twister"  or similar algorithms (which are fast and better in every way but can?t be adapted for the C API) in their applications.
>> OpenBSD did something drastic about it [1], breaking standards and compatibility and whatnot.
>> I wouldn?t go there and I don?t think there is any real ?solution? for this. The musl libc guys tried something interesting though. They took the tempering function from MT:
>> http://git.musl-libc.org/cgit/musl/commit/?id=20d01d83b5a13c77805976e7c520f566244ba3ff <http://git.musl-libc.org/cgit/musl/commit/?id=20d01d83b5a13c77805976e7c520f566244ba3ff>
>> It should be something relatively easy to try on our implementation too, if someone feels like running the tests and measuring if there is a difference.
>> Pedro.
>> [1[ http://www.tedunangst.com/flak/post/random-in-the-wild
> I suppose it depends on what you want to accomplish.  MT
> can be a horrible thing to use.  See the history of 
> libgfortran/intrinsics/random.c (svn r82443) where I ripped
> MT out many years ago in favor of George Marsaglia's KISS generator.
> The KISS generator that I used was his 32-bit version.  GM has
> a 64-bit generator as well.  The 32-bit version passed all
> of GM's diehard tests.  I haven't read a report on the
> 64-bit generator's diehard result. 

Oh, absolutely, I am considering something like this for OpenOffice.
Apache OpenOffice (and LibreOffice, I think) is using MT (from Boost)
but the seeding is not done properly.

> One big issue is saving internal state.  IIRC, MT requires 623-bit
> of internal state.  KISS requires 4 32-bit int.  Thus, if
> you want to reseed the generator, KISS requires far less effort.

Yes, the problem is the that libc requires a single 32 (or 31) bit seed.
Given that restriction, our existing generator is not bad. Enforcing something
better breaks the API and is not really practical to get crypto-grade randomness
for stuff like refreshing a slide in a presentation anyways.

The musl libc approach seemed reasonable but I haven’t looked at the
base random generator there (I’ve heard the glibc one is not good at all).


More information about the freebsd-numerics mailing list