How to safely generate a random number

So rather than using a function in the core library of the language that calls /dev/urandom, we should instead write our own wrapper around /dev/urandom? And this is supposed to be less prone to error?

SamReidHughes22• 12 years ago

Where does this article say that?

jbaudanza4• 12 years ago

The article lists several userspace libraries (OpenSSL, SecureRandom) and then says not to use them. I had the same question as weavejester.

tptacek19• 12 years ago

If you know that's all your library does, as in the case of Golang crypto/rand, then use the library. But don't just assume that's all your library is doing.

eliteraspberrie3• 12 years ago

Use urandom, but that's not the end of it. It may be that urandom supports non-blocking reads. Most implementations only check if read() returns -1 then abort, without checking for EAGAIN, not to mention EINTR, or some other subtleties like making sure not to request more than SSIZE_MAX bytes. The randombytes function in NaCl does it right, unfortunately libsodium did their own thing.

If you use Python, read from os.urandom, which is a wrapper to the system's CSPRNG. Don't use random.randint or random.getrandbits...

pbsd3• 12 years ago

The randombytes function in NaCl does it right, unfortunately libsodium did their own thing.

I don't know what you're talking about. Sodium does the same thing as NaCl, while also being more portable.

eliteraspberrie3• 12 years ago

No, libsodium does not do the same thing as NaCl.

NaCl:

https://gist.github.com/anonymous/9234738

libsodium:

https://github.com/jedisct1/libsodium/blob/master/src/libsod...

vertex-four• 12 years ago

You can also use random.SystemRandom, which gives you the same interface as random.Random (and the random module) but as a wrapper around os.urandom.

ars• 12 years ago

/dev/urandom is slow. So don't use it if you need lots of non secure random numbers. For example for game, or for a screensaver, etc.

montecarl• 12 years ago

If you want fast non-secure random numbers use Mersenne Twister: http://en.wikipedia.org/wiki/Mersenne_twister

SamReidHughes22• 12 years ago

You can also get much faster secure random numbers.

DanBC2• 12 years ago

For cryptography, you don’t usually want “true random”.

Wait what? I thought I wanted actually random numbers.

tptacek19• 12 years ago

Chapter 9 of _Cryptography Engineering_ leads off with a dozen or so paragraphs on why crypto software doesn't use real random.

DanBC2• 12 years ago

Thank you, I shall do some more (and better) reading.

infogulch• 12 years ago

I thought the same thing. This comment on crypto.stackexchange.com[1] shed a bit of light for me:

    Yup, entropy sources may even have a particular bias to bits valued 0 or 1.
    Normally you need at least a whitening technique to get something looking
    like a random number. Feeding that as a seed into a PRNG is certainly
    helping to get the right quality. Be careful not to confuse a source of
    entropy with a secure random number generator.

[1] http://crypto.stackexchange.com/questions/726/what-is-the-us...

anaphor• 12 years ago

What about haveged? Is that good enough for crypto? http://www.issihosts.com/haveged/

luke-stanley4• 12 years ago

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 the machine is taken out of the box and plugged in, that there isn't a sufficient amount of entropy, and since most userspace applications use /dev/urandom since they don't want to block, that they end up with keys that aren't very random." - https://www.schneier.com/blog/archives/2013/10/insecurities_...

Is that out of date?

Why so insistent? Why not provide reasons that people can openly verify?

tptacek19• 12 years ago

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 state embedded system that doesn't generate enough entropy to drive urandom, you're not doing enough to drive /dev/random either --- except, owing to a design flaw in Linux, on first-boot-ever, where /dev/random's entropy estimator gate saves from you from the bug that is Linux's willingness to give you output from an unseeded RNG. It shouldn't do that. FreeBSD doesn't. But if you're worried about that problem, the correct fix is to explicitly seed urandom from /dev/random on boot, not to use /dev/random in your code!

Once the CSPRNG is seeded, the idea of a "sufficient amount of entropy" is silly. Think of a CSPRNG as a stream cipher. Think of its output as you would the keystream of that cipher. What does it mean, within reason (ie, not hundreds of terabytes) for a keystream to have "sufficient" key in it? Because that's essentially the same question the maintainer for /dev/random is asking.

luke-stanley4• 12 years ago

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?

tveita3• 12 years 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.

lawnchair_larry• 12 years ago

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.

tptacek19• 12 years ago

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.

BasicBlock• 12 years ago

So, what specifically did Matt Green disagree with?

How to safely generate a random number

Related Stories