Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Uniting the Linux random-number devices

lwn.net

Post reply on HN
Print view View original

31–40 of 63 posts

Re: Uniting the Linux random-number devices

#31

Post by zx2c4 »

stingraycharles wrote: post #27
zx2c4 wrote: post #19

I just sent a v1 of this patch: https://lore.kernel.org/lkml/20220217162848.303601-1-Jason@z... We'll see if that elicits any real objections. Hopefully not, and this will be part of 5.18!

Seems like a no-brainer to me; as I understand, this effectively make urandom “always secure”, which is a very good thing; makes for an even more convincing argument when some colleague insists on using /dev/random “because it’s more secure”. Do I understand correctly that with this patch, the only drawback is for weird architectures that do not have an instruction counter or another instruction to gather random data…

Right, it unifies /dev/urandom, /dev/random, and getrandom(flags=0) to all do exactly the same thing.

Most modern userspaces already use getrandom(flags=0). Nothing changes for them. They already count on the rng being seeded in one way or another.

Rather, this changes /dev/urandom, which previously would give insecure randomness before being seeded. With this change, this doesn't happen any more, because it makes /dev/urandom wait until it has been seeded.

In practice, the RNG get seeded by a large variety of things. As a last ditch effort, the Linus Jitter Dance will seed it.

Taken together, what all the above amounts to is that the regression potential is limited to systems where: (A) /dev/urandom is still being used, rather than getrandom(flags=0), (B) the boot sequence, due to some bug, hard-depends on unseeded reads from /dev/urandom, (C) no ordinary sources of entropy, such as interrupts and input devices and disk drives, are available, (D) the CPU is so ancient as to be missing a cycle counter, defeating the last ditch Linus Jitter Dance, and (E) a new kernel will be installed on this old system.

I argue that the set of machines where (A), (B), (C), (D), and (E) all hold is minuscule.

Re: Uniting the Linux random-number devices

#32

Post by daneel_w »

loeg wrote: post #28
daneel_w wrote: post #12

Earlier quoted context omitted.

The bootloader seeds the kernel from disk, the kernel continually mixes data into the entropy pool from various sources. arc4random(), which provides for kernel/userspace/devices (including /dev/random which is symlinked to urandom), can never block. Add.: the seed file is unique per installation, and is also updated continously by the system.

Seed files are useful, but not a perfect solution, because they can be snapshotted or cloned in a virtual machine context, or otherwise shared/leaked. Also, they require a device to have writeable memory, which again does not work in all contexts. I don't think trying to spin this as "OpenBSD solved this years ago" is especially helpful. OpenBSD has made a different set of design tradeoffs than the Linux authors, and…

I don't understand what you mean by "trying to spin this", or how that, whatever it means, is not helpful. Helpful towards what? Admittedly I don't know if there has been a successful effort that breaks or otherwise proves OpenBSD's non-blocking solution as insecure, but I'd be glad to read any conclusions if you have any to share - it's why I asked about the reasons behind Linux developers' objection to the solution.

Re: Uniting the Linux random-number devices

#33

Post by adgjlsfhk1 »

goalieca wrote: post #6
Dork1234 wrote: post #3

Can Linux use Hardware RNG devices? Are these devices able to generate enough bits of randomness to work for boot?

I do wonder if _fast_ quantum rng sources will become ubiquitous outside mobile applications.

I doubt it. even if algorithms like sha get almost totally broken, you could get away with injecting a tiny number of bits of true randomness (like 1 in 2^20) and the result will be uncrackable.

Re: Uniting the Linux random-number devices

#34

Post by daneel_w »

dspillett wrote: post #24
daneel_w wrote: post #18

Earlier quoted context omitted.

Nor can OpenBSD. The system doesn't crash if /etc/random.seed isn't writable.

But what if it wasn't writeable recently but has been in the past? How do you know that the seed data isn't stale and you are starting up the entropy pool in exactly the same state as last time, and the time before that, and ... In some security contexts this could be a significant concern.

The seed file will go stale if you deny the system to update it. It's the first source for the entropy pool, but it's not the only source. I really have no idea how large effect the random subsystem suffers as a whole if that source is allowed to go stale.

Re: Uniting the Linux random-number devices

#35

Post by benchaney »

daneel_w wrote: post #8

OpenBSD solved this problem long ago. Is the reason behind Linux' hesitancy/opposition to their solution of technical or philosophical nature?

I had heard that the concern was that there are services very early in boot that rely on /dev/urandom never blocking. I’m not sure how true that is, or why it is no longer a concern now.

Re: Uniting the Linux random-number devices

#36

Post by an_d_rew »

zx2c4 wrote: post #19

I just sent a v1 of this patch: https://lore.kernel.org/lkml/20220217162848.303601-1-Jason@z... We'll see if that elicits any real objections. Hopefully not, and this will be part of 5.18!

Jason, you buried the lede! :-)

Very nicely put, and thank you for putting that together!

This patch goes a long way toward eliminating a long overdue userspace crypto footgun. After several decades of endless user confusion, we will finally be able to say, "use any single one of our random interfaces and you'll be fine. They're all the same. It doesn't matter." And that, I think, is really something. Finally all of those blog posts and disagreeing forums and contradictory articles will all become correct about whatever they happened to recommend, and along with it, a whole class of vulnerabilities eliminated.

With very minimal downside, we're finally in a position where we can make this change.

Re: Uniting the Linux random-number devices

#37

Post by SAI_Peregrinus »

neatze wrote: post #22
zx2c4 wrote: post #21

Earlier quoted context omitted.

No changes. Totally unrelated.

I meant /dev/urandom, sorry. Do you mean it is in reverse, in sense what getrandom() would be using ?

Still no changes. /dev/urandom will block until first seeded at boot. By the time you can run `dd`, it's seeded, because the system needs to have booted for that.

Re: Uniting the Linux random-number devices

#38

Post by throway_zwudbo »

zx2c4 wrote: post #19

I just sent a v1 of this patch: https://lore.kernel.org/lkml/20220217162848.303601-1-Jason@z... We'll see if that elicits any real objections. Hopefully not, and this will be part of 5.18!

This is probably way outside of my sphere of competence, but....

If your approach is adopted, people would simply treat /dev/random and /dev/urandom as the same thing (which I gather is your intended goal). That is fine as long as CSPRNGs are relatively easy to make. I hear that this hinges on fancy theorems like P=BPP being true, but apparently they're not proven yet.

What if... in some parallel universe it turns out that P!=BPP, and the concept of CSPRNGs is fundamentally broken, and somebody discovers a practical method to break whatever PRNG is implemented in a system? In this admittedly unlikely universe, keeping the distinction between /dev/random and /dev/urandom (i.e. the former could block indefinitely, the latter could be insecure) seems to be the safer approach. Of course in this universe, Linux would still have to pull the PRNG from /dev/random and revert back to the old behavior, but at least it's fixable. But if userland drops the distinction between /dev/random and /dev/urandom, then the problem would be fundamentally unfixable until every app reviews and decides which guarantee they want for themselves (and releases patches).

Of course your patch does not really imply the contract between the kernel and userland has changed, which is why I mentioned intention. If it is intended to change the contract, maybe it's better to wait for P=BPP before you do it? :P

Re: Uniting the Linux random-number devices

#39

Post by zamadatix »

daneel_w wrote: post #17
pdw wrote: post #13

Earlier quoted context omitted.

Linux is used in many more contexts than OpenBSD. Moreover, unlike OpenBSD, Linux explicitly promises not to break userspace on new releases. So yeah, the Linux devs are more hesitant about anything that might be a user-visible behavior change.

OpenBSD never removed /dev/random - though they did remove arandom and prandom. But I'm not sure how your response explains the reasons for why they avoided OpenBSD's solution.

OpenBSD behaves like this patch, the article does a good job of describing what it has taken on the Linux side to get to this point and why IMO. In particular it wasn't until recently there was a reliable way to get quick randomness on nearly any machine to avoid blocking for long periods on boot which things had come to expect avoiding in the previous implementation.

Re: Uniting the Linux random-number devices

#40

Post by DenseComet »

throway_zwudbo wrote: post #38
zx2c4 wrote: post #19

I just sent a v1 of this patch: https://lore.kernel.org/lkml/20220217162848.303601-1-Jason@z... We'll see if that elicits any real objections. Hopefully not, and this will be part of 5.18!

This is probably way outside of my sphere of competence, but.... If your approach is adopted, people would simply treat /dev/random and /dev/urandom as the same thing (which I gather is your intended goal). That is fine as long as CSPRNGs are relatively easy to make. I hear that this hinges on fancy theorems like P=BPP being true, but apparently they're not proven yet. What if... in some parallel universe it turns ou…

Applications trust /dev/urandom to be secure. If your scenario ends up being true, then instead of /dev/random acting like /dev/urandom, /dev/urandom should act like /dev/random since it is supposed to be secure, and we're back to having no distinction between the devices.
Post reply on HN