[Ach] removed outdated info on Linux RNG / haveged

Aaron Zauner azet at azet.org
Sat May 6 17:06:03 CEST 2017



We still have a section that conveys wrong information about kernel entropy in Linux (parts have never been correct). Also the use of `haveged` is recommended, which is a bad idea as this daemon can create blocking situations during key generation effectively creating a deadlock and thus security problems. haveged's design is from 2002, it has never been audited, there're only papers by the original authors available. Additionally, the design rationale is based on 2002 ISA for architectures like UltraSparc II - these are far from relevant these days. The removed section already mentioned that haveged's memory footprint is too high for embedded use-cases, additionally in most embedded boards the design will not even work.

Linux 4.9+ has a new design for `/dev/urandom`: it XORs RdRAND/SEED with ChaCha20 (this design is borrowed from Adam Langley's implementation in BoringSSL, also used in libsodium) thus providing a fast and save interface for cryptographically secure pseudo random numbers.

% dd if=/dev/urandom of=/dev/null bs=1M count=1024 ; uname -r
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.22117 s, 254 MB/s

The removed section also used to say:
Unfortunately most crypto implementations are using \verb+/dev/urandom+
and can produce predictable random numbers if not enough entropy has
been collected~\cite{HDWH12}.

This is simply wrong and misquotes the information provided in the cited factorable.net paper (compare to "Experiment" in Section 5.1).
The issue of "boot time entropy" only affects the very first boot-up of a machine or VM. States are saved across reboots.

I've taken the liberty to remove the section as I find it dangerously misinformed. Discussion welcome.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.cert.at/pipermail/ach/attachments/20170506/e0b5db16/attachment.sig>

More information about the Ach mailing list