4 ms·

> Both /dev/urandom and /dev/random are using the exact same CSPRNG The author keeps coming back to this fact, but I don't understand how it negates any of the

by shawnz 13y ago

> Both /dev/urandom and /dev/random are using the exact same CSPRNG The author keeps coming back to this fact, but I don't understand how it negates any of the arguments in favour of using /dev/random. What does it matter if the numbers are ultimately coming out of the same PRNG? I don't see how this negates the "self-healing" property of /dev/random or any of the other advantages. It seems like the author is really just saying, "/dev/urandom is probably good enough".

spoiler 13y ago
I think he's saying something along the lines: It's better to use /dev/urandom than /dev/random when you're in need of a high throughput of randomness. He even said people use /dev/random and do weird shit, which,makes their system less secure, when their app runs slow to make up for it. In the end, it boils down to: Why not use /dev/urandom and get good enough security, instead of insecurity.
Tomte 13y ago
This is basically a response to the widespread conception that /dev/random has some mechanism whereby it generates "true" random numbers, while /dev/urandom only uses some lowly PRNG. The idea that a lot of people get from that is that urandom is not much better than Mersenne twister, while /dev/random is the real thing. And yes, you're right, the argument is precisely "computational security is good enough". By the way, /dev/urandom is also self-healing. Which other advantages of /dev/random might be there, apart from the cold boot case?
- SeanLuke 13y ago
  > The idea that a lot of people get from that is that urandom is not much better than Mersenne twister > And yes, you're right, the argument is precisely "computational security is good enough". Point of order. MT is not, and is not meant to be, a cryptographically secure random number generator. Generally speaking, good RNGs may be divided into two categories. First, there are RNGs designed for simulation. Goals: high periods, strong statistical randomness, and speed. Then there are RNGs designed for crypto. These have one primary goal: that even if you knew how the RNG worked, and had a long stream of previous output, you could not [easily] predict the next output. MT is in the first category. It is trivially predictable given about 650 past integers, since they collectively defined its internal seed.
  - Tomte 13y ago
    Yes, that's why I gave the example of MT. People really believe that /dev/urandom belongs to that class of RNG.
  - dfc 13y ago
    A point of order is limited to issues regarding procedure. It is not meant for factual disputes and or differences of opinion.
    - SeanLuke 13y ago
      Shoudn't your comment have been a point of order? :-)
- shawnz 13y ago
  > By the way, /dev/urandom is also self-healing. Sure, but only when possible and not all the time. I do realize we are only talking about seconds of vulnerability at a time, though. > Which other advantages of /dev/random might be there, apart from the cold boot case? I don't know enough about linux's PRNG to say, but as mentioned in some of the other posts, the point is that both APIs are there because they represent two different sets of guarantees. If you need the guarantees that /dev/random provides, then it's there and there's nothing wrong with using it. There are some additional considerations to be aware of, like the fact that it blocks, but I don't think that makes it something to be avoided.
  - tptacek 13y ago
    /dev/random also only "heals" "when possible".
    - shawnz 13y ago
      But that "when possible" is approximately 100% of the time that bits can be read from it, correct? Is that not the point of /dev/random?
      - tptacek 13y ago
        No! That's not how /dev/random works. You aren't literally reading raw entropy from /dev/random. You're reading the ouput of a keystream generator. /dev/random has bolted onto it an "entropy estimator" that tries to match the draw from the generator to the inputs to the generator; that is the difference between it and urandom.
        shawnz 13y ago
        > You aren't literally reading raw entropy from /dev/random. You're reading the ouput of a keystream generator. Yes, I understand. It's the same one that /dev/urandom reads out of, if I am not mistaken. > /dev/random has bolted onto it an "entropy estimator" that tries to match the draw from the generator to the inputs to the generator Right, and it blocks if it estimates that there is little or no entropy left. So doesn't that mean that approximately (i.e. subject to the quality of the estimation) 100% of the time there is no entropy left, it will block?
- stcredzero 13y ago
  This is basically a response to the widespread conception Maybe it's just me, but it seems to me that the programming field is chock full of myths and misinformational tales that people actually make decisions with!
dfox 13y ago
The same "self-healing" property also applies to /dev/urandom. Author tries to show that only way in which is urandom better than random is that it blocks when there is not enought entropy by some pretty arbitrary estimate, and that this behavior is almost never what you require.
tptacek 13y ago
Another misconception. Talking about urandom is a little like playing whack-a-mole. Both random and urandom "self-heal"; they both continually rekey based on new entropy events. But there is no meaningful security benefit to giving your application control over that rekeying, which is effectively what /dev/random does by having your application sleep until some arbitrary counter elapses.

by shawnz 13y ago

spoiler 13y ago

I think he's saying something along the lines: It's better to use /dev/urandom than /dev/random when you're in need of a high throughput of randomness. He even said people use /dev/random and do weird shit, which,makes their system less secure, when their app runs slow to make up for it. In the end, it boils down to: Why not use /dev/urandom and get good enough security, instead of insecurity.

Tomte 13y ago

This is basically a response to the widespread conception that /dev/random has some mechanism whereby it generates "true" random numbers, while /dev/urandom only uses some lowly PRNG. The idea that a lot of people get from that is that urandom is not much better than Mersenne twister, while /dev/random is the real thing. And yes, you're right, the argument is precisely "computational security is good enough". By the way, /dev/urandom is also self-healing. Which other advantages of /dev/random might be there, apart from the cold boot case?

SeanLuke 13y ago
> The idea that a lot of people get from that is that urandom is not much better than Mersenne twister > And yes, you're right, the argument is precisely "computational security is good enough". Point of order. MT is not, and is not meant to be, a cryptographically secure random number generator. Generally speaking, good RNGs may be divided into two categories. First, there are RNGs designed for simulation. Goals: high periods, strong statistical randomness, and speed. Then there are RNGs designed for crypto. These have one primary goal: that even if you knew how the RNG worked, and had a long stream of previous output, you could not [easily] predict the next output. MT is in the first category. It is trivially predictable given about 650 past integers, since they collectively defined its internal seed.
- Tomte 13y ago
  Yes, that's why I gave the example of MT. People really believe that /dev/urandom belongs to that class of RNG.
- dfc 13y ago
  A point of order is limited to issues regarding procedure. It is not meant for factual disputes and or differences of opinion.
  - SeanLuke 13y ago
    Shoudn't your comment have been a point of order? :-)
shawnz 13y ago
> By the way, /dev/urandom is also self-healing. Sure, but only when possible and not all the time. I do realize we are only talking about seconds of vulnerability at a time, though. > Which other advantages of /dev/random might be there, apart from the cold boot case? I don't know enough about linux's PRNG to say, but as mentioned in some of the other posts, the point is that both APIs are there because they represent two different sets of guarantees. If you need the guarantees that /dev/random provides, then it's there and there's nothing wrong with using it. There are some additional considerations to be aware of, like the fact that it blocks, but I don't think that makes it something to be avoided.
- tptacek 13y ago
  /dev/random also only "heals" "when possible".
  - shawnz 13y ago
    But that "when possible" is approximately 100% of the time that bits can be read from it, correct? Is that not the point of /dev/random?
    - tptacek 13y ago
      No! That's not how /dev/random works. You aren't literally reading raw entropy from /dev/random. You're reading the ouput of a keystream generator. /dev/random has bolted onto it an "entropy estimator" that tries to match the draw from the generator to the inputs to the generator; that is the difference between it and urandom.
      - shawnz 13y ago
        > You aren't literally reading raw entropy from /dev/random. You're reading the ouput of a keystream generator. Yes, I understand. It's the same one that /dev/urandom reads out of, if I am not mistaken. > /dev/random has bolted onto it an "entropy estimator" that tries to match the draw from the generator to the inputs to the generator Right, and it blocks if it estimates that there is little or no entropy left. So doesn't that mean that approximately (i.e. subject to the quality of the estimation) 100% of the time there is no entropy left, it will block?
stcredzero 13y ago
This is basically a response to the widespread conception Maybe it's just me, but it seems to me that the programming field is chock full of myths and misinformational tales that people actually make decisions with!

dfox 13y ago

The same "self-healing" property also applies to /dev/urandom. Author tries to show that only way in which is urandom better than random is that it blocks when there is not enought entropy by some pretty arbitrary estimate, and that this behavior is almost never what you require.

tptacek 13y ago

Another misconception. Talking about urandom is a little like playing whack-a-mole. Both random and urandom "self-heal"; they both continually rekey based on new entropy events. But there is no meaningful security benefit to giving your application control over that rekeying, which is effectively what /dev/random does by having your application sleep until some arbitrary counter elapses.