&#x2F;dev&#x2F;urandom will generate secure random data. That&#x27;s what it does.<p>That was the point of the blog post: if you are using &#x2F;dev&#x2F;random as input in to a cryptographic protocol that will stretch that randomness over to many more bytes, WTF do you think &#x2F;dev&#x2F;urandom is already doing?<p>What &#x2F;dev&#x2F;urandom might fail to do, and this primarily applies to your specific case of a VM just as it is first launching and setting things up, is generate unpredictable data, and most terribly, it might generate duplicate data, for certain specific use cases where that would just be awful.<p>I would agree that you got the gist right though: &#x2F;dev&#x2F;urandom is usually the right choice, but when it is not, &#x2F;dev&#x2F;random is indeed needed. Most people misunderstand the dichotomy as &quot;random&quot; and &quot;guaranteed random&quot;, which leads to very, very unfortunate outcomes. Other people misunderstand what they are doing cryptographically and somehow think that some cryptographic algorithm that uses a small key to encrypt vast amounts of data shouldn&#x27;t have any concerns about insecure, non-random cyclic behaviour, but oddly take a jaundiced eye to &#x2F;dev&#x2F;urandom. It basically amounts to &quot;I think you can securely generate a random data stream from a small source of entropy... as long as that belief isn&#x27;t embodied in something called urandom&quot;.<p>Again, if you don&#x27;t know the right choice, you should pass the baton to someone who does, because even if you make the right choice, odds favour you doing something terrible that compromises security.