Bug#448775: Uses too much entropy (Debian Bug #343085)

[Simon Josefsson]

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
          file.

          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
future too.

Anyway, the recommended approach should be documented in the gnutls
manual eventually.

/Simon