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

Linux RNG flaws

bugs.chromium.org

Post reply on HN
Print view View original

61–67 of 67 posts

Re: Linux RNG flaws

#61

Post by JdeBP »

dullgiulio wrote: post #36
zaarn wrote: post #23

Earlier quoted context omitted.

/dev/random kinda does but a lot of applications also rely on /dev/urandom which doesn't, which is why it's a problem to some extend. Atleast from what I know.

I don't understand why it's not possible to make /dev/random block until there is enough entropy in the pool for the seed, and never block afterwards when it can securely do key-stretching. After seeding, there is no point in blocking on a lack of entropy, which is why it is recommended to use /dev/urandom in the first place.

What makes you think that that's impossible? It's what the BSDs do.

Re: Linux RNG flaws

#62

Post by dspillett »

dsl wrote: post #53
dspillett wrote: post #45

Earlier quoted context omitted.

If you have network access early enough in the install and/or boot processes could you not pluck some random bits from a web service to pump more entropy into the RNG's pool? For paranoia you could host your own fairly easily instead of using a public one: have a machine that is publicly visible respond with random digits from its own entropy pool, have it use one or more of various methods to keep that pool topped u…

http://manpages.ubuntu.com/manpages/trusty/man1/pollinate.1....

Exactly that. I'd not spotted that a nice convenient option already existed rather than rolling your own. If the location you host pollen on to provide entropy for elsewhere via pollenate, try running haveged.

Re: Linux RNG flaws

#63

Post by lihes »

oconnor663 wrote: post #48
lihes wrote: post #22

man urandom > When read during early boot time, /dev/urandom may return data prior to the entropy pool being initialized. I see no bugs here. Just repeating what is written in the man page.

If you continue to the next sentence in that man page: > If this is of concern in your application, use getrandom(2) or /dev/random instead. These bugs affect getrandom too.

Where is it written? Could you pin point it? I see urandom everywhere.

Re: Linux RNG flaws

#64

Post by dmateos »

4795 b2242bd 30230fc 9fb6ae d7 7d 69 69 73 69 69 69 69 69 69 69 73 69 69 69 69 69 69 69 69 69 69 69 69 69 69 69 69 69 69 69 69 69 69 69 69 69 69 69 69 69 6e 69 69 69 69 69 69 69 69 69 69 69 69 69 69 69 69 69 69 69 69 5140 f a a a 5 a a a a 5 a

Nice.

Re: Linux RNG flaws

#65

Post by loeg »

dullgiulio wrote: post #36
zaarn wrote: post #23

Earlier quoted context omitted.

/dev/random kinda does but a lot of applications also rely on /dev/urandom which doesn't, which is why it's a problem to some extend. Atleast from what I know.

I don't understand why it's not possible to make /dev/random block until there is enough entropy in the pool for the seed, and never block afterwards when it can securely do key-stretching. After seeding, there is no point in blocking on a lack of entropy, which is why it is recommended to use /dev/urandom in the first place.

I think a perverse sense of ABI stability, in this case. Don't want to change expectations for any userspace program, ever. getrandom(2) theoretically provides the actually useful behavior.

Re: Linux RNG flaws

#66

Post by oconnor663 »

lihes wrote: post #63
oconnor663 wrote: post #48

Earlier quoted context omitted.

If you continue to the next sentence in that man page: > If this is of concern in your application, use getrandom(2) or /dev/random instead. These bugs affect getrandom too.

Where is it written? Could you pin point it? I see urandom everywhere.

I got it from this part, unless I'm misreading:

> Multiple callers, including sys_getrandom(..., flags=0), attempt to wait for the

> RNG to become cryptographically safe before reading from it by checking for

> crng_ready() and waiting if necessary. However, crng_ready() only checks for

> `crng_init > 0`, and `crng_init==1` does not imply that the RNG is

> cryptographically safe.

Re: Linux RNG flaws

#67

Post by tytso »

zeveb wrote: post #52
tytso wrote: post #41

Earlier quoted context omitted.

This is what getrandom(2) does, and using getrandom is the recommended path. However, if you use getrandom(2), and you are in early boot, such as by systemd's journald, and you are using it for some pointless HMAC mechanism with a randomly generated key for no specified security goal and no clearly articulated threat model, then you can end up hanging the boot, leading to the entropy deadlock situation I described. S…

Is there a way to review the different paths and come up with answers for all of them? E.g., if on a platform with a hardware RNG then it should never be necessary to block: just read 128 bits out of the hardware RNG & generate a stream of random numbers. On a platform without a hardware RNG, could one require a previous seed? An installer could install the seed in some persistent storage somewhere, so there's no nee…

How do you decide whether or not you trust the hardware RNG? Do you trust RDRAND? Some people do, other people are convinced it may be backdoored by Intel at the request of the NSA. Worst of all, there is no way to tell which belief is true. So there are potential real problems with hardware RNG's if you are worried about state sponsored attackers who are willing to intercept hardware shipments.

Requiring a previous seed requires a way to get access to the seed, early enough in the boot that it is available to kernel users who are trying to use randomness for address space randomization and for stack canaries. But in early boot the kernel may not be sufficiently initialized to read from persistent storage, and there are many, many bootloaders.

The reason why there is no file system interface to getrandom(2) is that a file system interface is subject to file descriptor exhaustion attacks. It was OpenBSD which designed the getentropy(2) system call, and getrandom(2) was modelled after it. Basically, getrandom(2) is getentropy(2) with an extra flags parameter added.

Post reply on HN