On 2017-07-11T18:53, Alice Wonder <[email protected]> wrote: > > > On 07/11/2017 09:00 AM, Aaron Zauner wrote: > > > On 10 Jul 2017, at 10:35, Florian Stosse <[email protected]> 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. > > Please just stop. > > Give an acedemically sound (as in published exploit or peer reviewed paper) > demonstrating a flaw in haveged or just stop.
That would not matter, since even if haveged were flawed, the only thing it could do (at least when using it to refill /dev/(u)random) would be to screw up the entropy estimate of /dev/random, thus making it block less often. Which isn't really too much of a problem. Refilling with predictable entropy doesn't magically make the entropy pool go bad, except if one assumes that the mixing function is reversible, which would imply cryptographic hash functions or ciphers being predictable. That would be a 'we are screwed anyways' scenario. Or if the mixing function were bad, which is also synonymous with 'we are screwed'. Which means that haveged doesn't make anything worse entropy-wise, except reduce the blocking behaviour by /dev/random. On the other hand, haveged also doesn't really make anything better, at least Linux has used interrupt timings as a source of entropy for ages. Haveged relies on L1 cache timings, which are roughly derivatives of those interrupt timings plus some additional CPU nondeterminism. L1 misses occur more often than interrupts, however, the collection of timings in haveged is necessarily more limited than in the kernel. So I don't see the quality advantage of haveged's entropy gathering. Also, in more primitive embedded systems that are the usual suspects for low entropy at boot time, L1 cache timings are necessarily more predictable. So, in the entropy aspect I think it doesn't hurt, but doesn't help either. But... > Change for the sake of change is idiotic. There is another thing besides entropy to consider here: The very existence of 'yet another service that does stuff' is generally considered a problem in systems administration and security. More code is more attack surface and more stuff that can go wrong. So if that code is also useless, one should prune it. Theoretically, if one is given to paranoia, there is also another argument against haveged, from the original HAVEGE paper[0]: "In practice, the security of the HAVEGE generator relies on both the unfeasibility of reproducing its internal state, and on the continuous and unmonitorable injection of new uncertainty in its internal state by external events." Both arguments also apply to the entropy gathering of the operating system kernel. However, the OS kernel is in a far better protected position to hide its internal state and gather events, compared to a userspace process like haveged. Haveged is more vulnerable to such (admittedly somewhat hypothetical) attacks[1]. Btw. is there any reference regarding those deadlocks that haveged supposedly could produce according to https://lists.cert.at/pipermail/ach/2017-May/002251.html ? Ciao, Alexander Wuerstlein. [0] http://dl.acm.org/citation.cfm?id=945516 [1] Or maybe not that hypothetical, there are quite a few side-channel attacks on RSA multiplications based on cache timings. So I would consider it at least possible (especially compared to what we knew about cache timings compared to 2003) that there might be a problem... But I'm not sure, I'd have to think on it a bit longer. _______________________________________________ Ach mailing list [email protected] https://lists.cert.at/cgi-bin/mailman/listinfo/ach
