> > A workaround might be to use the libgcrypt's random number process > > feature which uses a single server process to feed other processes > > with entropy (I've never worked with it so I don't know if it can be > > used in that case). This might solve this issue. > > Disagree. > > * /dev/(u)random is more difficult to subvert than a daemon. > > * The kernel has access to more sources of randomness.
I don't understand these comments. The libgcrypt's generator can be used in a separate processes. It doesn't mean it gathers any entropy except for using /dev/urandom as usual. regards, Nikos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
