5
$\begingroup$

I'm referencing Jason A. Donenfeld's Random number generator enhancements for Linux 5.17 and 5.18 available here. In summary:-

significant outward-facing change is that /dev/random and /dev/urandom are now exactly the same thing, with no differences between them at all...

So entropy is collected at boot, ChaCha's state is seeded and off we go ad infinitum. My /proc/sys/kernel/random/entropy_avail always reads 256 bits as might be expected of a PRNG.

The question is thus: are USB keys (e.g. TrueRNG3) providing any benefit with regard to the state of the Linux RNG? Are they even used at all? The manufacturer's site is well out of date. That particular hardware appears as /dev/TrueRNG and I can read from it manually, but does the new /dev/urandom?

I can't tell whether or not it may be used for re-seeding. Looking at military key generators suggests that they bypass the OS entirely and read directly from their hardware, introducing further doubt over how \dev\urandom seeds.

I've written to Jason regarding this matter but as yet had no reply.

Improve this question
$\endgroup$
3
  • $\begingroup$ Maybe this link will largely answer your question? It's pretty old, but I presume you can still write to /dev/random so I also presume that this answer is still viable (but yeah, try!) $\endgroup$
    – Maarten Bodewes ♦
    Commented Mar 27 at 19:38
  • 1
    $\begingroup$ TRNG's are useful for one-time-pads (OTP with /dev/random isn't going to be OTP, it will be a stream cipher with extra steps) or when compliance is important, for example in gambling random number generation. $\endgroup$
    – Jackie Lanhorn
    Commented Mar 27 at 20:01
  • $\begingroup$ @JackieLanhorn I'm presuming that Paul means "benefit" in the sense that it helps the PRNG retrieve entropy within Linux, e.g. in case you don't trust the other entropy sources. Of course you can always read from the device. Paul, is that assumption correct? $\endgroup$
    – Maarten Bodewes ♦
    Commented Mar 27 at 20:16

1 Answer 1

Reset to default
2
$\begingroup$

In modern Linux versions, hardware TRNGs are supported by the kernel by exposing them through /dev/hwrng. Assuming you have such hardware, the userspace rng-tools package can read from it (or another device or a fifo), perform some statistical tests on it, and feed it to the kernel entropy pool. It will be accumulated there, along with any the kernel normally collects and any on-chip TRNG (such as RDRAND or RDSEED), and distilled normally as part of the BLAKE2 hashing process.

Now, assuming you've appropriately collected 256 bits of entropy already on boot, you don't need it for proper functioning; /dev/random will never block in such a case. However, it can be helpful if you would like to add more randomness in case of a pool compromise or if you're on a VM or a system with low entropy where enough randomness might not be collected normally at boot.

On VMs specifically, the virtio-rng driver provides a fake TRNG based on the host kernel's random pool to allow a fast, efficient bootup, so this tooling and functionality is in fact in active use.

Improve this answer
$\endgroup$
1
  • $\begingroup$ Err, rng-tools is now deprecated following the (u)random merger so not sure if it still works. I can't tell. $\endgroup$
    – Paul Uszak
    Commented Mar 29 at 13:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.