Pastebin
API
tools
faq
paste
Login
Sign up
Please fix the following errors:
New Paste
Syntax Highlighting
<link rel="preconnect" href="https://fonts.gstatic.com"> <link href="https://fonts.googleapis.com/css2?family=Open+Sans:ital,wght@0,300;0,400;0,600;0,700;0,800;1,300;1,400;1,600;1,700;1,800&display=swap" rel="stylesheet"> <body style="margin: 0;"> <div style="display: flex; flex-direction: column; margin: 0 auto; padding: 60px 80px; max-width: 800px;"> <span style="font-family: Open Sans; font-size: 24px; font-weight: 700;">Misconceptions about /dev/urandom</span> <span style="margin-top: 5px; font-family: Open Sans; font-size: 14px;">by <span style="font-weight: 600;">Thomas Hühn</span></span> <span style="margin-top: 20px; font-family: Open Sans; font-size: 16px; color: #444444;">There are a few misconceptions about /dev/urandom and /dev/random that keep being repeated over and over again. Here are some misconceptions and why they're so.</span> <span style="margin: 30px 0 0 auto; padding: 5px 10px; font-family: Open Sans; font-size: 14px; background-color: #000000; color: #ffffff;">im mostly talking about recent Linux systems, not other UNIX-like systems</span> <div style="display: flex; margin-top: 30px;"> <spans style="font-family: Open Sans; font-size: 16px; color: #999999;">1/6.</spans> <div style="display: flex; flex-direction: column; margin-left: 10px;"> <span style="font-family: Open Sans; font-size: 16px; color: #444444; text-decoration: line-through;">/dev/urandom is insecure! always use /dev/random for cryptographic purposes.</span> <span style="margin-top: 5px; font-family: Open Sans; font-size: 16px; font-weight: 600;">/dev/urandom is the preferred source of cryptographic randomness on UNIX-like systems.</span> </div> </div> <div style="display: flex; margin-top: 30px;"> <spans style="font-family: Open Sans; font-size: 16px; color: #999999;">2/6.</spans> <div style="display: flex; flex-direction: column; margin-left: 10px;"> <span style="font-family: Open Sans; font-size: 16px; color: #444444; text-decoration: line-through;">/dev/urandom is a pseudo random number generator, a PRNG, while /dev/random is a “true” random number generator.</span> <span style="margin-top: 5px; font-family: Open Sans; font-size: 16px; font-weight: 600;">Both /dev/urandom and /dev/random are using the exact same CSPRNG (a cryptographically secure pseudorandom number generator). They differ but in very few ways, ways which have nothing to do with “true” randomness.</span> </div> </div> <div style="display: flex; margin-top: 30px;"> <spans style="font-family: Open Sans; font-size: 16px; color: #999999;">3/6.</spans> <div style="display: flex; flex-direction: column; margin-left: 10px;"> <span style="font-family: Open Sans; font-size: 16px; color: #444444; text-decoration: line-through;">/dev/random is unambiguously the better choice for cryptography. Even if /dev/urandom were comparably secure, there's no reason to choose the latter.</span> <span style="margin-top: 5px; font-family: Open Sans; font-size: 16px; font-weight: 600;">/dev/random has a very nasty problem: it blocks.</span> </div> </div> <div style="display: flex; margin-top: 30px;"> <spans style="font-family: Open Sans; font-size: 16px; color: #999999;">4/6.</spans> <div style="display: flex; flex-direction: column; margin-left: 10px;"> <span style="font-family: Open Sans; font-size: 16px; color: #444444; text-decoration: line-through;">But that's good! /dev/random gives out exactly as much randomness as it has entropy in its pool. /dev/urandom will give you insecure random numbers, even though it has long run out of entropy.</span> <span style="margin-top: 5px; font-family: Open Sans; font-size: 16px; font-weight: 600;">No. Even disregarding issues like availability and subsequent manipulation by users, the issue of entropy “running low” is a straw man. About 256 bits of entropy are enough to get computationally secure numbers for a long, long time.<br><br>And the fun only starts here: how does /dev/random know how much entropy there is available to give out? Stay tuned!</span> </div> </div> <div style="display: flex; margin-top: 30px;"> <spans style="font-family: Open Sans; font-size: 16px; color: #999999;">5/6.</spans> <div style="display: flex; flex-direction: column; margin-left: 10px;"> <span style="font-family: Open Sans; font-size: 16px; color: #444444; text-decoration: line-through;">But cryptographers always talk about constant re-seeding. Doesn't that contradict your last point?</span> <span style="margin-top: 5px; font-family: Open Sans; font-size: 16px; font-weight: 600;">You got me! Kind of. It is true, the random number generator is constantly re-seeded using whatever entropy the system can lay its hands on. But that has (partly) other reasons.<br><br>Look, I don't claim that injecting entropy is bad. It's good. I just claim that it's bad to block when the entropy estimate is low.</span> </div> </div> <div style="display: flex; margin-top: 30px;"> <spans style="font-family: Open Sans; font-size: 16px; color: #999999;">6/6.</spans> <div style="display: flex; flex-direction: column; margin-left: 10px;"> <span style="font-family: Open Sans; font-size: 16px; color: #444444; text-decoration: line-through;">That's all good and nice, but even the man page for /dev/(u)random contradicts you! Does anyone who knows about this stuff actually agree with you?</span> <span style="margin-top: 5px; font-family: Open Sans; font-size: 16px; font-weight: 600;">No, it really doesn't. It seems to imply that /dev/urandom is insecure for cryptographic use, unless you really understand all that cryptographic jargon.<br><br>The man page does recommend the use of /dev/random in some cases (it doesn't hurt, in my opinion, but is not strictly necessary), but it also recommends /dev/urandom as the device to use for “normal” cryptographic use.<br><br>And while appeal to authority is usually nothing to be proud of, in cryptographic issues you're generally right to be careful and try to get the opinion of a domain expert.<br></br>And yes, quite a few experts share my view that /dev/urandom is the go-to solution for your random number needs in a cryptography context on UNIX-like systems. Obviously, their opinions influenced mine, not the other way around.</span> </div> </div> <div style="display: flex; flex-direction: column; margin-top: 30px; padding-top: 30px; border-top: 1px solid #f1f1f1;"> <span style="font-family: Open Sans; font-size: 20px; font-weight: 700;">"Are you saying that I'm stupid?"</span> <span style="margin-top: 20px; font-family: Open Sans; font-size: 16px;">You misunderstand me!<br><br>Actually, I used to believe that /dev/urandom was insecure myself, a few years ago. And it's something you and I almost had to believe, because all those highly respected people on Usenet, in web forums and today on Twitter told us. Even the man page seems to say so. Who were we to dismiss their convincing argument about “entropy running low”?<br><br>This misconception isn't so rampant because people are stupid, it is because with a little knowledge about cryptography (namely some vague idea what entropy is) it's very easy to be convinced of it. Intuition almost forces us there. Unfortunately, intuition is often wrong in cryptography. So it is here.</span> </div> <div style="display: flex; flex-direction: column; margin-top: 30px; padding-top: 30px; border-top: 1px solid #f1f1f1;"> <span style="font-family: Open Sans; font-size: 20px; font-weight: 700;">"What is that 'true randomness', then?"</span> <span style="margin-top: 20px; font-family: Open Sans; font-size: 16px;">I don't want to dive into that issue too deep, because it quickly gets philosophical. Discussions have been known to unravel quickly, because everyone can wax about their favorite model of randomness, without paying attention to anyone else. Or even making himself understood.<br><br>I believe that the “gold standard” for “true randomness” are quantum effects. Observe a photon pass through a semi-transparent mirror. Or not. Observe some radioactive material emit alpha particles. It's the best idea we have when it comes to randomness in the world. Other people might reasonably believe that those effects aren't truly random. Or even that there is no randomness in the world at all. Let a million flowers bloom.<br><br>Cryptographers often circumvent this philosophical debate by disregarding what it means for randomness to be “true”. They care about unpredictability. As long as nobody can get any information about the next random number, we're fine. And when you're talking about random numbers as a prerequisite in using cryptography, that's what you should aim for, in my opinion.<br><br>Anyway, I don't care much about those “philosophically secure” random numbers, as I like to think of your “true” random numbers.</span> <span style="margin-top: 20px; font-family: Open Sans; font-size: 18px; font-weight: 700;">Two kinds of security, one that matters</span> <span style="margin-top: 20px; font-family: Open Sans; font-size: 16px;">But let's assume you've obtained those “true” random numbers. What are you going to do with them?<br><br>You print them out, frame them and hang them on your living-room wall, to revel in the beauty of a quantum universe? That's great, and I certainly understand.<br><br>Wait, what? You're using them? For cryptographic purposes? Well, that spoils everything, because now things get a bit ugly.<br><br>You see, your truly-random, quantum effect blessed random numbers are put into some less respectable, real-world tarnished algorithms.<br><br>Because almost all of the cryptographic algorithms we use do not hold up to information-theoretic security. They can “only” offer computational security. The two exceptions that come to my mind are Shamir's Secret Sharing and the One-time pad. And while the first one may be a valid counterpoint (if you actually intend to use it), the latter is utterly impractical.<br><br>But all those algorithms you know about, AES, RSA, Diffie-Hellman, Elliptic curves, and all those crypto packages you're using, OpenSSL, GnuTLS, Keyczar, your operating system's crypto API, these are only computationally secure.<br><br>What's the difference? While information-theoretically secure algorithms are secure, period, those other algorithms cannot guarantee security against an adversary with unlimited computational power who's trying all possibilities for keys. We still use them because it would take all the computers in the world taken together longer than the universe has existed, so far. That's the level of “insecurity” we're talking about here.<br><br>Unless some clever guy breaks the algorithm itself, using much less computational power. Even computational power achievable today. That's the big prize every cryptanalyst dreams about: breaking AES itself, breaking RSA itself and so on.<br><br>So now we're at the point where you don't trust the inner building blocks of the random number generator, insisting on “true randomness” instead of “pseudo randomness”. But then you're using those “true” random numbers in algorithms that you so despise that you didn't want them near your random number generator in the first place!<br><br>Truth is, when state-of-the-art hash algorithms are broken, or when state-of-the-art block ciphers are broken, it doesn't matter that you get “philosophically insecure” random numbers because of them. You've got nothing left to securely use them for anyway.<br><br>So just use those computationally-secure random numbers for your computationally-secure algorithms. In other words: use /dev/urandom.</span> </div> <div style="display: flex; flex-direction: column; margin-top: 30px; padding-top: 30px; border-top: 1px solid #f1f1f1;"> <span style="font-family: Open Sans; font-size: 20px; font-weight: 700;">Structure of Linux's random number generator</span> <span style="margin-top: 20px; font-family: Open Sans; font-size: 16px;">Chances are, your idea of the kernel's random number generator is something similar to this:</span> <img style="margin-top: 20px;" src="https://www.2uo.de/myths-about-urandom/structure-no-73d42e4b.png"> <span style="margin: 0 auto; padding: 5px 10px; font-family: Open Sans; font-size: 14px; background-color: #000000; color: #ffffff;">supposed structure of the kernel's random number generator</span> <span style="margin-top: 20px; font-family: Open Sans; font-size: 16px;">“True randomness”, albeit possibly skewed and biased, enters the system and its entropy is precisely counted and immediately added to an internal entropy counter. After de-biasing and whitening it's entering the kernel's entropy pool, where both /dev/random and /dev/urandom get their random numbers from.<br><br>The “true” random number generator, /dev/random, takes those random numbers straight out of the pool, if the entropy count is sufficient for the number of requested numbers, decreasing the entropy counter, of course. If not, it blocks until new entropy has entered the system.<br>The important thing in this narrative is that /dev/random basically yields the numbers that have been input by those randomness sources outside, after only the necessary whitening. Nothing more, just pure randomness.<br><br>/dev/urandom, so the story goes, is doing the same thing. Except when there isn't sufficient entropy in the system. In contrast to /dev/random, it does not block, but gets “low quality random” numbers from a pseudorandom number generator (conceded, a cryptographically secure one) that is running alongside the rest of the random number machinery. This CSPRNG is just seeded once (or maybe every now and then, it doesn't matter) with “true randomness” from the randomness pool, but you can't really trust it.<br><br>In this view, that seems to be in a lot of people's minds when they're talking about random numbers on Linux, avoiding /dev/urandom is plausible.<br><br>Because either there is enough entropy left, then you get the same you'd have gotten from /dev/random. Or there isn't, then you get those low-quality random numbers from a CSPRNG that almost never saw high-entropy input.<br><br>Devilish, right? Unfortunately, also utterly wrong. In reality, the internal structure of the random number generator looks like this.</span> <span style="margin-top: 20px; font-family: Open Sans; font-size: 18px; font-weight: 700;">Before Linux 4.8</span> <img style="margin-top: 20px;" src="https://www.2uo.de/myths-about-urandom/structure-yes-c3cb7536.png"> <span style="margin: 0 auto; padding: 5px 10px; font-family: Open Sans; font-size: 14px; background-color: #000000; color: #ffffff;">actual structure of the kernel's random number generator before Linux 4.8</span> <span style="margin-top: 20px; font-family: Open Sans; font-size: 16px;">See the big difference? The CSPRNG is not running alongside the random number generator, filling in for those times when /dev/urandom wants to output something, but has nothing good to output. The CSPRNG is an integral part of the random number generation process. There is no /dev/random handing out “good and pure” random numbers straight from the whitener. Every randomness source's input is thoroughly mixed and hashed inside the CSPRNG, before it emerges as random numbers, either via /dev/urandom or /dev/random.</span> <span style="margin-top: 20px; padding: 5px 10px; font-family: Open Sans; font-size: 14px; background-color: #000000; color: #ffffff;">this is a pretty rough simplification. in fact, there isn't just one, but three pools filled with entropy. one primary pool, and one for /dev/random and /dev/urandom each, feeding off the primary pool. those three pools all have their own entropy counts, but the counts of the secondary pools (for /dev/random and /dev/urandom) are mostly close to zero, and “fresh” entropy flows from the primary pool when needed, decreasing its entropy count. also there is a lot of mixing and re-injecting outputs back into the system going on. all of this is far more detail than is necessary for this document.</span> <span style="margin-top: 20px; font-family: Open Sans; font-size: 16px;">Another important difference is that there is no entropy counting going on here, but estimation. The amount of entropy some source is giving you isn't something obvious that you just get, along with the data. It has to be estimated. Please note that when your estimate is too optimistic, the dearly held property of /dev/random, that it's only giving out as many random numbers as available entropy allows, is gone. Unfortunately, it's hard to estimate the amount of entropy.<br><br>The Linux kernel uses only the arrival times of events to estimate their entropy. It does that by interpolating polynomials of those arrival times, to calculate “how surprising” the actual arrival time was, according to the model. Whether this polynomial interpolation model is the best way to estimate entropy is an interesting question. There is also the problem that internal hardware restrictions might influence those arrival times. The sampling rates of all kinds of hardware components may also play a role, because they directly influence the values and the granularity of those event arrival times.<br><br>In the end, to the best of our knowledge, the kernel's entropy estimate is pretty good. Which means it's conservative. People argue about how good it really is, but that issue is far above my head. Still, if you insist on never handing out random numbers that are not “backed” by sufficient entropy, you might be nervous here. I'm sleeping sound because I don't care about the entropy estimate.<br><br>So to make one thing crystal clear: both /dev/random and /dev/urandom are fed by the same CSPRNG. Only the behavior when their respective pool runs out of entropy, according to some estimate, differs: /dev/random blocks, while /dev/urandom does not.</span> <span style="margin-top: 20px; font-family: Open Sans; font-size: 18px; font-weight: 700;">From Linux 4.8 onward</span> <span style="margin-top: 20px; font-family: Open Sans; font-size: 16px;">In Linux 4.8 the equivalency between /dev/urandom and /dev/random was given up. Now /dev/urandom output does not come from an entropy pool, but directly from a CSPRNG.</span> <img style="margin-top: 20px;" src="https://www.2uo.de/myths-about-urandom/structure-new-728f5983.png"> <span style="margin: 0 auto; padding: 5px 10px; font-family: Open Sans; font-size: 14px; background-color: #000000; color: #ffffff;">actual structure of the kernel's random number generator from Linux 4.8 onward</span> </div> <div style="display: flex; flex-direction: column; margin-top: 30px; padding-top: 30px; border-top: 1px solid #f1f1f1;"> <span style="font-family: Open Sans; font-size: 20px; font-weight: 700;">"What's wrong with blocking?"</span> <span style="margin-top: 20px; font-family: Open Sans; font-size: 16px;">Have you ever waited for /dev/random to give you more random numbers? Generating a PGP key inside a virtual machine maybe? Connecting to a web server that's waiting for more random numbers to create an ephemeral session key?<br><br>That's the problem. It inherently runs counter to availability. So your system is not working. It's not doing what you built it to do. Obviously, that's bad. You wouldn't have built it if you didn't need it.<br><br>But the problem runs even deeper: people don't like to be stopped in their ways. They will devise workarounds, concoct bizarre machinations to just get it running. People who don't know anything about cryptography. Normal people.</span> <span style="margin-top: 20px; padding: 5px 10px; font-family: Open Sans; font-size: 14px; background-color: #000000; color: #ffffff;">im working on safety-related systems in factory automation. can you guess what the main reason for failures of safety systems is? manipulation. simple as that. something about the safety measure bugged the worker. it took too much time, was too inconvenient, whatever. people are very resourceful when it comes to finding “inofficial solutions”.</span> <span style="margin-top: 20px; font-family: Open Sans; font-size: 16px;">Why not patching out the call to random()? Why not having some guy in a web forum tell you how to use some strange ioctl to increase the entropy counter? Why not switch off SSL altogether?<br><br>In the end you just educate your users to do foolish things that compromise your system's security without you ever knowing about it.<br><br>It's easy to disregard availability, usability or other nice properties. Security trumps everything, right? So better be inconvenient, unavailable or unusable than feign security.<br><br>But that's a false dichotomy. Blocking is not necessary for security. As we saw, /dev/urandom gives you the same kind of random numbers as /dev/random, straight out of a CSPRNG. Use it!</span> </div> <div style="display: flex; flex-direction: column; margin-top: 30px; padding-top: 30px; border-top: 1px solid #f1f1f1;"> <span style="font-family: Open Sans; font-size: 20px; font-weight: 700;">The CSPRNGs are alright</span> <span style="margin-top: 20px; font-family: Open Sans; font-size: 16px;">But now everything sounds really bleak. If even the high-quality random numbers from /dev/random are coming out of a CSPRNG, how can we use them for high-security purposes?<br><br>It turns out, that “looking random” is the basic requirement for a lot of our cryptographic building blocks. If you take the output of a cryptographic hash, it has to be indistinguishable from a random string so that cryptographers will accept it. If you take a block cipher, its output (without knowing the key) must also be indistinguishable from random data.<br><br>If anyone could gain an advantage over brute force breaking of cryptographic building blocks, using some perceived weakness of those CSPRNGs over “true” randomness, then it's the same old story: you don't have anything left. Block ciphers, hashes, everything is based on the same mathematical fundament as CSPRNGs. So don't be afraid</span> </div> <div style="display: flex; flex-direction: column; margin-top: 30px; padding-top: 30px; border-top: 1px solid #f1f1f1;"> <span style="font-family: Open Sans; font-size: 20px; font-weight: 700;">What about entropy running low?</span> <span style="margin-top: 20px; font-family: Open Sans; font-size: 16px;">It doesn't matter.<br><br>The underlying cryptographic building blocks are designed such that an attacker cannot predict the outcome, as long as there was enough randomness (a.k.a. entropy) in the beginning. A usual lower limit for “enough” may be 256 bits. No more.<br><br>Considering that we were pretty hand-wavey about the term “entropy” in the first place, it feels right. As we saw, the kernel's random number generator cannot even precisely know the amount of entropy entering the system. Only an estimate. And whether the model that's the basis for the estimate is good enough is pretty unclear, too.<br><br>But if entropy is so unimportant, why is fresh entropy constantly being injected into the random number generator?<br><br>First, it cannot hurt. If you've got more randomness just lying around, by all means use it!</span> <a style="margin: 30px 0 0 auto; padding: 5px 10px; font-family: Open Sans; font-size: 14px; background-color: #000000; color: #ffffff;" href="http://blog.cr.yp.to/20140205-entropy.html">djb remarked that more entropy actually can hurt</a> <span style="margin-top: 20px; font-family: Open Sans; font-size: 16px;">There is another reason why re-seeding the random number generator every now and then is important:<br><br>Imagine an attacker knows everything about your random number generator's internal state. That's the most severe security compromise you can imagine, the attacker has full access to the system.<br><br>You've totally lost now, because the attacker can compute all future outputs from this point on.<br><br>But over time, with more and more fresh entropy being mixed into it, the internal state gets more and more random again. So that such a random number generator's design is kind of self-healing.<br><br>But this is injecting entropy into the generator's internal state, it has nothing to do with blocking its output.</span> </div> <div style="display: flex; flex-direction: column; margin-top: 30px; padding-top: 30px; border-top: 1px solid #f1f1f1;"> <span style="font-family: Open Sans; font-size: 20px; font-weight: 700;">The random and urandom man page</span> <span style="margin-top: 30px; padding: 5px 10px; font-family: Open Sans; font-size: 14px; background-color: #000000; color: #ffffff;">there has actually been an updated version of the Linux kernel man page for /dev/random and /dev/urandom. unfortunately, a simple web search still turns up the old, deficient version im describing here in the top results. Furthermore, many Linux distributions still ship the old man pages. so unfortunately this section needs to stay a bit longer in the essay. im so looking forward to deleting it!</span> <span style="margin-top: 20px; font-family: Open Sans; font-size: 16px;">The man page for /dev/random and /dev/urandom is pretty effective when it comes to instilling fear into the gullible programmer's mind:</span> <span style="margin-top: 20px; font-family: Open Sans; font-size: 16px; color: #999999; padding-left: 20px; border-left: 10px solid #999999;">A read from the /dev/urandom device will not block waiting for more entropy. As a result, if there is not sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver. Knowledge of how to do this is not available in the current unclassified literature, but it is theoretically possible that such an attack may exist. If this is a concern in your application, use /dev/random instead.</span> <span style="margin-top: 20px; font-family: Open Sans; font-size: 16px;">Such an attack is not known in “unclassified literature”, but the NSA certainly has one in store, right? And if you're really concerned about this (you should!), please use /dev/random, and all your problems are solved.<br><br>The truth is, while there may be such an attack available to secret services, evil hackers or the Bogeyman, it's just not rational to just take it as a given.<br><br>And even if you need that peace of mind, let me tell you a secret: no practical attacks on AES, SHA-3 or other solid ciphers and hashes are known in the “unclassified” literature, either. Are you going to stop using those, as well? Of course not!<br><br>Now the fun part: “use /dev/random instead”. While /dev/urandom does not block, its random number output comes from the very same CSPRNG as /dev/random's.<br><br>If you really need information-theoretically secure random numbers (you don't!), and that's about the only reason why the entropy of the CSPRNG's input matters, you can't use /dev/random, either!<br><br>The man page is silly, that's all. At least it tries to redeem itself with this:</span> <span style="margin-top: 20px; font-family: Open Sans; font-size: 16px; color: #999999; padding-left: 20px; border-left: 10px solid #999999;">If you are unsure about whether you should use /dev/random or /dev/urandom, then probably you want to use the latter. As a general rule, /dev/urandom should be used for everything except long-lived GPG/SSL/SSH keys.</span> <span style="margin-top: 30px; padding: 5px 10px; font-family: Open Sans; font-size: 14px; background-color: #000000; color: #ffffff;">the <a href="http://man7.org/%E2%80%8Blinux/%E2%80%8Bman-pages/%E2%80%8Bman4/%E2%80%8Brandom.4.html">current, updated version</a> of the man page says in no uncertain terms: the /dev/random interface is considered a legacy interface, and /dev/urandom is preferred and sufficient in all use cases, with the exception of applications which require randomness during early boot time; for these applications, getrandom(2) must be used instead, because it will block until the entropy pool is initialized.</span> <span style="margin-top: 20px; font-family: Open Sans; font-size: 16px;">Fine. I think it's unnecessary, but if you want to use /dev/random for your “long-lived keys”, by all means, do so! You'll be waiting a few seconds typing stuff on your keyboard, that's no problem.<br><br>But please don't make connections to a mail server hang forever, just because you “wanted to be safe”.</span> </div> <div style="display: flex; flex-direction: column; margin-top: 30px; padding-top: 30px; border-top: 1px solid #f1f1f1;"> <span style="font-family: Open Sans; font-size: 16px;">The view espoused here is certainly a tiny minority's opinions on the Internet. But ask a real cryptographer, you'll be hard pressed to find someone who sympathizes much with that blocking /dev/random.<br><br>Let's take <a href="http://www.mail-archive.com/cryptography@randombit.net/msg04763.html">Daniel Bernstein</a>, better known as djb:</span> <span style="margin-top: 20px; font-family: Open Sans; font-size: 16px; color: #999999; padding-left: 20px; border-left: 10px solid #999999;">Cryptographers are certainly not responsible for this superstitious nonsense. Think about this for a moment: whoever wrote the /dev/random manual page seems to simultaneously believe that<br><br>(1) we can't figure out how to deterministically expand one 256-bit /dev/random output into an endless stream of unpredictable keys (this is what we need from urandom), but<br><br>(2) we _can_ figure out how to use a single key to safely encrypt many messages (this is what we need from SSL, PGP, etc.).<br><br>For a cryptographer this doesn't even pass the laugh test.</span> <span style="margin-top: 20px; font-family: Open Sans; font-size: 16px;">The view espoused here is certainly a tiny minority's opinions on the Internet. But ask a real cryptographer, you'll be hard pressed to find someone who sympathizes much with that blocking /dev/random.<br><br>Or <a href="http://security.stackexchange.com/questions/3936/is-a-rand-from-dev-urandom-secure-for-a-login-key/3939#3939">Thomas Pornin</a>, who is probably one of the most helpful persons I've ever encountered on the Stackexchange sites:</span> <span style="margin-top: 20px; font-family: Open Sans; font-size: 16px; color: #999999; padding-left: 20px; border-left: 10px solid #999999;">The short answer is yes. The long answer is also yes. /dev/urandom yields data which is indistinguishable from true randomness, given existing technology. Getting “better” randomness than what /dev/urandom provides is meaningless, unless you are using one of the few "information theoretic" cryptographic algorithm, which is not your case (you would know it).<br><br>The man page for urandom is somewhat misleading, arguably downright wrong, when it suggests that /dev/urandom may "run out of entropy" and /dev/random should be preferred;</span> <span style="margin-top: 20px; font-family: Open Sans; font-size: 16px;">The view espoused here is certainly a tiny minority's opinions on the Internet. But ask a real cryptographer, you'll be hard pressed to find someone who sympathizes much with that blocking /dev/random.<br><br>Or maybe <a href="http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/">Thomas Ptacek</a>, who is not a real cryptographer in the sense of designing cryptographic algorithms or building cryptographic systems, but still the founder of a well-reputed security consultancy that's doing a lot of penetration testing and breaking bad cryptography:</span> <span style="margin-top: 20px; font-family: Open Sans; font-size: 16px; color: #999999; padding-left: 20px; border-left: 10px solid #999999;">Use urandom. Use urandom. Use urandom. Use urandom. Use urandom. Use urandom.</span> </div> <div style="display: flex; flex-direction: column; margin-top: 30px; padding-top: 30px; border-top: 1px solid #f1f1f1;"> <span style="font-family: Open Sans; font-size: 16px;">/dev/urandom isn't perfect. The problems are twofold:<br><br>On Linux, unlike FreeBSD, /dev/urandom never blocks. Remember that the whole security rested on some starting randomness, a seed?<br><br>Linux's /dev/urandom happily gives you not-so-random numbers before the kernel even had the chance to gather entropy. When is that? At system start, booting the computer.<br><br>FreeBSD does the right thing: they don't have the distinction between /dev/random and /dev/urandom, both are the same device. At startup /dev/random blocks once until enough starting entropy has been gathered. Then it won't block ever again.<br><br>On Linux it isn't too bad, because Linux distributions save some random numbers when booting up the system (but after they have gathered some entropy, since the startup script doesn't run immediately after switching on the machine) into a seed file that is read next time the machine is booting. So you carry over the randomness from the last running of the machine.<br><br>Obviously that isn't as good as if you let the shutdown scripts write out the seed, because in that case there would have been much more time to gather entropy. The advantage is obviously that this does not depend on a proper shutdown with execution of the shutdown scripts (in case the computer crashes, for example).<br><br>And it doesn't help you the very first time a machine is running, but the Linux distributions usually do the same saving into a seed file when running the installer. So that's mostly okay.<br><br>Virtual machines are the other problem. Because people like to clone them, or rewind them to a previously saved check point, this seed file doesn't help you.<br><br>But the solution still isn't using /dev/random everywhere, but properly seeding each and every virtual machine after cloning, restoring a checkpoint, whatever.</span> <span style="margin-top: 30px; padding: 5px 10px; font-family: Open Sans; font-size: 14px; background-color: #000000; color: #ffffff;">in the meantime, Linux has implemented a new syscall, originally introduced by OpenBSD as getentropy(2): getrandom(2). this syscall does the right thing: blocking until it has gathered enough initial entropy, and never blocking after that point. Of course, it's a syscall, not a character device, so it isn't as easily accessible from shell or script languages. it's available from Linux 3.17 onward.</span> </div> <div style="display: flex; flex-direction: column; margin-top: 30px; padding-top: 30px; border-top: 1px solid #f1f1f1;"> <span style="font-family: Open Sans; font-size: 20px; font-weight: 700;">tldr; just use /dev/urandom</span> </div> </div> </body>
Optional Paste Settings
Category:
None
Cryptocurrency
Cybersecurity
Fixit
Food
Gaming
Haiku
Help
History
Housing
Jokes
Legal
Money
Movies
Music
Pets
Photo
Science
Software
Source Code
Spirit
Sports
Travel
TV
Writing
Tags:
Syntax Highlighting:
None
Bash
C
C#
C++
CSS
HTML
JSON
Java
JavaScript
Lua
Markdown (PRO members only)
Objective C
PHP
Perl
Python
Ruby
Swift
4CS
6502 ACME Cross Assembler
6502 Kick Assembler
6502 TASM/64TASS
ABAP
AIMMS
ALGOL 68
APT Sources
ARM
ASM (NASM)
ASP
ActionScript
ActionScript 3
Ada
Apache Log
AppleScript
Arduino
Asymptote
AutoIt
Autohotkey
Avisynth
Awk
BASCOM AVR
BNF
BOO
Bash
Basic4GL
Batch
BibTeX
Blitz Basic
Blitz3D
BlitzMax
BrainFuck
C
C (WinAPI)
C Intermediate Language
C for Macs
C#
C++
C++ (WinAPI)
C++ (with Qt extensions)
C: Loadrunner
CAD DCL
CAD Lisp
CFDG
CMake
COBOL
CSS
Ceylon
ChaiScript
Chapel
Clojure
Clone C
Clone C++
CoffeeScript
ColdFusion
Cuesheet
D
DCL
DCPU-16
DCS
DIV
DOT
Dart
Delphi
Delphi Prism (Oxygene)
Diff
E
ECMAScript
EPC
Easytrieve
Eiffel
Email
Erlang
Euphoria
F#
FO Language
Falcon
Filemaker
Formula One
Fortran
FreeBasic
FreeSWITCH
GAMBAS
GDB
GDScript
Game Maker
Genero
Genie
GetText
Go
Godot GLSL
Groovy
GwBasic
HQ9 Plus
HTML
HTML 5
Haskell
Haxe
HicEst
IDL
INI file
INTERCAL
IO
ISPF Panel Definition
Icon
Inno Script
J
JCL
JSON
Java
Java 5
JavaScript
Julia
KSP (Kontakt Script)
KiXtart
Kotlin
LDIF
LLVM
LOL Code
LScript
Latex
Liberty BASIC
Linden Scripting
Lisp
Loco Basic
Logtalk
Lotus Formulas
Lotus Script
Lua
M68000 Assembler
MIX Assembler
MK-61/52
MPASM
MXML
MagikSF
Make
MapBasic
Markdown (PRO members only)
MatLab
Mercury
MetaPost
Modula 2
Modula 3
Motorola 68000 HiSoft Dev
MySQL
Nagios
NetRexx
Nginx
Nim
NullSoft Installer
OCaml
OCaml Brief
Oberon 2
Objeck Programming Langua
Objective C
Octave
Open Object Rexx
OpenBSD PACKET FILTER
OpenGL Shading
Openoffice BASIC
Oracle 11
Oracle 8
Oz
PARI/GP
PCRE
PHP
PHP Brief
PL/I
PL/SQL
POV-Ray
ParaSail
Pascal
Pawn
Per
Perl
Perl 6
Phix
Pic 16
Pike
Pixel Bender
PostScript
PostgreSQL
PowerBuilder
PowerShell
ProFTPd
Progress
Prolog
Properties
ProvideX
Puppet
PureBasic
PyCon
Python
Python for S60
QBasic
QML
R
RBScript
REBOL
REG
RPM Spec
Racket
Rails
Rexx
Robots
Roff Manpage
Ruby
Ruby Gnuplot
Rust
SAS
SCL
SPARK
SPARQL
SQF
SQL
SSH Config
Scala
Scheme
Scilab
SdlBasic
Smalltalk
Smarty
StandardML
StoneScript
SuperCollider
Swift
SystemVerilog
T-SQL
TCL
TeXgraph
Tera Term
TypeScript
TypoScript
UPC
Unicon
UnrealScript
Urbi
VB.NET
VBScript
VHDL
VIM
Vala
Vedit
VeriLog
Visual Pro Log
VisualBasic
VisualFoxPro
WHOIS
WhiteSpace
Winbatch
XBasic
XML
XPP
Xojo
Xorg Config
YAML
YARA
Z80 Assembler
ZXBasic
autoconf
jQuery
mIRC
newLISP
q/kdb+
thinBasic
Paste Expiration:
Never
Burn after read
10 Minutes
1 Hour
1 Day
1 Week
2 Weeks
1 Month
6 Months
1 Year
Paste Exposure:
Public
Unlisted
Private
Folder:
(members only)
Password
NEW
Enabled
Disabled
Burn after read
NEW
Paste Name / Title:
Create New Paste
Hello
Guest
Sign Up
or
Login
Sign in with Facebook
Sign in with Twitter
Sign in with Google
You are currently not logged in, this means you can not edit or delete anything you paste.
Sign Up
or
Login
Public Pastes
Crypto admin access
1 min ago | 0.43 KB
+12,000$ in 2 days
CSS | 3 min ago | 0.71 KB
Free Crypto Method
CSS | 4 min ago | 0.70 KB
Documents
5 min ago | 0.43 KB
Crypto admin access
1 hour ago | 0.43 KB
deforestation
9 hours ago | 14.70 KB
Untitled
13 hours ago | 0.32 KB
Untitled
13 hours ago | 0.14 KB
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the
Cookies Policy
.
OK, I Understand
Not a member of Pastebin yet?
Sign Up
, it unlocks many cool features!