[Bug libc/29437] arc4random is too slow

["adhemerval.zanella at linaro dot org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=29437

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adhemerval.zanella at linaro dot o
                   |                            |rg

--- Comment #6 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Miroslav Lichvar from comment #5)
> I need a PRNG that is fast and not as easily predictable as random(). That's
> how arc4random() is documented on FreeBSD and other systems supported by
> chrony. As I understand it, it's not supposed to be used to generate
> long-term keys, for instance.

Both OpenBSD (and FreeBSD which base its implementation on OpenBSD) [1] and
MacOS [2] (which used to be based on OpenBSD, but now has its own
implementation) state they are CSRNG (OpenBSD doc is not really clear in the
sentence it describes some of the internal, but it is used as CSRNG in the
code).

However, the OpenBSD implementation (and all implementations based on the
user-managed buffer, like FreeBSDB and libbsd) uses heuristics to trigger the
buffer reseed, which is not *suffice*. 

For example, when a virtual machine is forked, restored, or duplicated, it's
imperative that the RNG doesn't generate the same outputs. For this reason,
there's a small protocol between hypervisors and the kernel that indicates this
has happened, alongside some ID, which the RNG uses to reseed immediately, so
as not to return the same numbers.

So the kernel becomes the focal point on how to correctly generate and manage
cryptographic secure RNG, and one of the drives of arc4random inclusion is it
should not provide worse RNG than getrandom syscall.

> 
> If the reason for adding arc4random() was source compatibility, that won't
> work well for applications that need high performance. They will still need
> to support another PRNG.

That one of the reason yes.

> 
> If new applications assume arc4random() is a high-quality CSPRNG and
> generate long-term keys with it, they might have security issues on the
> other systems where this is not the case.

Yes, but it is an improvement for the Linux ecosystem nonetheless. Other
systems, like Windows and MacOS are also moving on same direction.

> 
> I'm not sure what are the benefits of the current implementation.

The benefits is to proper provide CSRNG, regaless on how the environment is
deployed or configured, to avoid each library deploy wrong and insecure
user-based alternatives.

The vDSO discussion to speed up getrandom is still ongoing the main issue seems
on who and how should be the one responsible to buffer management. The
performance of arc4random was indeed initially taking in consideration [3] (I
even spent considerable time to adjust libgcrypt chacha20 optimized
implementations).

I wonder if we should add a GNU extension, arc4random_insecure or whatever,
similar to what systemd does with 'random_bytes' that uses a user-managed
buffer plus chacha20 or any other block cipher.  And document it properly that
it was added as PRNG focused on speed. 

[1] https://man.openbsd.org/arc4random.3
[2]
https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/arc4random.3.html
[3] https://lore.kernel.org/linux-crypto/Ytx8GKSZfRt+ZrEO@zx2c4.com/
[4] https://github.com/systemd/systemd/blob/main/src/basic/random-util.c

-- 
You are receiving this mail because:
You are on the CC list for the bug.