GNU C Library Finally Adds arc4random Functions For Linux

[phoronix]

Phoronix: GNU C Library Finally Adds arc4random Functions For Linux

The arc4random, arc4random_buf, and arc4random_uniform functions have been common on the BSDs for years to provide higher quality random number generation than rand/random and alternative functions. But now as of yesterday the GNU C Library (Glibc) has finally added the arc4random functions for use on Linux!..

https://www.phoronix.com/scan.php?page=news_item&px=GNU-Glibc-arc4random-Functions

[OneTimeShot]

I think the problem with arc4random was that it was based on RC4 and so was broken with legal issues. I'm not sure that using CHACHA is technically correct according to the function documentation.

Probably best to use a generic name like "secrandom" and not defining what algorithm is used to implement it... You know, 'coz who knows if CHACHA will be suitable in 10 years' time.

[soulsource]

I'd be curious what changed. The reasoning behind the original rejection was imho perfectly on point, along with the suggestion to put those functions into a separate library.

[stormcrow]

I think the problem with arc4random was that it was based on RC4 and so was broken with legal issues. I'm not sure that using CHACHA is technically correct according to the function documentation.

Probably best to use a generic name like "secrandom" and not defining what algorithm is used to implement it... You know, 'coz who knows if CHACHA will be suitable in 10 years' time.

So I looked up the history of the arc4random() function in the FreeBSD man pages. It doesn't specify in its functional documentation what algorithm it uses just what to expect as output. BUT, the history statement explicitly states that the function originally started as RC4 in OpenBSD 2.1, but it was indeed changed to be ChaCha-20 in OpenBSD 5.5 while it was changed from RC4 to ChaCha-20 in FreeBSD in release 12. Making the original algorithm for glibc ChaCha is simply making it compatible with current BSD expectations. There's no reason it can't be changed later on should some situation arise where it's necessary to do so. The people that are maintaining this function in BSD are probably fully aware there's no current mathematical proof they're random enough for the task, but as currently understood it's sufficient.

It's a difficult problem. How do you know if a number is actually random if you're not even sure the base line we're comparing them against are random fluctuations? Current answer is: "You can't."

[RedEyed]

So I looked up the history of the arc4random() function in the FreeBSD man pages. It doesn't specify in its functional documentation what algorithm it uses just what to expect as output. BUT, the history statement explicitly states that the function originally started as RC4 in OpenBSD 2.1, but it was indeed changed to be ChaCha-20 in OpenBSD 5.5 while it was changed from RC4 to ChaCha-20 in FreeBSD in release 12. Making the original algorithm for glibc ChaCha is simply making it compatible with current BSD expectations. There's no reason it can't be changed later on should some situation arise where it's necessary to do so. The people that are maintaining this function in BSD are probably fully aware there's no current mathematical proof they're random enough for the task, but as currently understood it's sufficient.

It's a difficult problem. How do you know if a number is actually random if you're not even sure the base line we're comparing them against are random fluctuations? Current answer is: "You can't."

You can measure entropy of prng function

[xnor]

It's a difficult problem. How do you know if a number is actually random if you're not even sure the base line we're comparing them against are random fluctuations? Current answer is: "You can't."

Of course you can. You can do a host of tests. Check out TestU01. Also check out rng-tools, you may even have it installed already.

[Gonk]

This discussion reminds me of two great videos about what is

and is not

random.

[stormcrow]

You can measure entropy of prng function

Only to a certain point. Once you reach the point of theoretically being statistically indistinguishable from quantum fluctuations and white noise the question becomes whether or not white noise and quantum fluctuations are actually random, which we don't know for sure. That's the reason there's always people looking into the mathematical soundness of PRNG algorithms. There's currently no mathematical proof that the background is random. Some theories suggest it may not be.

Really doesn't matter to most people of course, but it may matter in some unspecified point in the future.

[brad0]

Wow, I think hell has frozen over. This is awesome. Now to just get musl to do the same. Bionic, due to it's BSD origin, has had arc4random() since the start.

[soulsource]

Wow, I think hell has frozen over. This is awesome. Now to just get musl to do the same. Bionic, due to it's BSD origin, has had arc4random() since the start.

Why exactly is this a good thing? There is a perfectly usable implementation of those functions in libbsd. That they get added to the C library sounds a lot like feature creep to me. Of course, if those functions get added to a C standard, the situation is different, but now it's just building up technical debt (because if they exist, they are going to be used, and if they are used, they have to be maintained).