I noticed the other day that generating keys with GPG on a server takes forever which suggests bad entropy? This server is combining RSA and AES encryption with quite large RSA keys (generated elsewhere).
The AES key I RSA encrypt (and that is used to encrypt the actual message) are generated with calls to Crypto.Random.new().read(). If the entropy is bad on this server isn't there a risk for compromised encryption? Or is a 32 byte AES and a large RSA key "good enough"? (whatever that means)
I'm using the Crypto python module but can switch to cryptography or GnuPG if that effort improves security. Changing server is also an option.
Is SSL affected by bad entropy?
os.urandom() vs Crypto.Random?
It's unlikely that your server has "bad entropy" or insufficient amounts of entropy; especially if your machine is running any other tasks, or has any human input (such as keypresses or mouse movement), even the 'blocking' entropy should be more than sufficient, unless you're asking for extraordinary amounts of random bits.
I'd check a few other common bottlenecks, including the ping-time to the server, if you have C bindings installed and configured for your python libraries, etc. (In particular, pure python implementations of crypto are notoriously slow.)
Handling bad entropy in encryption