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 <[email protected]> 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 >
_______________________________________________ Ach mailing list [email protected] http://lists.cert.at/cgi-bin/mailman/listinfo/ach
