6 ms·
How to safely generate a random number
- weavejester 13y agoSo 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?
- SamReidHughes2 13y agoWhere does this article say that?
- jbaudanza 13y agoThe article lists several userspace libraries (OpenSSL, SecureRandom) and then says not to use them. I had the same question as weavejester.
- tptacek 13y agoNo. 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.
- weavejester 13y agoThe 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.
- tptacek 13y agoI 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.
- TheLoneWolfling 13y ago> 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.
- tptacek 13y agoThis 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".
- weavejester 13y agoIf 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.
- tptacek 13y agoYou 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).
- marshray 13y agoIf you're ever in Redmond, stop by and we'll go inspire some confidence with the folks maintaining it.
- jbaudanza 13y agoThat 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.
- tptacek 13y agoThe 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.
- jbaudanza 13y agoSo 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.
- tptacek 13y agoThe 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.
- jbaudanza 13y agoThanks for clarifying. My project depends on bitcoin-ruby, which uses OpenSSL's EC_KEY_generate_key to generate keys. EC_KEY_generate_key, as far as I can tell, uses OpenSSLs internal PRNG. If I understand you correctly, this is unsafe and it would be better to derive a key from urandom.
- tptacek 13y ago
- tptacek 13y agoIf 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.
- cratermoon 13y agoAnyone want to give a total count of wrong assertions in this article?
- spartanatreyu 13y agoI liked the part that said "urandom".
- csense 13y agoI prefer the Munroe-Hatguy entropy collection method for pseudorandom number generation [1]. [1] http://xkcd.com/221/ http://xkcd.com/221/
- marshray 13y agoI knew that link was going to show up. It's predictable that way.
- eliteraspberrie 13y agoUse 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...
- pbsd 13y 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.
- eliteraspberrie 13y agoNo, libsodium does not do the same thing as NaCl. NaCl: https://gist.github.com/anonymous/9234738 https://gist.github.com/anonymous/9234738 libsodium: https://github.com/jedisct1/libsodium/blob/master/src/libsodium/randombytes/sysrandom/randombytes_sysrandom.c https://github.com/jedisct1/libsodium/blob/master/src/libsod...
- pbsd 13y agoI'm aware that the implementations are not strictly equal, but how is libsodium doing it 'wrong'? Is it because it does not partition reads into smaller chunks (avoiding the unspecified >= SSIZE_MAX read)? I consider any reasonable answer a valid bug report. I should also point out that randombytes is technically not part of NaCl. The authors maintain that random byte generation is out of scope for NaCl, and what actually happens is that randombytes.o is bundled separately from libnacl.a [1]. In TweetNacl the randombytes implementation is completely omitted. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=20;bug=694248#20 https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=20;bug=694...
- 13y ago
- ars 13y 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 13y agoIf you want fast non-secure random numbers use Mersenne Twister: http://en.wikipedia.org/wiki/Mersenne_twister http://en.wikipedia.org/wiki/Mersenne_twister
- SamReidHughes2 13y agoYou can also get much faster secure random numbers.
- DanBC 13y ago> For cryptography, you don’t usually want “true random”. Wait what? I thought I wanted actually random numbers.
- tptacek 13y agoChapter 9 of _Cryptography Engineering_ leads off with a dozen or so paragraphs on why crypto software doesn't use real random.
- DanBC 13y agoThank you, I shall do some more (and better) reading.
- infogulch 13y agoI 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-use-of-real-random-number-generators-in-cryptography#comment3459_726 http://crypto.stackexchange.com/questions/726/what-is-the-us...
- anaphor 13y agoWhat about haveged? Is that good enough for crypto? http://www.issihosts.com/haveged/ http://www.issihosts.com/haveged/
- luke-stanley 13y agoWhy 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_in.html#c1909001 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?
- tptacek 13y agourandom 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-stanley 13y agoHow 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?
- lawnchair_larry 13y agoThis rant does more harm than good. Telling people not to use a library csprng is quite silly. Everything uses these and it's fine.
- tptacek 13y agoYeah 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 13y agoSo, what specifically did Matt Green disagree with?