4 ms·

> The correct fix is to fix getrandom() to not block when it's not appropriate,... I'm not a cryptography expert, but this suggestion doesn't look right. Edit

> The correct fix is to fix getrandom() to not block when it's not appropriate,... I'm not a cryptography expert, but this suggestion doesn't look right. Edit: IMO the main problem is the lack of a forward progress guarantee for entropy generation, even if there are suitable sources for entropy in the system.

banachtarski 7y ago
I've worked in crypto before (not now though) and your statement is actually a common misconception. The information about whether the randomness is sourced from "true" entropy or not is in and of itself a form of entropy from the perspective of an assailant. It's enough that given some period of time, "some" amount of entropy is present and how much is dependent on the degree to which the system is used. You can use a game theoretic approach to determine how much that is. edit: to clarify, occasionally not using /dev/random when it may block is not actually a security issue (in most cases)
- ses1984 7y ago
  How do we know which cases?
  - deleted 7y ago
    [deleted]
  - masklinn 7y ago
    The only case where it could be an issue is at bootup, when the subsystem simply does not have enough entropy. OpenBSD solved that by storing a seed for next bootup at the end of boot and during shutdown.
    - simonh 7y ago
      I hope the seed is very well protected.
      - VibrantClarity 7y ago
        wdym? if an attacker can access your filesystem its already game over
        iforgotpassword 7y ago
        The same could be said for some of the entropy sources that were nerfed or removed over time due to security concerns. That's the main reason why we even are in this situation today.
    - asamarin 7y ago
      So what happens at the very first boot (e.g. after system installation, or cloud instance just being spawned)? Is that the only circumstance where it would be OK to block? Does OpenBSD trust RdRand for such occasions?
      - ChrisSD 7y ago
        You can set /etc/random.seed (or /var/db/host.random for spawned instances) prior to first boot. That's what cloud providers do IIRC. It also mixes in hardware random (if available).
      - gnud 7y ago
        A new cloud instance seems like a small problem. The host could just generate an entropy file for the first boot.
        caf 7y ago
        Yes - the hard case is a little flash-based low power ARM router, cloned by the million.
        Reelin 7y ago
        From 2012, but still at least somewhat relevant (https://factorable.net/weakkeys12.extended.pdf https://factorable.net/weakkeys12.extended.pdf). > RSA and DSA can fail catastrophically when used with malfunctioning random number generators ... network survey of TLS and SSH servers and present evidence that vulnerable keys are surprisingly widespread ... we are able to obtain RSA private keys for 0.50% of TLS hosts and 0.03% of SSH hosts, because their public keys shared nontrivial common factors due to entropy problems, and DSA private keys for 1.03% of SSH hosts, because of insufﬁcient signature randomness ... the vast majority appear to be headless or embedded devices ...
      - boring_twenties 7y ago
        > Does OpenBSD trust RdRand for such occasions? It is used as one source among many to seed the PRNG, so I think the answer is no.
trasz 7y ago
PRNG needs entropy, but it doesn't consume it. You don't need to feed entropy into it continuously.
- msla 7y ago
  > PRNG needs entropy, but it doesn't consume it. You don't need to feed entropy into it continuously. In the extreme case, this means you can run a PRNG with a fixed seed indefinitely, which is definitely wrong because such a PRNG will necessarily loop. That might not be feasible to exploit, however.
  - stouset 7y ago
    > such a PRNG will necessarily loop Given infinite time, energy, and computing power, yes. Given computers made out matter and running on energy for use by meat-based intelligences, no. This is really analogous to saying "technically a 256-bit encryption key is brute-forceable". In fact, this is so close to being the actual underlying situation it's barely even an analogy.
pmoriarty 7y ago
Something else I'd wonder is whether there are other sources of entropy that could be used here other than the disk -- as improving disk IO is what seems to have caused this particular issue in the first place.
dmitrygr 7y ago
> even if there are suitable sources for entropy in the system What might those be on, say, a freshly booted RasPi that hasn't even brought up much of userspace besides systemd?
- jlgaddis 7y ago
  The Raspberry Pi has a HWRNG onboard.
  - dmitrygr 7y ago
    Do you trust it?
    - tatersolid 7y ago
      You’re forced to trust the maker of your CPU, mainboard, etc. if you can’t trust your hardware you’re toast. There’s nothing special about RNGs in this regard.
- leni536 7y ago
  The problematic commit reduced the number of disk IO at bootup which resulted in starving getrandom() from the necessary entropy. If disk IO is already considered a reliable source of entropy then there is no reason to not actively exercise it when entropy is needed.

banachtarski 7y ago

I've worked in crypto before (not now though) and your statement is actually a common misconception. The information about whether the randomness is sourced from "true" entropy or not is in and of itself a form of entropy from the perspective of an assailant. It's enough that given some period of time, "some" amount of entropy is present and how much is dependent on the degree to which the system is used. You can use a game theoretic approach to determine how much that is. edit: to clarify, occasionally not using /dev/random when it may block is not actually a security issue (in most cases)

ses1984 7y ago
How do we know which cases?
- deleted 7y ago
  [deleted]
- masklinn 7y ago
  The only case where it could be an issue is at bootup, when the subsystem simply does not have enough entropy. OpenBSD solved that by storing a seed for next bootup at the end of boot and during shutdown.
  - simonh 7y ago
    I hope the seed is very well protected.
    - VibrantClarity 7y ago
      wdym? if an attacker can access your filesystem its already game over
      - iforgotpassword 7y ago
        The same could be said for some of the entropy sources that were nerfed or removed over time due to security concerns. That's the main reason why we even are in this situation today.
  - asamarin 7y ago
    So what happens at the very first boot (e.g. after system installation, or cloud instance just being spawned)? Is that the only circumstance where it would be OK to block? Does OpenBSD trust RdRand for such occasions?
    - ChrisSD 7y ago
      You can set /etc/random.seed (or /var/db/host.random for spawned instances) prior to first boot. That's what cloud providers do IIRC. It also mixes in hardware random (if available).
    - gnud 7y ago
      A new cloud instance seems like a small problem. The host could just generate an entropy file for the first boot.
      - caf 7y ago
        Yes - the hard case is a little flash-based low power ARM router, cloned by the million.
        Reelin 7y ago
        From 2012, but still at least somewhat relevant (https://factorable.net/weakkeys12.extended.pdf https://factorable.net/weakkeys12.extended.pdf). > RSA and DSA can fail catastrophically when used with malfunctioning random number generators ... network survey of TLS and SSH servers and present evidence that vulnerable keys are surprisingly widespread ... we are able to obtain RSA private keys for 0.50% of TLS hosts and 0.03% of SSH hosts, because their public keys shared nontrivial common factors due to entropy problems, and DSA private keys for 1.03% of SSH hosts, because of insufﬁcient signature randomness ... the vast majority appear to be headless or embedded devices ...
    - boring_twenties 7y ago
      > Does OpenBSD trust RdRand for such occasions? It is used as one source among many to seed the PRNG, so I think the answer is no.

trasz 7y ago

PRNG needs entropy, but it doesn't consume it. You don't need to feed entropy into it continuously.

msla 7y ago
> PRNG needs entropy, but it doesn't consume it. You don't need to feed entropy into it continuously. In the extreme case, this means you can run a PRNG with a fixed seed indefinitely, which is definitely wrong because such a PRNG will necessarily loop. That might not be feasible to exploit, however.
- stouset 7y ago
  > such a PRNG will necessarily loop Given infinite time, energy, and computing power, yes. Given computers made out matter and running on energy for use by meat-based intelligences, no. This is really analogous to saying "technically a 256-bit encryption key is brute-forceable". In fact, this is so close to being the actual underlying situation it's barely even an analogy.

pmoriarty 7y ago

Something else I'd wonder is whether there are other sources of entropy that could be used here other than the disk -- as improving disk IO is what seems to have caused this particular issue in the first place.

dmitrygr 7y ago

> even if there are suitable sources for entropy in the system What might those be on, say, a freshly booted RasPi that hasn't even brought up much of userspace besides systemd?

jlgaddis 7y ago
The Raspberry Pi has a HWRNG onboard.
- dmitrygr 7y ago
  Do you trust it?
  - tatersolid 7y ago
    You’re forced to trust the maker of your CPU, mainboard, etc. if you can’t trust your hardware you’re toast. There’s nothing special about RNGs in this regard.
leni536 7y ago
The problematic commit reduced the number of disk IO at bootup which resulted in starving getrandom() from the necessary entropy. If disk IO is already considered a reliable source of entropy then there is no reason to not actively exercise it when entropy is needed.