6 ms·
How do other OSes handle this "lack of entropy at startup" problem? (Windows, FreeBSD, OpenBSD, etc.) I've only ever seen this discussed in the context of Lin
by brobinson 5y ago
How do other OSes handle this "lack of entropy at startup" problem? (Windows, FreeBSD, OpenBSD, etc.) I've only ever seen this discussed in the context of Linux.
- tptacek 5y agoIt's not that this is hard to design, it's that it's hard to retrofit given the installed base of weird shit that already cryptically relies on the existing behavior, bugs and all.
- loeg 5y agoIt's kind of both. There's the existing behavior, and also it's also just sort of impossible to solve on some of these weird archs with nothing unpredictable going on.
- hypertele-Xii 5y agoI wasn't aware randomness had behavior.
- shmageggy 5y agoThey both use a system with multiple entropy pools, and incoming entropoy is distributed over them in a staggered fashion such that eventually one of them will accumulate sufficient entropy. You'll notice there is discussion in all of these Linux patches/blog posts about eventually moving to such a design because entropy estimation is too hard and full of pitfalls. I thought that neither try to estimate entropy, but I see that apple provides a blocking getrandom(2) system call, so maybe they additionally do some entropy estimation alongside the Fortuna design? They are both very well documented (pdf): https://download.microsoft.com/download/1/c/9/1c9813b8-089c-4fef-b2ad-ad80e79403ba/Whitepaper%20-%20The%20Windows%2010%20random%20number%20generation%20infrastructure.pdf https://download.microsoft.com/download/1/c/9/1c9813b8-089c-... https://www.schneier.com/wp-content/uploads/2015/12/fortuna.pdf https://www.schneier.com/wp-content/uploads/2015/12/fortuna....
- andbberger 5y agohow does the kernel estimate entropy?
- loeg 5y agoThe entropy pool design protects against some attacks, but, critically, it actually makes this boot-time initial seeding problem harder because you need to gather a lot more total entropy (spread over all pools) before the initial pool has enough bits, vs a non-staggered design.
- pfortuny 5y agoIIRC Open BSD saves a seed each time the system is turned off. Of course, thebvery first boot is problematic, but this one tends to be the installation.
- loeg 5y agoSaving a seed on disk is fine (and good), but orthogonal to the Fortuna entropy pool design. FreeBSD does the same, but not every bootloader can put it in kernel memory. And/or not every configuration has a writeable /boot. Writing some entropy from the previous boot (or installer) would be helpful for a similar set of Linux systems, but would not solve the problem in the hardest cases. And Linux userspace is developed by a different group than kernel, so it is somewhat harder to make these kind of systemic changes than in BSD land.
- tremon 5y agoSo does Linux (although by default it only seeds it after initial boot, so doesn't help with boot-time seeding), but the problem is that the seed must be trusted. Which may be true (or true enough) in a number of specific cases, but it's not true in general.
- tytso 5y agoIn practice it's not hard that hard to solve if you only are supporting a limited number of CPU architectures (e.g., all the world's x86) or only one bootloader. Even if some of the BSD systems support multiple architectures, in practice, they are mostly used only in x86 servers --- and are mostly judged by how well or poorly they work on x86. In contrast, Linux has to work on a very large number of embedded architectures, and some of the CPU architectures don't even have a fine-grained CPU cycle counter, let alone something like RDRAND. And some architectures have practically no peripherals that provide unpredictable input, and some of them very cleverly generate RSA keys and x.509 certificates as the very first thing they do as part of their "out of box" experience. If you can assume that you're always running on x86 architecture, with RDRAND and RDSEED, and pretty much all desktops, servers, and laptops have TPM chips (which have their own hardware random number generator) and are using UEFI boot (which also has a random number generator) --- and while maybe one of these are either incompetently designed, or backdoored by either the NSA or MSS, hopefully not all of them have been compromised, it's really not that hard. The challenge has always being on the crap embedded/mobile devies, where manufacturers live and die based on a tenth of a penny in BOM costs..... (and where they tend to have hardware engineers writing firmware and device drivers, and contractors implementing their Minimum Viable Product, and no one ever goes back to retrofit security....)
- dehrmann 5y ago> Even if some of the BSD systems support multiple architectures...In contrast, Linux has to work on a very large number of embedded architectures Doesn't NetBSD target an absurd number of platforms?
- loeg 5y agoIn FreeBSD, we're equally screwed on these architectures with no good source of random data and no ability to persist some entropy from a previous boot.
- gbrown_ 5y agoThere’s a nice overview of OenBSD’s RNG system here[1] or video if you prefer [2]. [1] https://www.openbsd.org/papers/hackfest2014-arc4random/index.html https://www.openbsd.org/papers/hackfest2014-arc4random/index... [2] https://m.youtube.com/watch?v=aWmLWx8ut20 https://m.youtube.com/watch?v=aWmLWx8ut20