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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
Ach mailing list
[email protected]
http://lists.cert.at/cgi-bin/mailman/listinfo/ach

Reply via email to