Bug#448775: Uses too much entropy (Debian Bug #343085)
simon at josefsson.org
Fri Jan 4 13:41:38 CET 2008
Florian Weimer <fweimer at bfk.de> writes:
> * Werner Koch:
>> Exim should properly intialize libgcrypt and create a random seed file.
> Is this documented somewhere? I'm a bit reluctant to add this kind of
> layering violation.
We could consider doing something like that in gnutls too, to help
applications avoid having to do it themselves. However, the
documentation on UPDATE_SEED seems somewhat discouraging. I'm not sure
if gnutls is in a position to save a seeds file properly. It seems to
better belong either inside libgcrypt or inside the application.
`GCRYCTL_SET_RANDOM_SEED_FILE; Arguments: const char *filename'
This command specifies the file, which is to be used as seed
file for the PRNG. If the seed file is registered prior to
initialization of the PRNG, the seed file's content (if it
exists and seems to be valid) is fed into the PRNG pool.
After the seed file has been registered, the PRNG can be
signalled to write out the PRNG pool's content into the seed
file with the following command.
`GCRYCTL_UPDATE_RANDOM_SEED_FILE; Arguments: none'
Write out the PRNG pool's content into the registered seed
Multiple instances of the applications sharing the same
random seed file can be started in parallel, in which case
they will read out the same pool and then race for updating
it (the last update overwrites earlier updates). They will
differentiate only by the weak entropy that is added in
read_seed_file based on the PID and clock, and up to 16 bytes
of weak random non-blockingly. The consequence is that the
output of these different instances is correlated to some
extent. In the perfect scenario, the attacker can control
(or at least guess) the PID and clock of the application, and
drain the system's entropy pool to reduce the "up to 16
bytes" above to 0. Then the dependencies of the inital states
of the pools are completely known. Note that this is not an
issue if random of `GCRY_VERY_STRONG_RANDOM' quality is
requested as in this case enough extra entropy gets mixed.
When building/developing GnuTLS with non-libgcrypt providers, a seed
file would definitely help -- Nettle's PRNG maintains one. So building
good APIs for this now may help with non-libgcrypt providers in the
Anyway, the recommended approach should be documented in the gnutls
More information about the Gcrypt-devel