Uniting the Linux random-number devices • Hacker News Board

Re: Uniting the Linux random-number devices

#61

Post by dspillett » Fri, Feb 18, 2022, 11:14 AM UTC

tedunangst wrote: post #51

dspillett wrote: post #24

Earlier quoted context omitted.

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.

How do you know somebody hasn't hex edited the kernel to nop out the rng entirely?

You usually don't, unless you demand signed kernels and have a secure method of blocking unsigned ones.

But the read-only filesystem issue is something that could happen by accident rather than malicious alteration - for instance some filesystem errors may result in it being mounted RO for safety until the corruption is addressed.

Re: Uniting the Linux random-number devices

#62

Post by SAI_Peregrinus » Sun, Feb 20, 2022, 4:04 PM UTC

throway_zwudbo wrote: post #53

jcranmer wrote: post #41

Earlier quoted context omitted.

You're already misunderstanding how /dev/random and /dev/urandom work today, or indeed ever worked. Both devices have always read from the output of a CSPRNG. It used to be that /dev/random did some accounting to try to estimate how much entropy was in its pool, and if that number declined too low (as reading from /dev/random was figured to decrease the entropy), it would simply refuse to run its CSPRNG to produce an…

I don't think I have that misunderstanding. My question is, do you have proof that: 1. the CSPRNG in Linux is secure, and 2. CSPRNGs in general exists ? Fixing #1 simply requires changing to another algorithm. Fixing #2 requires a secure RNG to block for entropy, and if the distinction between /dev/random and /dev/urandom goes away, then this scenario will cause problems _if_ it happens. I said it's very unlikely, bu…

There's also no proof that a TRNG exists. Physics is consistent with an entirely deterministic universe.

Re: Uniting the Linux random-number devices

#63

Post by derobert » Tue, Feb 22, 2022, 8:37 PM UTC

EdSchouten wrote: post #56

What I never understood is why the entire discussion revolves around the concept that the kernel gets launched in a vacuum where it is responsible for generating its own entropy. Why can’t the kernel (or the boot loader) restore/reload state from somewhere? I don’t buy the argument that it’s hard to build that. - For virtualized systems there could be a hypervisor call to request an initial random seed. - Run of the…

A lot of these things do exist. Desktop/server Linux systems (used to at least) save some output from the PRNG to disk on shutdown and load it back on boot.

But of course snapshots, cloning, etc. can foil that badly, causing the same seed to be used multiple times. And on initial install you're not going to have any of that (but initial install is also when you may need to generate long-lived random numbers like ssh host keys).

Embedded devices it can be a real challenge. You must not re-use the seed data, so you effectively have to erase it from NVRAM/flash before use. But then if you lose power before you can generate a new one, you won't have one next boot. And you're adding flash writes, which decreases longevity and increases the chance of power failure in the middle of a write.

Qemu/KVM has a virtual RNG so you can feed host randomness into the guests if you want. So there are hypervisor calls available.