4 ms·

> I exhausted the entropy on the Linux VM How is that supposed to work? Entropy does not get exhausted.

boring_twenties 7y ago
Pretty sure the Linux entropy pool is "consumed" when read and thus will become exhausted when not replenished fast enough. You can see this when reading /dev/random on a low-entropy machine (such as a VM), and adding whatever you want to the entropy pool manually. The reading process will unblock, read a few bytes, then block again until you add more.
- dependenttypes 7y ago
  This is extremely weird. Would you happen to have an idea of what the reasoning behind it is?
  - boring_twenties 7y ago
    Well, not really, but before Linux 3.17 there was no way other way to be safe: /dev/urandom was the only other option, and that happily returns data even if the entropy pool isn't (yet) initialized and the CSPRNG can't be properly seeded. Since then there is get_random(2) which does the right thing for most applications. The man page also has this to say: > The /dev/random device is a legacy interface which dates back to a time where the cryptographic primitives used in the implementation of /dev/urandom were not widely trusted. I must admit though, that I still don't understand why blocking on insufficient entropy is a bad thing for generating long-lived keys. I'm going to use the key for years, why wouldn't I just wait a couple of seconds or minutes?
    - throwaway2048 7y ago
      Because the entire idea of "insufficient entropy" past an initialization amount is a cargo culted fantasy. In the Linux kernel view of the world, /dev/random "loses" 1 bit of entropy for every bit that gets read. That is not how cryptographic and hashing primitives work, if it were it would be dangerous to use an AES key to encrypt more than a few megabytes for example.
  - loeg 7y ago
    The /dev/random re-blocking behavior, where entropy is "consumed" (after initial entropy seeding), is a result of lack of crypto understanding by Linux shot-callers, and Linus in particular. You wouldn't blame them for it 20-25 years ago, but we've known better for at least 15 years so it'd be nice if they'd get with the program. And it can be fixed without breaking their userspace ABI that they're usually fanatical about not breaking. Linus wanting to break getrandom's ABI just shows he still doesn't understand how CSPRNGs work.
    - dependenttypes 7y ago
      Surely someone must have explained that to them years ago, right? Would you happen to have a discussion in mind where the maintainers of the RNG generators commented on the issue? I would like to see their perspective but I am kind of lost.
      - loeg 7y ago
        I imagine so, but I'm not close to the Linux kernel community and don't know. I don't get the impression that Linus, for example, changes his mind particularly easily.
- nwallin 7y ago
  This is why you're supposed to use getrandom() instead of /dev/random. It doesn't block on "low" entropy. What were you using that uses /dev/random?
  - boring_twenties 7y ago
    Right, or just use *BSD where /dev/{u,}random both behave correctly :) I'm not the same guy, so I have no idea what he was reading /dev/random for. Just pointing out that it can in fact be "exhausted." I'm not a crypto expert either, but wouldn't it still make sense to use /dev/random when generating long-lived keys (e.g. PGP, SSL CA, ssh keys...)? I understand, I think, that a CSPRNG seeded with just the minimum amount of entropy should be "good enough." More entropy has to be at least theoretically better though, doesn't it? If the only tradeoff is having to wait a few more seconds or possibly minutes to generate a key I'm going to use for years... why wouldn't I want to do that?
    - loeg 7y ago
      > I'm not a crypto expert either, but wouldn't it still make sense to use /dev/random when generating long-lived keys (e.g. PGP, SSL CA, ssh keys...)? No. https://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ https://sockpuppet.org/blog/2014/02/25/safely-generate-rando...
  - hinkley 7y ago
    I’m pretty sure it was https session keys for pulling packages. I can’t recall how I fixed it. Best bet is logged into the Linux host and cross linked dev/urandom, or just restarted the host. Hasn’t happened again, and I was just experimenting with couple of images over the last few weeks.

Pretty sure the Linux entropy pool is "consumed" when read and thus will become exhausted when not replenished fast enough. You can see this when reading /dev/random on a low-entropy machine (such as a VM), and adding whatever you want to the entropy pool manually. The reading process will unblock, read a few bytes, then block again until you add more.

dependenttypes 7y ago
This is extremely weird. Would you happen to have an idea of what the reasoning behind it is?
- boring_twenties 7y ago
  Well, not really, but before Linux 3.17 there was no way other way to be safe: /dev/urandom was the only other option, and that happily returns data even if the entropy pool isn't (yet) initialized and the CSPRNG can't be properly seeded. Since then there is get_random(2) which does the right thing for most applications. The man page also has this to say: > The /dev/random device is a legacy interface which dates back to a time where the cryptographic primitives used in the implementation of /dev/urandom were not widely trusted. I must admit though, that I still don't understand why blocking on insufficient entropy is a bad thing for generating long-lived keys. I'm going to use the key for years, why wouldn't I just wait a couple of seconds or minutes?
  - throwaway2048 7y ago
    Because the entire idea of "insufficient entropy" past an initialization amount is a cargo culted fantasy. In the Linux kernel view of the world, /dev/random "loses" 1 bit of entropy for every bit that gets read. That is not how cryptographic and hashing primitives work, if it were it would be dangerous to use an AES key to encrypt more than a few megabytes for example.
- loeg 7y ago
  The /dev/random re-blocking behavior, where entropy is "consumed" (after initial entropy seeding), is a result of lack of crypto understanding by Linux shot-callers, and Linus in particular. You wouldn't blame them for it 20-25 years ago, but we've known better for at least 15 years so it'd be nice if they'd get with the program. And it can be fixed without breaking their userspace ABI that they're usually fanatical about not breaking. Linus wanting to break getrandom's ABI just shows he still doesn't understand how CSPRNGs work.
  - dependenttypes 7y ago
    Surely someone must have explained that to them years ago, right? Would you happen to have a discussion in mind where the maintainers of the RNG generators commented on the issue? I would like to see their perspective but I am kind of lost.
    - loeg 7y ago
      I imagine so, but I'm not close to the Linux kernel community and don't know. I don't get the impression that Linus, for example, changes his mind particularly easily.
nwallin 7y ago
This is why you're supposed to use getrandom() instead of /dev/random. It doesn't block on "low" entropy. What were you using that uses /dev/random?
- boring_twenties 7y ago
  Right, or just use *BSD where /dev/{u,}random both behave correctly :) I'm not the same guy, so I have no idea what he was reading /dev/random for. Just pointing out that it can in fact be "exhausted." I'm not a crypto expert either, but wouldn't it still make sense to use /dev/random when generating long-lived keys (e.g. PGP, SSL CA, ssh keys...)? I understand, I think, that a CSPRNG seeded with just the minimum amount of entropy should be "good enough." More entropy has to be at least theoretically better though, doesn't it? If the only tradeoff is having to wait a few more seconds or possibly minutes to generate a key I'm going to use for years... why wouldn't I want to do that?
  - loeg 7y ago
    > I'm not a crypto expert either, but wouldn't it still make sense to use /dev/random when generating long-lived keys (e.g. PGP, SSL CA, ssh keys...)? No. https://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ https://sockpuppet.org/blog/2014/02/25/safely-generate-rando...
- hinkley 7y ago
  I’m pretty sure it was https session keys for pulling packages. I can’t recall how I fixed it. Best bet is logged into the Linux host and cross linked dev/urandom, or just restarted the host. Hasn’t happened again, and I was just experimenting with couple of images over the last few weeks.