You may want to check what the kernel's using as a source of randomness.
I forget the details, but IIRC /dev/urandom never blocks, whereas /dev/random may block under {some condition I can't recall in detail}.
Well, the server in question is a vServer, a virtual server which shares the physical hardware with other virtual servers. The machine is hosted on provider's land and I have no physical access to it. All I can do is a ssh to my vServer instance. So, whatever it uses as a source of randomness, I have no way of discovering or changing it.
And you are right, /dev/random will block if you try to read more random bytes than it currently has in the pool, it will wait for more random data to become available. /dev/urandom won't block if you ask for more than it has, it will give you what it has and perhaps inform you somehow that it wasn't as much as you requested.
My linking /dev/random to /dev/urandom may well affect the quality of the encrypted connection, depends on how the underlying TLS library handles the random sources. In this case it thinks that it reads from /dev/random, so I guess that my solution can result in poor encryption keys. It isn't advisable for high security environments to follow my solution, but rather to check their random sources, as you suggested. In my case, I am one man and that server is my private hobby, a bad key with less random background than it should have is still more than good enough.
Ciao, Igor
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
