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

11–20 of 67 posts

Re: Linux RNG flaws

#11

Post by IcePic »

hsivonen wrote: post #10
tytso wrote: post #8

The flaws only applied for keys generated during early boot. Jann and I looked, but we didn't find a way that this could be turned into a practical exploit, which is why we considered, but decided against, doing any kind of coordinated disclosure. The potential weakness applies before you see crng_init=2 message, and in practice on many machines this happens well before a minute --- on my laptop, in under 10 seconds.…

What reasons are there not to implement the OpenBSD model where the bootloader passes the kernel a seed that the kernel generated previously?

There is no reason not to try it, but you would still want to cater for the initial boot when you have no previous entropy to read.

Re: Linux RNG flaws

#12

Post by hsivonen »

IcePic wrote: post #11
hsivonen wrote: post #10

Earlier quoted context omitted.

What reasons are there not to implement the OpenBSD model where the bootloader passes the kernel a seed that the kernel generated previously?

There is no reason not to try it, but you would still want to cater for the initial boot when you have no previous entropy to read.

Couldn't the installer write the initial seed?

Re: Linux RNG flaws

#13

Post by tinus_hn »

edflsafoiewq wrote: post #9
tytso wrote: post #8

The flaws only applied for keys generated during early boot. Jann and I looked, but we didn't find a way that this could be turned into a practical exploit, which is why we considered, but decided against, doing any kind of coordinated disclosure. The potential weakness applies before you see crng_init=2 message, and in practice on many machines this happens well before a minute --- on my laptop, in under 10 seconds.…

What kind of applications need cryptographic randomness during early boot?

The classic application is generating the ssh server keys.

I don’t know if that solely uses the system RNG though.

Re: Linux RNG flaws

#15

Post by zaarn »

tytso wrote: post #8

The flaws only applied for keys generated during early boot. Jann and I looked, but we didn't find a way that this could be turned into a practical exploit, which is why we considered, but decided against, doing any kind of coordinated disclosure. The potential weakness applies before you see crng_init=2 message, and in practice on many machines this happens well before a minute --- on my laptop, in under 10 seconds.…

I think that problem could be handled by having the RNG return an error until crng_init=2 and introduce a way to check the state of the kernel RNG.

Applications can then check if the kernel is ready to do RNG and if not, handle the delay themselves.

But I guess that would break some applications so there might be another way (extra device for early boot randomness? ioctl?)

Re: Linux RNG flaws

#16

Post by champtar »

Just to be sure I understand fully, if I take a small embedded router running OpenWRT, that maybe take ~1min for the urandom pool to be ready. https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;... On the first boot we save 512 bytes from getrandom(). On the second boot we restore the seed (cat seed > /dev/urandom) before almost all the user space starts. Many daemons (dropbear/openvpn) will read from /dev/urandom before urandom pool is considered ready, but after the seed is restored.

With the new patches, are the daemons benefiting from the seed ?

Re: Linux RNG flaws

#17

Post by mkj »

champtar wrote: post #16

Just to be sure I understand fully, if I take a small embedded router running OpenWRT, that maybe take ~1min for the urandom pool to be ready. https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;... On the first boot we save 512 bytes from getrandom(). On the second boot we restore the seed (cat seed > /dev/urandom) before almost all the user space starts. Many daemons (dropbear/openvpn) will read from /dev/u…

Note that Dropbear will read urandom upon each incoming connection so that should be mitigated in many circumstances. (Hopefully some systems are using the delayed hostkey generation option too)

Re: Linux RNG flaws

#18

Post by amelius »

zaarn wrote: post #15
tytso wrote: post #8

The flaws only applied for keys generated during early boot. Jann and I looked, but we didn't find a way that this could be turned into a practical exploit, which is why we considered, but decided against, doing any kind of coordinated disclosure. The potential weakness applies before you see crng_init=2 message, and in practice on many machines this happens well before a minute --- on my laptop, in under 10 seconds.…

I think that problem could be handled by having the RNG return an error until crng_init=2 and introduce a way to check the state of the kernel RNG. Applications can then check if the kernel is ready to do RNG and if not, handle the delay themselves. But I guess that would break some applications so there might be another way (extra device for early boot randomness? ioctl?)

Why doesn't the device simply block until it has collected sufficient randomness?

Re: Linux RNG flaws

#19

Post by londons_explore »

zaarn wrote: post #15
tytso wrote: post #8

The flaws only applied for keys generated during early boot. Jann and I looked, but we didn't find a way that this could be turned into a practical exploit, which is why we considered, but decided against, doing any kind of coordinated disclosure. The potential weakness applies before you see crng_init=2 message, and in practice on many machines this happens well before a minute --- on my laptop, in under 10 seconds.…

I think that problem could be handled by having the RNG return an error until crng_init=2 and introduce a way to check the state of the kernel RNG. Applications can then check if the kernel is ready to do RNG and if not, handle the delay themselves. But I guess that would break some applications so there might be another way (extra device for early boot randomness? ioctl?)

When the device blocks, the application can always do a non-blocking read to determine if data is available.

Re: Linux RNG flaws

#20

Post by AstralStorm »

tinus_hn wrote: post #13
edflsafoiewq wrote: post #9

Earlier quoted context omitted.

What kind of applications need cryptographic randomness during early boot?

The classic application is generating the ssh server keys. I don’t know if that solely uses the system RNG though.

Pretty silly. If you can network, you have access to at least 3 decent sources of entropy. (Network traffic, hardware clock randomness and network device clock. Potentially power supply monitoring and bus clocks. And finally thermal sources.) And then you can always bake in the key into flash.

The problem here is that you would have to probe RNG stats manually as it returned readiness too early.

Post reply on HN