Live data from Hacker News

How to safely generate a random number

sockpuppet.org

21–30 of 62 posts

Re: How to safely generate a random number

#21
post #14

Earlier quoted context omitted.

The article doesn't care how you use the OpenSSL commands; it's concerned with code you write that might need a CSPRNG. If you're writing code, don't use OpenSSL's CSPRNG.

So code that I write that generates keys using OpenSSL isn't indirectly depending on OpenSSL's CSPRNG? Sorry for all the questions. I just want to make sure I'm doing it right and I suspect I'm not the only one that is confused by the article's assertions.

The article (I'm its author) is about programming; it doesn't have strong opinions about how you e.g. configure nginx.

As for keys: it depends on the kinds of keys you're generating. If you're building on OpenSSL's primitives --- which, don't --- it'll be hard to get an RSA key without invoking the OpenSSL CSPRNG. But it's not at all hard to avoid OpenSSL's CSPRNG for AES.

Re: How to safely generate a random number

#22
post #13

Earlier quoted context omitted.

I would definitely avoid Java's SecureRandom. It means too many different things depending on what platform you're on. Meanwhile, XORing SHA1PRNG against /dev/urandom seems cryptographically nonsensical.

> XORing SHA1PRNG against /dev/urandom seems cryptographically nonsensical. Untrue! Assuming that the two (/dev/urandom and SHA1PRNG) are not correlated, the resulting output will be at least as secure as the most secure of the two. This means that (for example) if SHA1PRNG is found to be breakable, SecureRandom will still be at least as secure as /dev/urandom, and vice versa.

This is a rabbit hole I don't want to go down and so I will concede the point about NativePRNG, while sticking to my guns on "avoid the Java SecureRandom interface".

Re: How to safely generate a random number

#23
post #13

Earlier quoted context omitted.

I would definitely avoid Java's SecureRandom. It means too many different things depending on what platform you're on. Meanwhile, XORing SHA1PRNG against /dev/urandom seems cryptographically nonsensical.

If you want a cross-platform secure random source, you can't rely on /dev/urandom existing, so I'm not sure what alternative you're suggesting here.

You can't on the one hand say that OpenJDK Unix SecureRandom uses urandom so it's OK while on the other hand saying that SecureRandom is preferable because it works on platforms without urandom. That's the problem with SecureRandom: it's hard to know exactly what it's doing, as the Android team discovered last year.

(On Windows, I'd use CryptGenRandom, although it inspires even less confidence than Linux /dev/random).

Re: How to safely generate a random number

#24
post #23

Earlier quoted context omitted.

If you want a cross-platform secure random source, you can't rely on /dev/urandom existing, so I'm not sure what alternative you're suggesting here.

You can't on the one hand say that OpenJDK Unix SecureRandom uses urandom so it's OK while on the other hand saying that SecureRandom is preferable because it works on platforms without urandom. That's the problem with SecureRandom: it's hard to know exactly what it's doing, as the Android team discovered last year. (On Windows, I'd use CryptGenRandom, although it inspires even less confidence than Linux /dev/random)…

If you're ever in Redmond, stop by and we'll go inspire some confidence with the folks maintaining it.

Re: How to safely generate a random number

#26
post #23

Earlier quoted context omitted.

You can't on the one hand say that OpenJDK Unix SecureRandom uses urandom so it's OK while on the other hand saying that SecureRandom is preferable because it works on platforms without urandom. That's the problem with SecureRandom: it's hard to know exactly what it's doing, as the Android team discovered last year. (On Windows, I'd use CryptGenRandom, although it inspires even less confidence than Linux /dev/random)…

If you're ever in Redmond, stop by and we'll go inspire some confidence with the folks maintaining it.

Two immediate questions: forward secrecy and CryptGenRandom's state relative to other WinAPI processes. As in, I'm very clear how the Unix security model protects /dev/random, and less clear about Windows. Some of my C.G.R. thoughts are probably dated. But it's the system CSPRNG, and I think, just use the system CSPRNG.

Re: How to safely generate a random number

#30
post #27

> For cryptography, you don’t usually want “true random”. Wait what? I thought I wanted actually random numbers.

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...
Post reply on HN