1. My conlusion is a such that a secure implementation of a PRNG had to be blocking or returning an error code when it is too little entropy. If a PRNG does not do so it means that it cannot be secure- we cannot be sure that returned pseudorandom bits "comes" from true random bits (achieved with a sufficient entropy). Yes?

2. The presentation Understanding and Managing Entropy Usage points PRNG provided by OpenSSL does not reseed itself (a slide 32). Does it mean that in long-running application we have to reseed manually? Otherwise we don't have secure PRNG? If yes, how to reseed? Every minute? Every Hour? Every generated 1024 bytes? How to be sure that a seed was taken when entropy was sufficient?

3. If you know about books/chapters/blogs that covers my doubts let me know!

a secure implementation of a PRNG had to be blocking

A CSPRNG is the cryptographically secure version of a PRNG. Given a good and unknown (to any attackers) seed, then the CSPRNG can run effectively for ever. ChaCha20 or something based around AES can generate oodlebytes of output.

It's a semantic distinction,but you could say that such CSPRNGs should block at initialisation. They should not output anything unless seeded correctly with adequate entropy. And since unknown entropy is sometimes difficult to acquire, there might be a delay before the CSPRNG kicks off. Acquisition of 128 or 256 bits of unknown entropy can be lengthy for some implementations such as IoT devices without on board TRNGs.

Reseeding can be useful however, especially in the case of a desktop computer /server. Such devices allow other processes to execute alongside the CSPRNG. There are currently 263 running alongside my /dev/urandom device. Anyone of them could be spying on me. Regular reseeding is an attempt to mitigate a potential compromise of the inner state of the CSPRNG. If the RNG is running on an IoT fridge in your kitchen, such reseeding is not really necessary.

...how to reseed? Every minute? Every Hour?

Well this is the trick. It will depend on your environment. The CSPRNG Fortuna uses a horribly convoluted, variable timed reseeding and pooling mechanism. A Quantis quantum key distribution system might re-key the conventional side every few minutes. This answer gives the default reseed rate of /dev/urandom as 1 minute. I see no reason why an IoT wine cooler has to reseed at all between power cycles. I don't think that anyone can give you a meaningful reseed period. A piece of advice might be that if you have access to some form of TRNG, you might as well capitalise on it as often as possible.

Although consider that in cryptography rather than simulation, the exact random stream is often closely related to a key and/or IV. Simply swapping out the CSPRNG's inner state after a protocol has been established will suddenly break the session. The protocol will have to be re-established. This adds complexity and computational /network overhead and also applies to OpenSSL. Your session would terminate.

As for further reading, this forum of course. There's much debate under the entropy and CSPRNG tags.

• thanks for your response! I see now that reseeding is not necessary. If we assume that /dev/urandom does not expose a seed, does it mean that we don't need a reseeding? – Gilgamesz Sep 29 '18 at 16:41
• @Gilgamesz I think that you'd reseed if the device could be attacked easily, but again that's not obvious. You can hack a generic PC's /dev/*random, so you reseed. But you can hack the reseed mechanism too. Rather than generalising, the correct approach is probably to identify the exact use case, device and attackers, then determine the security response. Do you have a more specific case in mind that could be asked separately? – Paul Uszak Sep 29 '18 at 16:58
• @Gilgamesz We? Is we a corporation? 256 bits/s of entropy is a lot for an isolated server with no keyboard interaction. I'd be surprised if this entropy rate is achievable. My advice would be to purchase a TRNG through the project and guarantee the entropy. An alternative is to code usage of any internal TRNG via Intel's RDSEED. See software.intel.com/en-us/articles/…. Otherwise you're left with urandom and it's quasi entropy, although most secure connections do this. – Paul Uszak Sep 29 '18 at 18:50
• @Gilgamesz So then type dd if=/dev/random of=/dev/null bs=10000 count=1 && time dd if=/dev/random of=/dev/null bs=32 count=1 iflag=fullblock and then don't touch the machine. It will show how long it takes to generate enough entropy for an AES key. It's not good. – Paul Uszak Sep 30 '18 at 13:30
• @Gilgamesz Well it's the typical way for servers. There is still Intel's inbuilt TRNG. You might be able to acquire/write a daemon to pull entropy from that and shove it up /dev/random. Or use it directly. Or code up a Raspberry Pi as a network entropy server using it's inbuilt TRNG. There are many options... – Paul Uszak Sep 30 '18 at 15:51