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

[Simon Josefsson]

Andreas Metzler <ametzler at downhill.at.eu.org> writes:

> On 2008-01-31 Werner Koch <wk at gnupg.org> wrote:
>> On Wed, 30 Jan 2008 19:20, ametzler at downhill.at.eu.org said:
>
>>> Any obvious breakage? Exim does not use any threading. I have not
>>> included an gcry_check_version(NULL) since I thought gcry_control()
>>> would fail as reliably as gcry_check_version() would, if gcrypt was
>
>> Better insert a gcry_check_version because this is the safe way to
>> initialize gcrypt.  The initialization is also done with most other
>> gcry_control calls but that is a failsafe feature.  Explicitly
>> initialization is better (you don't need to check the return code, just
>> call it.)
>
> Hello,
>
> we still seem have not been able to find a really working solution,
> this patch <http://svn.debian.org/wsvn/pkg-exim4/exim/trunk/debian/patches/65_saverandomseed.dpatch?op=file&rev=0&sc=0>
> causes crashes in exim.
>
> Quoting Marc Haber in http://bugs.exim.org/show_bug.cgi?id=654
> | However, the secondary MX (which delivers some spam to the primary MX) noted
> | that the primary box had become unreliable in TLS:
> | 2008-01-30 14:51:21 1JKDKT-0003ME-AG Remote host mailgate.zugschlus.de
> | [85.214.68.41] closed connection in response to STARTTLS
> | 
> | When this happened (a couple of times per hour), I didn't get any
> | atypical log entries on mailgate.
> | 
> | This was a repeating, but intermittent failure since mailgate
> | continued to work normally, and STARTTLS was successful most of the
> | time.
> [...]
> | Going back to the same exim sans the random-seed patch, entropy
> | average went back to 200, but the STARTTLS failures vanished.
>
> We have tried to isolate what actually breaks, by only applying parts
> of the patch (e.g setting up dthe seed file, but not updating it.),
> but it looks like the mere presence of
> gcry_control (GCRYCTL_SET_RANDOM_SEED_FILE,filename)
> causes the crashes.

Did you follow Werner's suggestion to the patch?  I.e., to call
gcry_check_version to initialize libgcrypt properly.

> I am really wondering whether using the experimental daemon might be
> worthwile, there does not seem to be much cost involved, and
> /dev/(u)random has not got any policy controls either.

I think doing whatever it takes to make libgcrypt return useful amounts
of entropy would be a good thing.  Forcing every application to set a
seed file is quite costly maintenance and documentation wise, so running
one libgcrypt-specific daemon may be simpler.

/Simon