Hacker News Reader

Comment by brobinson | Hacker News Reader

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.

View on HN

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

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

OpenBSD also still targets like 7 or 8 arches and did some bunch more a while ago

As does FreeBSD, and of course those non-x86 platforms are where the pain points are re: RNG -- same as Linux. Tytso is just unfamiliar with the BSD landscape.

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

https://www.schneier.com/wp-content/uploads/2015/12/fortuna....

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

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

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

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

how does the kernel estimate entropy?

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

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

I wasn't aware randomness had behavior.

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

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

[2] https://m.youtube.com/watch?v=aWmLWx8ut20

Reply on news.ycombinator.com