[gnutls-dev] Speed of random data generation
home at alexhudson.com
Thu Jun 14 19:19:00 CEST 2007
Thank you very much for your helpful response.
On Thu, 2007-06-14 at 18:50 +0200, Werner Koch wrote:
> For an embedded platform it might make sense to build libgcrypt with the
> names of the random devices both set to /dev/urandom. It depends on
> your application.
I think our main problem is that many servers will behave a bit like
embedded devices in terms of lack of randomness: some of them rarely do
disk i/o, which seems to be their only source of real entropy. However,
in our situation, we want our software to work on standard GNU/Linux
distributions, so we can't really ship our own libgcrypt without
creating worse problems.
> Libgcrypt has a feature which might be helpful:
> gcry_control (GCRYCTL_ENABLE_QUICK_RANDOM, 0);
> This is used early at program startup to degrade the require random for
> key generation down to the standard level. We use this only for the
> regression tests but it is an official feature.
I hadn't seen this before, thanks. However, in the manual it does say:
"This command activates the use of a highly-insecure, but fast
PRNG. It can only be used at initialization time. The only
useful applications for this are certain regression tests."
If we used GNUTLS with this turned on, would GNUTLS be working in much
the same way as OpenSSL does (wrt. cert generation, etc.), or would it
be a worse position?
It sounds like this is an option we could offer our users, but I'd like
to make clear the actual risk this poses. From my point of view, the
risk is that the PRNG is predictable and therefore the certs. created
could be guessed. To me, that doesn't sound like a big risk (it would
probably be easier to steal the mail server), but the manual statement
is very strong ("highly-insecure"). Is the manual being very paranoid,
or is there a real risk here?
More information about the Gnutls-devel