[Ach] removed outdated info on Linux RNG / haveged

[Florian Stosse]

Further insights I posted on GitHub, I forward it there :

Got an answer from Andre Seznec (credited as one of the main authors :
https://www.irisa.fr/caps/projects/hipsor/contact.php)

He replied that, in his opinion, the principles on which HAVEGE and the
haveged daemon are built are still valid, and in fact are more efficient
today given the microprocessors architectural evolution (more complex
architectures and more non-predictable states usable to gather entropy).

He acknowledged that he did not touch the code for +/- 10 years, and I
couldn't not reach the listed maintainer. On Debian, the latest maintainer
upload was on november 2016.

He also pointed out a security warning : with some VMs, the hardware cycles
counter is emulated and deterministic, and thus predictible. He thereforde
does not recommend using HAVEGE on those systems.


Bien cordialement,

Florian STOSSE | Apprenti-Ingénieur sécurité informatique
*Bureau Veritas - Service Sûreté de Fonctionnement | ESIEA Paris*

2017-06-19 6:59 GMT+02:00 Aaron Zauner <azet at azet.org>:

> 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
>>
>
>
> _______________________________________________
> Ach mailing list
> Ach at lists.cert.at
> http://lists.cert.at/cgi-bin/mailman/listinfo/ach
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cert.at/pipermail/ach/attachments/20170710/ab54e67d/attachment.html>