4 ms·

Tldr?

by snissn 8y ago

Tldr?

cryptonector 8y ago
From TFA: > == Discarded early randomness, including device randomness == > == RNG is treated as cryptographically safe too early == > == Interaction between kernel and entropy-persisting userspace is broken == > == No entropy is fed into NUMA CRNGs between rand_initialize() initcall and crng_init==2 == > == initcall can propagate entropy into primary and NUMA CRNGs while crng_init==1 == and > == Impact == > I have spent a few days attempting to figure out how bad these issues are. > I believe that on an Intel Grass Canyon system, with RDRAND disabled, > ASLR disabled, fast boot enabled, no connected devices, with boot on power, > some frequency scaling options disabled, and the fan set to maximum, > it should be possible to express the entropy in the used RDTSC samples in around > 105 bits or less. (I'm not sure which parts of this configuration actually > influence the amount of entropy; but ASLR certainly does influence it, since the > one interrupt sample that is fed into the RNG before the RNG initialization > contains an instruction pointer.)
- ploxiln 8y ago
  Due to some unfortunate complications of somewhat recent changes: > The worst part of this (one device entropy sample being enough to move to crng_init==1) was AFAICS introduced in commit ee7998c50c26 ("random: do not ignore early device randomness"), first in v4.14. confirmed by the fix for that bit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/char/random.c?id=dc12baacb95f205948f64dc936a47d89ee110117 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
- londons_explore 8y ago
  "105 bits" isn't too shabby. I'd only start to worry when it gets to say 70 bits or less. That's the kind of size a state actor could precompute ssh host keys for each of the initial random number states in a common distro for example. If a state actor could compute ssh keys in 50 milliseconds on custom hardware, and they had 100,000 machines generating those keys, they could generate enough keys to have a 1 in 1 million chance for 70 bits of entropy after 20 years.
  - loeg 8y ago
    Emphasis on "or less." Anyway, far far below expected entropy.
lucb1e 8y ago
Read each of the headings and see the bottom part for impact. The final update (added today) mentions the resolution.
ethbro 8y ago
Early system, post-boot randomness is hard. Linux wasn't handling it ideally. Consequently, things which relied on a cryptographically safe RNG were likely executing before that could be guaranteed. Sequencing was modified to better align expectations with actual system operation.

Tldr?

by snissn 8y ago

Tldr?

From TFA: > == Discarded early randomness, including device randomness == > == RNG is treated as cryptographically safe too early == > == Interaction between kernel and entropy-persisting userspace is broken == > == No entropy is fed into NUMA CRNGs between rand_initialize() initcall and crng_init==2 == > == initcall can propagate entropy into primary and NUMA CRNGs while crng_init==1 == and > == Impact == > I have spent a few days attempting to figure out how bad these issues are. > I believe that on an Intel Grass Canyon system, with RDRAND disabled, > ASLR disabled, fast boot enabled, no connected devices, with boot on power, > some frequency scaling options disabled, and the fan set to maximum, > it should be possible to express the entropy in the used RDTSC samples in around > 105 bits or less. (I'm not sure which parts of this configuration actually > influence the amount of entropy; but ASLR certainly does influence it, since the > one interrupt sample that is fed into the RNG before the RNG initialization > contains an instruction pointer.)

ploxiln 8y ago
Due to some unfortunate complications of somewhat recent changes: > The worst part of this (one device entropy sample being enough to move to crng_init==1) was AFAICS introduced in commit ee7998c50c26 ("random: do not ignore early device randomness"), first in v4.14. confirmed by the fix for that bit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/char/random.c?id=dc12baacb95f205948f64dc936a47d89ee110117 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
londons_explore 8y ago
"105 bits" isn't too shabby. I'd only start to worry when it gets to say 70 bits or less. That's the kind of size a state actor could precompute ssh host keys for each of the initial random number states in a common distro for example. If a state actor could compute ssh keys in 50 milliseconds on custom hardware, and they had 100,000 machines generating those keys, they could generate enough keys to have a 1 in 1 million chance for 70 bits of entropy after 20 years.
- loeg 8y ago
  Emphasis on "or less." Anyway, far far below expected entropy.

lucb1e 8y ago

Read each of the headings and see the bottom part for impact. The final update (added today) mentions the resolution.

ethbro 8y ago

Early system, post-boot randomness is hard. Linux wasn't handling it ideally. Consequently, things which relied on a cryptographically safe RNG were likely executing before that could be guaranteed. Sequencing was modified to better align expectations with actual system operation.