Yes, so the question is what is the preferred failure behaviour when there isn&#x27;t even enough entropy in the system to be confident that you can select a single unpredictable key with any kind of confidence of uniqueness within an unbounded time window. That should mean that the system effectively has <i>no</i> source of entropy.<p>I think blocking and not returning until you have entropy is a reasonable failure behaviour for gpg in the key generation process.<p>It&#x27;d be nice to report something and maybe hint to the user that you are waiting for just a modicum of entropy to show up, but at least it isn&#x27;t presenting a key that is entirely predictable (and worse still, the <i>SAME</i> as any other instance of that VM image!!!) to anyone with access to the original VM.<p>The bug the article is referring to is that a lot of security systems will block reading &#x2F;dev&#x2F;random when in fact &#x2F;dev&#x2F;urandom will provide a securely unpredictable sequence of data with no statistically likelihood of another system producing the same sequence. It&#x27;s particularly bad for the case where timeliness is an important part of the protocol (which is largely a given for anything around say... a TCP connection). That&#x27;s a silly design flaw.