Re: arc4random - are you sure we want these?

["Jason A. Donenfeld" <Jason@zx2c4.com>]

Hi Cristian,

On Sun, Jul 24, 2022 at 12:23:43PM -0400, Cristian Rodríguez wrote:
> On Sat, Jul 23, 2022 at 6:59 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> 
> > Doesn't getrandom() already basically have this quality?
> 
> In current kernels. yes. problems with old kernels remain..

Can you outline specifically which kernels you think those are and what
the problems you think there are? And how arc4random as currently
implemented does away with those problems?

I kind of suspect you don't have something specific in mind...

> The syscall
> overhead being too high for some use cases is still a remaining
> problem,

Really? Do you have any numbers? I would be very surprised to hear that
this is affecting things that intend to use arc4random as a substitute.
Could you give me specifics on this? Again, this sounds made up in the
absence of something real, widespread, and particular.

> if that was overcomed it could be used literally for everything,
> including simulations and other stuff.

You mentioned simulations, but actually simulations are one thing where
you want repeatable randomness -- something insecure with a seed that
gives a good distribution and is extremely fast, so that you can repeat
your simulation with the same data need-be. For this there are various
LFSRs and such that work fine and are well explored. But that's not what
getrandom() is, nor arc4random().

More generally speaking, there are well-defined RNGs that are for
simulations and take seeds, and there are well-defined RNGs that are
sufficient for crypto, and then there's a massive valley of ill-defined
junk in between that people keep shooting themselves in the foot with.

The fact that you won't even call arc4random cryptographically secure
(according to Adhemerval's comment) indicates to me that something has
gone wrong here.

So, please, I urge you to put the breaks on this a little bit. Come up
with numbers. Let's lay out the interfaces and properties we want. And
then we'll see what we can draw up together.

But now I'm just repeating myself. See my earlier reply here:
https://lore.kernel.org/linux-crypto/Ytx8GKSZfRt+ZrEO@zx2c4.com/

Jason