Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Browse files
Browse the repository at this point in the history
remove dangerously out-of-date Linux/haveged info
- Loading branch information
Showing
2 changed files
with
0 additions
and
56 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
cf7cef7There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have any more information as to why this information is out of date and why the use of haveged is dangerous?
cf7cef7There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe someone could send an email to the maintainers listed on the Havege project ?
https://www.irisa.fr/caps/projects/hipsor/contact.php
cf7cef7There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@fmarier
See: https://lists.cert.at/pipermail/ach/2017-May/002251.html
..and follow-up discussion on the mailing list. Most decisions are discussed on the mailing list, not GitHub per se (we will reference ML discussion at times on GitHub and GitHub issues vice versa on the mailing list).
@Harvester57
Please go ahead and do so. The project seems barely maintained for years.
cf7cef7There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@azet
Done, waiting for an an answer
cf7cef7There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
cf7cef7There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cf7cef7There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry but how does it's performance and security compare to the recent changes in the Linux Kernel's CSPRNG implementation, which is solid and very fast? I'm not sure why we should recommend using
havegedon Linux systems instead. FreeBSD has been fine for a long time until they fucked up a patch regarding AESNI - but that has been fixed too. So I don't see whathavegedwould provide in comparison to current implementations of OS CSPRNGs?We've had this discussion on list and I think it makes far more sense to keep it on there.
cf7cef7There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cf7cef7There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh I forgot to mention I talked about this issue back in 2017 at SHA and hack.lu:
a couple of people came up to me afterwards with their own custom implementations for "entropy" gathering daemons, some silly, some pretty solid, but they're still by far not as good as what the Linux kernel ships per default these days (and has been for quite a while now). Until the interface will be closed to the unwitting public -- writing to the random device still interferes with the operating systems' CSPRNG, which is really not a good idea to do.
I've heard privately of exploits for various RNGd's -- I can't say anything more and don't have my own exploits of them, mostly because this is a topic I don't want to waste tons of time and energy on as very few people actually use them.
cf7cef7There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@azet in some environments, the user might be forced to use an older linux kernel (enterprise linux distribution, embedded space)
I have been recommending "haveged" and "rngd" for virtualized environments in the past.
In some VM environments, there is almost no entropy coming from /dev/random. Generating keys in these environments can take a very long time. Using /dev/urandom is sometimes not an option.
What alternatives to havege exist?
Is "rngd" (https://github.com/nhorman/rng-tools) a better choice (it is actively maintained)?
Red Hat has a (from my point of view, but I'm not an crypto expert) a sensible discussion on the topic:
https://developers.redhat.com/blog/2017/10/05/entropy-rhel-based-cloud-instances/
cf7cef7There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi,
I made a video this morning showing the positive effect of Haveged on the entropy coming out of
/dev/randomon an modern Linux System (fedora 29 Kernel 4.19)https://strotmann.de/~cas/download/78cb4f98bc96e6c10b7294116cc2515f739f6d46204b1c0258b4d58d/Haveged-Linux-4.19.mp4
This machine runs inside a KVM machine, and without Haveged, it has very little entropy. Generating keys will take very long.
With Haveged running, GPG, SSH, DNSSEC or OpenSSL Key-Generation is almost immediately.
I have never seen "hangs" during key generation on a system with Haveged running, but I have seen "hangs" on systems without Haveged.
I maintain a couple of production DNSSEC signing servers, and without Haveged running, there is a danger that the system locks up during a key rollover event.
I understand that
/dev/urandomnow is a good (or better) choice, however software often is bound to/dev/randomand cannot be changed by the user. Also/dev/randomis the portable way to get entropy across Unix systems, at least for now.I'm not defending Haveged, but I see a need for a source of extra entropy on virtual machines (as shown in the video).
If not Haveged, there might be an alternative. Or in absence of an alternative, we (the community) might need to think about adopting Haveged, find a proper maintainer, do an audit.
cf7cef7There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm sorry but using
/dev/randomin general is considered highly unsafe. It's blocking and extremely slow, which can and will cause many applications relying on random input to fail. This interface is not only slow it's deprecated and should not be used for cryptographic purposes as (finally!) documented inman 7 random: http://man7.org/linux/man-pages/man7/random.7.htmljust link to
/dev/urandomand you'll get pretty sweet performance especially on such a new kernel. You don't need an "extra source of entropy" on modern Linux kernels, that's a myth. And it'll only make your operating systems CSPRNG weaker, not stronger. It's like saying you need an extra driver for your Intel NIC because the one upstream is not performant enough, because Intel doesn't know it's own hardware. Even if that'd be the case, it'd be up to the driver maintainers to fix it where it needs to be fixed.I also don't get the concern w.r.t. portability: On BSD and OSX
randomandurandomare the same thing. Solaris behaves similar. And most software needs to be ported for these Operating Systems anyway and will have#ifdefclauses in it for exactly that purpose.https://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/
https://bugs.ruby-lang.org/issues/9569
(...)
cf7cef7There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cstrotm if you really want better /dev/random performance in your VM, and you don't want to use urandom, with KVM, you can create a virtual hardware RNG with the host's /dev/random as backend. Some sample libvirt XML for it:
Then in the VM, have rngd pull from your virtual hardware RNG. You're essentially pooling from the host's /dev/random entropy pool by doing that, if it is acceptable for your use case.
cf7cef7There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hello Aaron,
I get that. But what should be the recommendation for environments where:
a) the user cannot switch the source of entropy in the application, it is hard coded to /dev/random
b) the user is not permitted to change the device links in the Linux system
Do you have a source on the deprecation of /dev/random?
If /dev/urandom is better in all cases, the switch should be done in the kernel or inside the linux distribution.
cf7cef7There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gcs-github I know about KVM and virtual hardware RNG.
Unfortunately creating a virtual hardware RNG in many cases, the clients do not have access to the virtual host (or it might not be a KVM host), maybe because that is managed my a different team inside the organization or is from an external provider.
cf7cef7There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you can bind mount them for example. I agree that distros should do that but most haven't caught up with the kernels developments and then there's always endless discussions like here or with many programming languages that still prefer random or silly custom RNGs (I started or contributed to many change requests for languages and it took ages to convince eg. Ruby to switch). The current Linux man page for the random char device and all related LKML discussions are the reference, that man page caused the myth that random is somehow better and it took quite a while until it was changed although the design of the actual random char device was changed long ago and often improved upon since.
BTW Ruby only finally switched to a reasonable solution after the Linux documentation team changed the random(7) man page. Ignoring expert opinion of many crypto engineers and cryptographers in the relevant change request for years (I linked to all that above in an edit to last my post on GitHub). Python always did the right thing. Erlang still doesn't. Hope that helps. :)
cf7cef7There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In e.g. a VMWare environment you should use/install the vmware-tools in the guest anyway otherwise you'll lose many features of the hypervisor platform, your clock will go out of sync fast and devices won't be hot pluggable. It depends what you use.
The most laughable solution anyone could come up with was canonical and their virtualization layer. They wrote a service called pollinate that was designed to get an initial seed for virtualized guests via HTTP(!), without any proper exception handling. Unsurprisingly no one used that crap for long. Makes it easy for any attacker on the network to change the seed of the OS CSPRNG network-wide. And in the event there's any service outage or problem with it you'll get similar results. Awesome idea!
cf7cef7There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cstrotm I would like to recommend jitterentropy-rngd more details could be found in CPU Time Jitter Based Non-Physical True Random Number Generator paper. This RNG is available as a kernel module since 2015.
There's currently an ongoing effort to add size optimized Jitter-NPTRNG based RNG service/daemon into OpenWrt. It improves the entropy situation significantly on embedded devices and VMs as well.
cf7cef7There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cf7cef7There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ynezz great information, I will check this out. Many thanks.
cf7cef7There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ynezz That's exactly what the RNG in Linux does already, it mixes jitter into it's pools and has been doing so for ages (for an analysis of the 2.6.+ RNG: https://eprint.iacr.org/2012/251.pdf). You won't gain more security by yanking out other pools and security features (including backtracking protection and a lot of other things that have been added recently over the past few years) and replacing them with a kernel module that only implements a few of these features. The CPU-specific jitter feature has been upstreamed in 4.2: https://marc.info/?l=linux-kernel&m=143496272614455&w=2
If this is to be put as a recommendation into the guide: please test this properly on relevant embedded devices, show comparative results with the current upstream kernel and if it actually turns out that there's an improvement in security (Many embedded devices don't even have a high resolution timer, so this RNG won't work well at all on these platforms) for embedded devices this should be clearly stated and not as a general remedy. I highly doubt this is true for VMs, there've been a lot of improvements on the side of hypervisors (at least VMWare and KVM) and how they interact with the guest OS since this has been a hot topic in research. I've been tracking guest OS entropy in multiple big virtualization environments and haven't seen any issues with stable-branch Linux distros (RHEL7, Debian stable,..).
cf7cef7There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A newer in-depth analysis paper of the RNG in Linux up to kernel version 5.1 by the BSI: https://bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/LinuxRNG/LinuxRNG_EN.pdf?__blob=publicationFile&v=13
By the way written by the same person this daemon/module mentioned above is from and that has been working on upstream Linux Kernel RNG improvements together with a few other people (as well as a complete redesign) over the last couple of years.