4 ms·

I think this is the best comment I've seen in this thread yet. It can be a tough call. In a previous job I worked on a product that used /dev/random. We neve

I think this is the best comment I've seen in this thread yet. It can be a tough call. In a previous job I worked on a product that used /dev/random. We never had a problem with it until one customer installed our product on a newly created VM, and it hung during startup. We switched to urandom, but we definitely had misgivings about it, as this was exactly the case where it could matter. It's also a situation where reading from /dev/random only the first time wouldn't fix the perceived bug in our product. Perhaps it would be useful to have a userland process monitor /dev/random and, in a case like this where there has never been sufficient entropy in the pool, send a notification to the console (though there's no guarantee it will be noticed). On Android it could pop up a window.

saurik 13y ago
> It's also a situation where reading from /dev/random only the first time wouldn't fix the perceived bug in our product. If this was the case, that the block was happening on the very first usage of random data, then you actually managed to build a system that wasn't secure: that first time /dev/random was blocking, when you switched to /dev/urandom, on a newly-created VM, meant that the customer was getting deterministic data from /dev/urandom, and no one ever realized because there is no error condition for this. (Maybe the system clock was accurate on these new VMs and not set later by ntpd; if so, there might be hope that at least there were a few bits of entropy involved ;P.)
- ScottBurson 13y ago
  Yes -- that's what I meant by "this was exactly the case where it could matter".
  - saurik 13y ago
    Sorry, I had presumed you meant simply "we were doing key generation" not "we realized that this directly led to not actually getting random data", especially given the "misgivings", which seemed like a light statement.
    - ScottBurson 13y ago
      Sorry I was unclear. I think we only had "misgivings" because the key we were generating had only relatively minor use in the product. Alas, I don't recall exactly what that was, and it's certainly possible, in retrospect, that we didn't care as much about the implications of using /dev/urandom as we should have. But that was pre-Snowden.

saurik 13y ago

> It's also a situation where reading from /dev/random only the first time wouldn't fix the perceived bug in our product. If this was the case, that the block was happening on the very first usage of random data, then you actually managed to build a system that wasn't secure: that first time /dev/random was blocking, when you switched to /dev/urandom, on a newly-created VM, meant that the customer was getting deterministic data from /dev/urandom, and no one ever realized because there is no error condition for this. (Maybe the system clock was accurate on these new VMs and not set later by ntpd; if so, there might be hope that at least there were a few bits of entropy involved ;P.)

ScottBurson 13y ago
Yes -- that's what I meant by "this was exactly the case where it could matter".
- saurik 13y ago
  Sorry, I had presumed you meant simply "we were doing key generation" not "we realized that this directly led to not actually getting random data", especially given the "misgivings", which seemed like a light statement.
  - ScottBurson 13y ago
    Sorry I was unclear. I think we only had "misgivings" because the key we were generating had only relatively minor use in the product. Alas, I don't recall exactly what that was, and it's certainly possible, in retrospect, that we didn't care as much about the implications of using /dev/urandom as we should have. But that was pre-Snowden.