0

We have OpenSSL on BealgboneBlack Based Embedded Linux custom board and we were thinking about increasing randomness of PRNG(/dev/urandom).

While browsing about it, I landed on this page: How to speed up OpenSSL/GnuPG Entropy For Random Number Generation On Linux

That talks more about speeding up entropy for OpenSSL, but I am not sure whether will that /dev/urandom more "random".

Any suggestions if Haveged is good path to start investigating and using?

If not, any other solution for increasing entropy?

I am not sure how to even test that thing, any suggestions about that?

Vilican
  • 2,703
  • 8
  • 21
  • 35
ART
  • 273
  • 1
  • 2
  • 9

2 Answers2

3

Just use /dev/random normally.

/dev/urandom in its default state is more than sufficient for all security purposes, unless you require strong random numbers in an early-boot environment on a small embedded device. In such a case your embedded device requires a hardware random number generator (HRNG) to improve early-boot entropy. This is a physical restriction of information entropy rather than an implementation issue within Linux.

The code behind the urandom block device, in any modern Linux kernel, is designed to be resistant against entropy pool exhaustion. Outside some very extreme and unrealistic scenarios there is no good reason to mess with the implementation or attempt to feed additional data into the entropy pool.

Polynomial
  • 132,208
  • 43
  • 298
  • 379
  • is there any way we can validate/test the entropy availability in system? will it be reading entropy from proc and reading random number and checking entropy again in the loop in some kind of script? – ART May 12 '17 at 03:12
  • The `/dev/urandom` block device outputs random numbers from a PRNG based on AES-CTR, which is considered secure for cryptographic use. It is keyed by data from `/dev/random` (or rather internal APIs which are exposed to userspace by the `/dev/random` block device). You do not need to do any entropy checking in userspace as it is all handled for you in the kernel, aside from the edge case of early-boot entropy collection, which is a niche case that you should only be concerned about if you are designing an embedded system without a HRNG. – Polynomial May 12 '17 at 13:45
  • I recommend reading Thomas Pornin's answer [here](https://security.stackexchange.com/questions/2604/evaluating-the-entropy-gathering-in-a-prng?rq=1) if you'd like to learn more about entropy and measuring it. – Polynomial May 12 '17 at 13:46
  • Based on AES-CTR, what? In the past, it used a SHA1 mixing operation. Now days it uses a ChaCha20 stream cipher (called the CRNG). I'm not sure where you got the idea that it used AES. Furthermore, `/dev/random` does not key `/dev/urandom`. Rather, they are both keyed by a "hidden" internal entropy pool called the input pool. A "catastrophic reseed" of a configurable size (64 bits by default I think) allows the input pool to key both the blocking and nonblocking pool. The difference is that the blocking pool will, well, block when the entropy estimate gets too low. – forest Dec 09 '17 at 08:51
  • @AnkurTank I believe if you enable FIPS mode, a rather basic RNG self-test will be done that will panic the system on duplicated output. It's not really necessary though, since the randomness driver is heavily audited and well-designed. – forest Dec 09 '17 at 08:54
-1

You could always delete /dev/urandom and make it a symlink to /dev/random. Hardware random number generators exist if you don't think that urandom is good enough, and you should be able to point haveged to the hwrng.

user148021
  • 1
  • 3
    Sounds like a great way to slow down your computer to a crawl. – CodesInChaos May 11 '17 at 16:11
  • I agree, but the asker wanted to make urandom more random for some reason. For embedded systems I'd say a hardware random number generator is one of the only ways to go if you can't wait for entropy. – user148021 May 11 '17 at 17:55
  • I didn't understand the advantage of pointing haveged to hwrng, is it to increase entropy ? if yes why not for PRNG(urandom)? – ART May 12 '17 at 02:58
  • This doesn't work and is a terrible idea. `/dev/random` is a legacy artefact kept only for compatibility reasons. `/dev/urandom` is the appropriate block device to use for random numbers. – Polynomial May 12 '17 at 13:43
  • Specifically, `/dev/urandom` handles re-keying of the internal CSPRNG automatically and the implementation has been carefully audited. The `/dev/random` device will block when the entropy estimation in the kernel is low which, as CodesInChaos pointed out, would cause all sorts of horrible performance and stability issues on your system. – Polynomial May 12 '17 at 13:49
  • This doesn't "make it more random". The only time `/dev/random` would be superior is if 1) you need information theoretic randomness (meaning you fear a preimage attack against SHA1... unheard of), and 2) you trust the entropy estimator to be accurate. I can't think of any situation in which these would hold true, except perhaps if you wanted to create a one-time pad (which is stupid 99% of the time anyway). – forest Dec 09 '17 at 08:53