Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to safely generate a random number

sockpuppet.org

Post reply on HN
Print view View original

41–50 of 62 posts

Re: How to safely generate a random number

#41

Post by luke-stanley »

tptacek wrote: post #38
luke-stanley wrote: post #35

Why is urandom meant to be more secure? I read this: "So I'm the maintainer for Linux's /dev/random driver. "... "The main thing which I am much more worried about is that on various embedded systems, which do not have a fine-grained clock, and which is reading from flash which has a much more deterministic timing for their operations, is that when userspace tries to generate long-term public keys immediately after t…

urandom and /dev/random aren't two different CSPRNGs. They aren't really even two different designs. They are two different pools into which the same kinds of raw entropy are mixed; the interface to /dev/random's pool happens to have a weird gate on it that tries to determine how much "entropy" is "left" in the pool. I'm oversimplifying a little, but that's the gist of it. So the problem here is, if you're on a solid…

How do we know there isn't some predictable pattern from common urandom sources? What is meant to make the state non-predictable anyway? If I cared about it, someone could just add a library on top of it that combines them with more entropy sources. Like camera noise, temperature changes, audio static etc. For some reason the author says not to build libraries on top of urandom because they might be hacked. Well if something has compromised your system anyway, why does that matter?

Re: How to safely generate a random number

#42

Post by tveita »

tptacek wrote: post #38
luke-stanley wrote: post #35

Why is urandom meant to be more secure? I read this: "So I'm the maintainer for Linux's /dev/random driver. "... "The main thing which I am much more worried about is that on various embedded systems, which do not have a fine-grained clock, and which is reading from flash which has a much more deterministic timing for their operations, is that when userspace tries to generate long-term public keys immediately after t…

urandom and /dev/random aren't two different CSPRNGs. They aren't really even two different designs. They are two different pools into which the same kinds of raw entropy are mixed; the interface to /dev/random's pool happens to have a weird gate on it that tries to determine how much "entropy" is "left" in the pool. I'm oversimplifying a little, but that's the gist of it. So the problem here is, if you're on a solid…

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.

Re: How to safely generate a random number

#43

Post by tptacek »

tveita wrote: post #42
tptacek wrote: post #38

Earlier quoted context omitted.

urandom and /dev/random aren't two different CSPRNGs. They aren't really even two different designs. They are two different pools into which the same kinds of raw entropy are mixed; the interface to /dev/random's pool happens to have a weird gate on it that tries to determine how much "entropy" is "left" in the pool. I'm oversimplifying a little, but that's the gist of it. So the problem here is, if you're on a solid…

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 irre…

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?

Re: How to safely generate a random number

#44

Post by tptacek »

luke-stanley wrote: post #41
tptacek wrote: post #38

Earlier quoted context omitted.

urandom and /dev/random aren't two different CSPRNGs. They aren't really even two different designs. They are two different pools into which the same kinds of raw entropy are mixed; the interface to /dev/random's pool happens to have a weird gate on it that tries to determine how much "entropy" is "left" in the pool. I'm oversimplifying a little, but that's the gist of it. So the problem here is, if you're on a solid…

How do we know there isn't some predictable pattern from common urandom sources? What is meant to make the state non-predictable anyway? If I cared about it, someone could just add a library on top of it that combines them with more entropy sources. Like camera noise, temperature changes, audio static etc. For some reason the author says not to build libraries on top of urandom because they might be hacked. Well if s…

"The urandom sources"? What do you think that means? The code is right there.

Re: How to safely generate a random number

#45

Post by tveita »

tptacek wrote: post #43
tveita wrote: post #42

Earlier quoted context omitted.

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 irre…

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 repe…

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/

Re: How to safely generate a random number

#46

Post by tptacek »

tveita wrote: post #45
tptacek wrote: post #43

Earlier quoted context omitted.

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 repe…

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/

Keep reading. I think you stopped too early.

Re: How to safely generate a random number

#47

Post by tveita »

tptacek wrote: post #46
tveita wrote: post #45

Earlier quoted context omitted.

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/

Keep reading. I think you stopped too early.

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.

Re: How to safely generate a random number

#49

Post by weavejester »

tptacek wrote: post #32
weavejester wrote: post #31

Earlier quoted context omitted.

I don't see any contradiction. SecureRandom uses urandom where it's available, and the next best alternative where it's not. Again, I'd like to know what your suggested solution is. The way I see it, you can either: 1) Don't write cross-platform code 2) Use the language implementation 3) Write your own cross-platform code Assuming (1) isn't an option, it comes down to using SecureRandom or writing your own version of…

If SecureRandom was simply "pull bytes from urandom" on Linux and "pull bytes from CryptGenRandom" on Windows, I wouldn't care enough to argue. But it's not. It's not even "pull bytes from urandom" on Linux; depending on the specific details of your platform, it can be dramatically different than that. I'm absolutely not recommending that people write their own version of SecureRandom; I'm advising the opposite. Avoi…

So I should write my own cross-platform interface to the system PRNG? Doesn't that strike you as more prone to error than relying on SecureRandom, which at least has the advantage of having many eyes on it.

Re: How to safely generate a random number

#50

Post by tptacek »

lawnchair_larry wrote: post #48

This rant does more harm than good. Telling people not to use a library csprng is quite silly. Everything uses these and it's fine.

Yeah I mean, there's probably never been a urandom-based vulnerability in ordinary software, and "library csprngs" are the reason every Debian SSH was compromised and the reason Android Bitcoin wallets were generating colliding keys, but sure. Everything's fine.
Post reply on HN