I have spend a few recent days at 2015 CCC congress in Hamburg. CCC is the biggest security conference in Europe with 12,000 participants, and potentially more [tickets were sold out].

Most talks I have attended were really good! 90% are really excellent.
CCC is IMHO also the best security conference in Europe. A place like no other, where you get to learn a lot about real-life cyber-security. But not everything was to my taste.

Real-Life RNG Security For Dummies

Filippo Valsorda, a crypto developer known for exploration of some serious vulnerabilities [e.g. HeartBleed test or showing how RNGs fail very badly]  has apparently decided to stop being a hacker (showing how not to do security).
Now he decided to educate the public about how to make a secure random generator and explained that we need to stop worrying!!!

Do Not Stop Worrying About RNG Security

As a university security expert who taught computer security and applied cryptography for a decade now, author of several publications about how RNGs fail and fail again, and due to my industry RNG experience, I must say this recent talk is not exactly what I would call good security advice.

 

 

 

 

 

 

 

The author has studied the source code of dev/[u]random in Linux [a good start!] and found that it is a PRNG in which system events are used to add entropy to the pool. He also remarked that the system has no counter [which is hard to implement and could be hacked, good remark], which is something he would recommend to use [one single random number could be then used to generate unlimited amount of randomness in a counter mode].

He explained the [well-known] difference between dev/urandom and dev/random.

The difference is the blocking behaviour. The file dev/random will not provide many bits if the entropy pool has not been modified by a sufficient number of events which add entropy to the pool.

He claimed that the blocking behaviour of dev/random is ‘totally useless’.

Right Or Wrong?

His argument is that in cryptography we have secure stream ciphers just for that. Yes, even rather basic and inexpensive cryptography solutions can produce unlimited quantity of secure randomness from a seed/initial pool of fixed size. Yes a counter mode and a hash function as in Filippo proposal also does the job at least equally well. Yes a hash function such as SHA1 which is what Linux uses to obtain outputs from the entropy pool is a secure design provided that just one bit in SHA1 input changes. This even though dev/random uses simpler mechanisms to update the internal memory pool, as many stream ciphers do. All this is correct. HOWEVER.

This is correct in cryptography, but totally wrong in the real life, and totally wrong in crypto engineering.

Consider for example encryption. Again, yes, standard cryptography can encrypt unlimited quantities of data with one short key. However. The reality is almost no real-life cryptographic system I have ever heard of [and I teach applied cryptography]  uses the same encryption key for a long time. Frequent re-keying is the norm in the industry since ever [WW2 Enigma,GSM, 3/4G,Bluetooth encryption etc..].

In the same way, many real-life random number generators behave as in Linux: they continuously upgrade their entropy pool. There are good reasons for that. No Linux security engineers, however basic their designs are, are not idiots. They monitor entropy entering the pool for a reason.

The reason is something which we now call a post-Snowden attacker.
Or just what the attacker always was for security engineers, except in “pure mathematical crypto technology push” research [which people love to ignore real-life security and are frequently happy with provable security even though assumptions on the adversary are not realistic].

Now a post-Snowden attacker is NOT about just predicting the next/previous bits of the RNG or recovering the seed, all the things which become impossible with cryptography at an affordable cost.

It is about more practical attacks such as:
recording the state of the pool at different moments in hidden locations inside CPU, OS, file system, your hard drive. Stealing the pool state with side channels, malware, covert channels, BIOS SMM code, or air-gaps.
Then brute force [insufficient] entropy entering the pool between these moments(!) based on some captured randoms generated some moment after the captured data.

This brute force attack is the reason WHY you would count the bits of entropy which enter the pool. Linux developers are doing the right thing. We do not claim Linux RNG is secure but it could be secure enough in practice and using dev/random IS a good idea, rather than the dubious proposal using a counter mode outlined in this talk, which I would not recommend to my worst enemy. It simply makes it super easy to compromise A LOT of random bits by capturing very little data.

More About Building Secure RNGs

Here are some of our [older] slides about how to design RNGs in various applicative contexts which can range from pure software to [secure] hardware environments. We do not claim that these slides are the best reference on this topic, but they represent the idea of robust crypto and security engineering with focus on realistic attack scenarios, and there are some further references recommended inside.