Things have improved a little on this front. It turn out gnupg was being a little gluttonous when it came to entropy:<p>&quot;Daniel Kahn Gillmor observed that GnuPG reads 300 bytes from &#x2F;dev&#x2F;random when it generates a long-term key, which, he observed, is a lot given &#x2F;dev&#x2F;random&#x27;s limited entropy . Werner explained that GnuPG has always done this. In particular, GnuPG maintains a 600-byte persistent seed file and every time a key is generated it stirs in an additional 300 bytes. Daniel pointed out an interesting blog post by DJB explaining that a proper CSPRNG should never need more than about 32 bytes of entropy. Peter Gutmann chimed in and noted that a 2048-bit RSA key needs about about 103 bits of entropy and a 4096-bit RSA key needs about 142 bits, but, in practice, 128-bits is enough. Based on this, Werner proposed a patch for Libgcrypt that reduces the amount of seeding to just 128-bits.&quot;[^1]<p>On a related not why are you generating keys on a remote vm?  Its probably not fair to say that gpg &quot;failed to work (literally would not do anything).&quot; It was doing something, gnupg was waiting for more entropy. Needing immediate access to cryptographic keys that you just generated on a recently spun up remote VM is kind of a strange use case?<p>[^1]: <a href="https:&#x2F;&#x2F;www.gnupg.org&#x2F;blog&#x2F;20150607-gnupg-in-may.html" rel="nofollow">https:&#x2F;&#x2F;www.gnupg.org&#x2F;blog&#x2F;20150607-gnupg-in-may.html</a>