[Ach] removed outdated info on Linux RNG / haveged

Aaron Zauner azet at azet.org
Tue Jul 11 18:00:19 CEST 2017

> On 10 Jul 2017, at 10:35, Florian Stosse <florian.stosse at gmail.com> wrote:
> 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).

Has the author taken a look at how CSPRNGs are implemented currently in Linux, FreeBSD, OpenBSD and Windows? I don't think HAVEGE's concept is still valid. We have high speed, high-security CSPRNGs now in every major operating system, without the need for additional user-land daemons that are prone to exploitation, user-error or bugs. Please correct me if I'm wrong. Where do you see the benefits of using HAVEGE over - say - Linux's `urandom` char device as implemented in Linux 4.x?

> 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.

With security critical code - at least for me - this is a clear no-go. I would not recommend using this piece of code professionally nor would I in any open-source project. As far as I can see and have researched; there has never been *any* audit of said code except for the original authors security analysis. Again, please correct me if I'm wrong and missed a publication or blog post.

> 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.

I'd say the majority of systems use VMs in one or the other way these days. Hence recommending HAVEGE in general should be clearly avoided. Again this is a no-go. Do you have specifics on which VMs are meant by that statement? That'd be interesting.

Thanks for your efforts in contacting the original author(s),
-------------- 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/20170711/a856aff1/attachment.sig>

More information about the Ach mailing list