Re: [dsfjdssdfsd] getentropy(2)

[Alyssa Rowan <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 15/07/2014 14:13, Theodore Ts'o wrote:

> I'm arguing that it might be better to have a standardized
> userspace library, ala OpenBSD's arc4random, which takes care of
> all of the OS specific issues, and also provides a crypto-based
> DRBG.  In that case, it saves even more syscalls, since it only
> needs to read entropy from the kernel at application startup time,
> and perhaps periodically every so often when it wants to reseed,
> but not every single time you need crypto-sensitive padding, IV's,
> session keys, etc.

I agree with that entirely - that should definitely be in the libc (we
need to take special care to ensure threads and forks never share a
context of this), and that is of course how arc4random(3) works.


We then have the thorny issue of how to seed it. Failure to seed
should definitely be considered a fatal error (OpenBSD bails with
SIGKILL).

The existing Linux RNG, though it has stood up well to the test of
time if I may say so, does not quite meet the needs of that use as it
stands.

Linux /dev/random estimates incoming entropy and blocks on warmup, but
cools down on output, assuming entropy is removed from the pool when
used. Many non-interactive systems without hardware TRNGs have
insufficient entropy to keep the pool from blocking frequently: it
would be impractical to make this a fatal error.

Linux /dev/urandom is the same, but never blocks - even if the
generator has not received sufficient initial seeding. This is a
problem which has resulted in many predictable keys in the wild,
especially in embedded devices (which are notoriously challenging
environments for entropy collection in the absence of a TRNG, and
which obviously did not collect enough at startup and just winged it).

What Linux doesn't seem to have is something in the middle; that
blocks until it's safely warmed up, but then doesn't need to block
again. That's the approach used by OpenBSD (as far as I know?). It
stops someone calling it before it's seeded, but also has no concept
of 'entropy exhaustion' as the DRBG is secure (hopefully!).

The fact that reading from Linux's RNG currently requires device file
accesses means access is not atomic and is dependent upon the finite
resources of file descriptors, as the libReSSL developers have clearly
pointed out.

I agree a better approach would be to have a syscall such as
getentropy(2) which:
- - requires no special privileges
- - provides a small amount of data into a provided buffer from a kernel
  CSPRNG (40-256 bytes, ish)
- - iff it has been correctly seeded beforehand with sufficient collected
  entropy
- - returns an error (ENOENT?) if it has never been insufficiently seeded
  to operate securely
- - otherwise does not error (except if an invalid buffer or byte count
  is given) or block
- - does not reduce the entropy estimate in the accumulated buffer (the
  DRBG should be cryptographically secure so this is not a problem)
- - is suitable for seeding arc4random(3) or another CSPRNG, or for
  direct use if only small quantities are required
- - is atomic and uninterruptible

and then libc can use that to seed arc4random(3) using ChaCha20 or
another very good DRBG (i.e. not RC4!) and hopefully everyone can swim
in a sea of quite fast, long-term-key-grade random numbers.

If a blocking/pure-entropy mode analogous to /dev/random is required,
I think the best approach would be to run a second CSPRNG in parallel
which does reduce the entropy count when queried - and its first
secure output could be used to kickstart the main kernel CSPRNG, which
would be a reasonable implementation in practice I think.

I don't think a mode analogous to current /dev/urandom should be
provided, because it can be run completely unseeded. If someone wants
a non-cryptographic PRNG, they can do it much faster in user-space.

Of course, that is just my opinion, this isn't LKML but more of a case
study/general discussion here, and I am aware over the decade the
generator has been in Linux you've seen _plenty_ of opinions. :)

- -- 
/akr
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTxW5/AAoJEOyEjtkWi2t6FVQP/jjPdnn5KozDhiMaY2e5Ohy9
evQc7kZpgF9z0ZWVhx1LUd6o1WMmgUqDa/rnA+Py0R/s7XMg6zuuuUMagLB/YoB0
C3i1E2A1OywnzJAaX6Q31jCyYyIvr8nP2zWdl41cn5NU8kmR0odduuPMgders7bT
4wA6W687qr9ABDolUy9+zNMBfFo/UF8eXn6FBMgdnobNf5OJCqmpmv1RDBFTc80W
e4Fhn34r0fAtWRxj+nyC5zAK9HwlKapV1w8HcxLK175rdEfNQAJoalJ19UfgXLvd
+w2uohF3uA4UFBlhqvW2UoM9ZTfmbmi2Zr8P/ak0p4rc/2Vg6GU/OLEciqkaHBtE
CFgCNbYM0N5JhgAc4pW5Gk4AnoH1xUQLgqNHxsjOji1KeHWTTyk0ZaK1n2fskEXl
/Av4z8xmfyXHeus56igtfb82bEhERddUFXixaXbHbxq5KswLiYMQ5rAnTojJZkZz
aroZ3V5DPKgIC1yp5YlyJH0YDbGfq3yQ+nKOA3HqDZze7euks3h6/IG0T8mkGEhv
sH340xwJqc309n8V3507i+c4ECRMlM3SEBpYpWvGFBRM3Im/1Ah98N2IX9x15rON
HsK/tZEyhi98ewd/NPAzgXrVRPTXh5zyGG2S5Ep4ViYMVGKLhQbiNjrqcynYclKc
zC9z8ddoGFhcURcifsu0
=U9FN
-----END PGP SIGNATURE-----