3 ms·

You can call it a bug or design flaw if you'd like, but this behaviour is documented, well known, and it's how every single Linux system operates. urandom simp

by tveita 13y ago

You can call it a bug or design flaw if you'd like, but this behaviour is documented, well known, and it's how every single Linux system operates. urandom simply isn't guaranteed to be random enough for cryptographic keys. Misusing it for this causes real-world problems. You are telling people to write insecure software. That it could be secure if Linux worked differently from how it actually works is completely irrelevant and bordering on denialism. If you want to fix Linux to be more like the other systems, great! Then /dev/random will be non-blocking and everyone can use that. Meanwhile, I'd much rather block than find myself sharing prime factors with random strangers.

tptacek 13y ago
On the one hand you have Nacl, from Daniel J. Bernstein, Tanja Lange, and Peter Schwabe, the gold standard of misuse-resistant crypto libraries, relying entirely on urandom and documenting why. On the other, you have HN's 'tveita, saying that urandom "isn't guaranteed to be random enough for cryptographic keys". I could continue the argument, but since the whole post you're commenting on is that argument, I'd be repeating myself. So instead, I'll just ask: what specific assertion in that post do you disagree with?
- tveita 13y ago
  How about the very post I replied to? > the bug that is Linux's willingness to give you output from an unseeded RNG So there you have it. But don't worry, no one uses this "Linux" thing, certainly not in embedded systems. https://factorable.net/ https://factorable.net/
  - tptacek 13y ago
    Keep reading. I think you stopped too early.
    - tveita 13y ago
      I read it all, don't be a jerk. When you're writing a program for generic use, you can't trust the underlying system to be set up above and beyond a stock install. If you want to use seeding as a workaround, it should be done from every program that requires secure randomness. That doesn't seem to be what you're advocating. And if you're just generating a key, why not read it directly from random instead? You can pretend that urandom gives good randomness and be surprised when you get key collisions. Just like you can pretend that strncpy null-terminates strings and be surprised when you get a buffer overflow vulnerability. That makes you a menace. For what's it's worth, I agree that an adequately seeded CSPRNG should never 'run out' of entropy, and I wouldn't mind if Linux got a BSD-style shared random/urandom. But as it stands, urandom is not guaranteed to be adequately seeded, and I have no idea why you would advocate taking that risk.
      - tptacek 13y ago
        Oh, we're talking past each other. Sorry. When I said "post", I meant the story this thread links to, not the comment thread. I believe you read the comments in their entirety. I think if you reread the post, you'd see that it rebuts your argument.
        luke-stanley 13y ago
        For encryption, the only way to be really secure is to have the same amount of randomness as there is data to encrypt, as a shared key. (A one time pad.) This isn't that hard to do so long as you can give it to the people that need it ahead of time, and should solve all kinds of theoretical problems. Mailing memory cards sealed in photoed glitter paint could work well too. It would be fun to 3D print a replica though.

by tveita 13y ago

tptacek 13y ago

On the one hand you have Nacl, from Daniel J. Bernstein, Tanja Lange, and Peter Schwabe, the gold standard of misuse-resistant crypto libraries, relying entirely on urandom and documenting why. On the other, you have HN's 'tveita, saying that urandom "isn't guaranteed to be random enough for cryptographic keys". I could continue the argument, but since the whole post you're commenting on is that argument, I'd be repeating myself. So instead, I'll just ask: what specific assertion in that post do you disagree with?

tveita 13y ago
How about the very post I replied to? > the bug that is Linux's willingness to give you output from an unseeded RNG So there you have it. But don't worry, no one uses this "Linux" thing, certainly not in embedded systems. https://factorable.net/ https://factorable.net/
- tptacek 13y ago
  Keep reading. I think you stopped too early.
  - tveita 13y ago
    I read it all, don't be a jerk. When you're writing a program for generic use, you can't trust the underlying system to be set up above and beyond a stock install. If you want to use seeding as a workaround, it should be done from every program that requires secure randomness. That doesn't seem to be what you're advocating. And if you're just generating a key, why not read it directly from random instead? You can pretend that urandom gives good randomness and be surprised when you get key collisions. Just like you can pretend that strncpy null-terminates strings and be surprised when you get a buffer overflow vulnerability. That makes you a menace. For what's it's worth, I agree that an adequately seeded CSPRNG should never 'run out' of entropy, and I wouldn't mind if Linux got a BSD-style shared random/urandom. But as it stands, urandom is not guaranteed to be adequately seeded, and I have no idea why you would advocate taking that risk.
    - tptacek 13y ago
      Oh, we're talking past each other. Sorry. When I said "post", I meant the story this thread links to, not the comment thread. I believe you read the comments in their entirety. I think if you reread the post, you'd see that it rebuts your argument.
      - luke-stanley 13y ago
        For encryption, the only way to be really secure is to have the same amount of randomness as there is data to encrypt, as a shared key. (A one time pad.) This isn't that hard to do so long as you can give it to the people that need it ahead of time, and should solve all kinds of theoretical problems. Mailing memory cards sealed in photoed glitter paint could work well too. It would be fun to 3D print a replica though.