[Ach] removed outdated info on Linux RNG / haveged

[Aaron Zauner]

Further discussion/fallout from this change on GitHub:
https://github.com/BetterCrypto/Applied-Crypto-Hardening/commit/cf7cef7a870c1b77089b1bd6209ded6525b5a4e0#commitcomment-22594913

On Sat, May 6, 2017 at 5:06 PM, Aaron Zauner <azet at azet.org> wrote:

> Hi,
>
> https://github.com/BetterCrypto/Applied-Crypto-Hardening/commit/
> cf7cef7a870c1b77089b1bd6209ded6525b5a4e0
>
> 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
> 4.9.0-2-amd64
> ```
>
> 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.
>
> Aaron
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cert.at/pipermail/ach/attachments/20170619/1c4cb7bd/attachment.html>