Deep Dive into FreeBSD's Kernel RNG, John-Mark Gurney and Dean Freeman
0 0 55
By loeg 2018-05-04
It's worth noting that FreeBSD also had some RNG troubles quite recently (2017) (talk: ). Personally, I don't think they were as severe as this. (But I am biased, I do FreeBSD development.) What I'm trying to say is, getting random right is hard. It's easy to produce something random-looking that isn't good enough.
JMG's FreeBSD 2017 RNG talk Tl;dr:
1. Boot-time entropy might leak on either UFS or ZFS; might be re-used in a byzantine ZFS environment. (Not addressed, as far as I know.)
2. Input entropy data (pre-whitening) had only about 0.18 bits of entropy per byte of input. NIST likes to see 4-6 bits per byte. (Not really an issue due to sufficient input volume.) Partially due to:
3. All the fast, high-quality sources of random entropy were accidentally disabled(!). (All the PURE_* ones, including x86 RDRAND.) Fixed in r324394.
4. Other low entropy structures were getting mixed in. Probably harmless, but reduces entropy-per-byte measure that NIST cares about. Fixed in r324372.
The earlier 2015 FreeBSD RNG issues were probably as severe as this Linux issue:
> URGENT: RNG broken for last 4 months
> If you are running a current kernel r273872 or later, please upgrade your kernel to r278907 or later immediately and regenerate keys.
> I discovered an issue where the new framework code was not calling randomdev_init_reader, which means that read_random(9) was not returning good random data. read_random(9) is used by arc4random(9) which is the primary method that arc4random(3) is seeded from.
> This means most/all keys generated may be predictable and must be regenerated. This includes, but not limited to, ssh keys and keys generated by openssl. This is purely a kernel issue, and a simple kernel upgrade w/ the patch is sufficient to fix the issue.
Popular Videos 176
Submit Your Video