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

11–20 of 62 posts

Re: How to safely generate a random number

#11

Post by weavejester »

tptacek wrote: post #9
jbaudanza wrote: post #8

Earlier quoted context omitted.

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

No. OpenSSL RAND_bytes and Java SecureRandom aren't simply libraries that "call /dev/urandom"; they are full-fledged CSPRNG designs, and must themselves avoid all the possible bugs a CSPRNG can have, in addition to their usual reliance on urandom not itself being vulnerable.

The NativePRNG algorithm for SecureRandom XORs /dev/urandom with a SHA1PRNG seeded from /dev/urandom, so as long as the XOR is correct, it should be no less secure than reading from /dev/urandom directly.

Re: How to safely generate a random number

#12

Post by jbaudanza »

tptacek wrote: post #9
jbaudanza wrote: post #8

Earlier quoted context omitted.

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

No. OpenSSL RAND_bytes and Java SecureRandom aren't simply libraries that "call /dev/urandom"; they are full-fledged CSPRNG designs, and must themselves avoid all the possible bugs a CSPRNG can have, in addition to their usual reliance on urandom not itself being vulnerable.

That makes more sense. So which of the following is true: 1) I shouldn't be using OpenSSL to generate keys without somehow injecting bytes directly /dev/urandom 2) The article is wrong, using OpenSSL's CSPRNG is fine. 3) I still don't get it.

Re: How to safely generate a random number

#13

Post by tptacek »

weavejester wrote: post #11
tptacek wrote: post #9

Earlier quoted context omitted.

No. OpenSSL RAND_bytes and Java SecureRandom aren't simply libraries that "call /dev/urandom"; they are full-fledged CSPRNG designs, and must themselves avoid all the possible bugs a CSPRNG can have, in addition to their usual reliance on urandom not itself being vulnerable.

The NativePRNG algorithm for SecureRandom XORs /dev/urandom with a SHA1PRNG seeded from /dev/urandom, so as long as the XOR is correct, it should be no less secure than reading from /dev/urandom directly.

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.

Re: How to safely generate a random number

#14

Post by tptacek »

jbaudanza wrote: post #12
tptacek wrote: post #9

Earlier quoted context omitted.

No. OpenSSL RAND_bytes and Java SecureRandom aren't simply libraries that "call /dev/urandom"; they are full-fledged CSPRNG designs, and must themselves avoid all the possible bugs a CSPRNG can have, in addition to their usual reliance on urandom not itself being vulnerable.

That makes more sense. So which of the following is true: 1) I shouldn't be using OpenSSL to generate keys without somehow injecting bytes directly /dev/urandom 2) The article is wrong, using OpenSSL's CSPRNG is fine. 3) I still don't get it.

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.

Re: How to safely generate a random number

#15

Post by eliteraspberrie »

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...

Re: How to safely generate a random number

#16

Post by jbaudanza »

tptacek wrote: post #14
jbaudanza wrote: post #12

Earlier quoted context omitted.

That makes more sense. So which of the following is true: 1) I shouldn't be using OpenSSL to generate keys without somehow injecting bytes directly /dev/urandom 2) The article is wrong, using OpenSSL's CSPRNG is fine. 3) I still don't get it.

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.

Re: How to safely generate a random number

#18

Post by TheLoneWolfling »

tptacek wrote: post #13
weavejester wrote: post #11

Earlier quoted context omitted.

The NativePRNG algorithm for SecureRandom XORs /dev/urandom with a SHA1PRNG seeded from /dev/urandom, so as long as the XOR is correct, it should be no less secure than reading from /dev/urandom directly.

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.

Re: How to safely generate a random number

#19

Post by pbsd »

eliteraspberrie wrote: post #15

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

> 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.

Re: How to safely generate a random number

#20

Post by weavejester »

tptacek wrote: post #13
weavejester wrote: post #11

Earlier quoted context omitted.

The NativePRNG algorithm for SecureRandom XORs /dev/urandom with a SHA1PRNG seeded from /dev/urandom, so as long as the XOR is correct, it should be no less secure than reading from /dev/urandom directly.

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