From nmav at gnutls.org  Fri Jan  4 10:59:58 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 4 Jan 2008 11:59:58 +0200
Subject: Bug#448775: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <20080104094848.GB4528@downhill.g.la>
References: <20080103003214.GB14155@torres.zugschlus.de>
	<c331d99a0801032356i4e8be690h56be9db32318bdfc@mail.gmail.com>
	<20080104094848.GB4528@downhill.g.la>
Message-ID: <c331d99a0801040159q7be28a15ndf1883ba8d4a2f02@mail.gmail.com>

On Jan 4, 2008 11:48 AM, Andreas Metzler <ametzler at downhill.at.eu.org> wrote:

> >> have to disagree with this being a kernel bug. man 4 random on
> >> Linux documents how /dev/urandom behaves, and is supposed to
> >> behave.  "Some bytes" looks more like "a few hundred bytes", and
> >> Exim does not exhaust /dev/urandom as badly when OpenSSL is used.
>
> Hello,
> The amount of data read from /dev/urandom in Gnutls/Gcrypt is on a
> different scale than in openssl:
>
[...]

> So with a forking daemon (therefore initialising the RNG for every in-
> and outgoing connection) GnuTLS will deplete entropy_avail to its
> bare minimum vor every single connection, while openssl only takes
> about 7%.
> What is the actual cause of this difference in resource usage?

This is mostly a question for libgcrypt developers, but I believe
libgcrypt initializes the PRNG in a more conservative way.

regards,
Nikos


From wk at gnupg.org  Fri Jan  4 12:25:54 2008
From: wk at gnupg.org (Werner Koch)
Date: Fri, 04 Jan 2008 12:25:54 +0100
Subject: Bug#448775: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <c331d99a0801040159q7be28a15ndf1883ba8d4a2f02@mail.gmail.com>
	(Nikos Mavrogiannopoulos's message of "Fri, 4 Jan 2008 11:59:58
	+0200")
References: <20080103003214.GB14155@torres.zugschlus.de>
	<c331d99a0801032356i4e8be690h56be9db32318bdfc@mail.gmail.com>
	<20080104094848.GB4528@downhill.g.la>
	<c331d99a0801040159q7be28a15ndf1883ba8d4a2f02@mail.gmail.com>
Message-ID: <87tzlt6ddp.fsf@wheatstone.g10code.de>

On Fri,  4 Jan 2008 10:59, nmav at gnutls.org said:

> This is mostly a question for libgcrypt developers, but I believe
> libgcrypt initializes the PRNG in a more conservative way.

Right, we even implement failsafe methods in case /dev/random does not
work like expected.  In fact we don't know ehther /dev/random is a good
RNG or not.  There is no serious study on the quality of /dev/random and
in the past we have seen major over-estimations on the available
entropy.

The problem with exim is that it does not use a random seed file which
greatly helps libgcrypt to initializes its internal pool.  I recall that
we discussed this quite some time ago.  I just looked at the current Sid
source of Exim and I can't find any call to libgcrypt.  IIRC, gnutls
does not cope with global libcgrypt setting and thus there is no saving
of a seend file.  

Exim should properly intialize libgcrypt and create a random seed file.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.



From simon at josefsson.org  Fri Jan  4 13:20:17 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 04 Jan 2008 13:20:17 +0100
Subject: Bug#448775: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <87tzlt6ddp.fsf@wheatstone.g10code.de> (Werner Koch's message of
	"Fri, 04 Jan 2008 12:25:54 +0100")
References: <20080103003214.GB14155@torres.zugschlus.de>
	<c331d99a0801032356i4e8be690h56be9db32318bdfc@mail.gmail.com>
	<20080104094848.GB4528@downhill.g.la>
	<c331d99a0801040159q7be28a15ndf1883ba8d4a2f02@mail.gmail.com>
	<87tzlt6ddp.fsf@wheatstone.g10code.de>
Message-ID: <87odc1bx4u.fsf@mocca.josefsson.org>

Werner Koch <wk at gnupg.org> writes:

> On Fri,  4 Jan 2008 10:59, nmav at gnutls.org said:
>
>> This is mostly a question for libgcrypt developers, but I believe
>> libgcrypt initializes the PRNG in a more conservative way.
>
> Right, we even implement failsafe methods in case /dev/random does not
> work like expected.  In fact we don't know ehther /dev/random is a good
> RNG or not.  There is no serious study on the quality of /dev/random and
> in the past we have seen major over-estimations on the available
> entropy.

Right, and there are studies that suggests the Linux /dev/random device
have flaws:

http://eprint.iacr.org/2006/086

Being conservative here is a good thing.  However, that does not have to
be in conflict with working efficiently.  Using a random seed file would
be one way to address both concerns.

/Simon


From simon at josefsson.org  Fri Jan  4 13:35:26 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 04 Jan 2008 13:35:26 +0100
Subject: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <20080104122116.GK22955@kiste.smurf.noris.de> (Matthias Urlichs's
	message of "Fri, 4 Jan 2008 13:21:16 +0100")
References: <20080103003214.GB14155@torres.zugschlus.de>
	<c331d99a0801032356i4e8be690h56be9db32318bdfc@mail.gmail.com>
	<20080104113847.GJ22955@kiste.smurf.noris.de>
	<c331d99a0801040355v2785cd0ei87e02beb7395717e@mail.gmail.com>
	<20080104122116.GK22955@kiste.smurf.noris.de>
Message-ID: <87k5mpbwfl.fsf@mocca.josefsson.org>

Matthias Urlichs <smurf at smurf.noris.de> writes:

> Hi,
>
> Nikos Mavrogiannopoulos:
>> 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.
>> 
> Ah, thanks for the correction.
>
> In that case, if it's "as usual", why run the daemon in the first place?

I think the daemon is there to help libgcrypt maintain randomness state
between invocations of applications that use randomness from libgcrypt.
Libgcrypt talks with it.  But I haven't used the feature either (it is
experimental) so I don't know for sure.  Cc'ing libgcrypt-devel for
corrections.

> To clarify: I don't have an issue with gnutls eating randomness from the
> pool. The randomness is there to be eaten.
>
> However, reading 3000+ bits every time a server (or client) starts up
> does seem a bit excessive. I seriously doubt that it needs that many.

The 3000+ bits part doesn't seem excessive to me, but I think the
problem is that it is required each time a server or client starts up.
Saving a random seeds file would help with this.  Or using the libgcrypt
daemon, if it works as I think it does.

/Simon


From simon at josefsson.org  Fri Jan  4 13:41:38 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 04 Jan 2008 13:41:38 +0100
Subject: Bug#448775: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <82wsqpg492.fsf@mid.bfk.de> (Florian Weimer's message of "Fri, 04
	Jan 2008 13:32:57 +0100")
References: <20080103003214.GB14155@torres.zugschlus.de>
	<c331d99a0801032356i4e8be690h56be9db32318bdfc@mail.gmail.com>
	<20080104094848.GB4528@downhill.g.la>
	<c331d99a0801040159q7be28a15ndf1883ba8d4a2f02@mail.gmail.com>
	<87tzlt6ddp.fsf@wheatstone.g10code.de> <82wsqpg492.fsf@mid.bfk.de>
Message-ID: <87fxxdbw59.fsf@mocca.josefsson.org>

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


From fweimer at bfk.de  Fri Jan  4 13:32:57 2008
From: fweimer at bfk.de (Florian Weimer)
Date: Fri, 04 Jan 2008 13:32:57 +0100
Subject: Bug#448775: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <87tzlt6ddp.fsf@wheatstone.g10code.de> (Werner Koch's message of
	"Fri, 04 Jan 2008 12:25:54 +0100")
References: <20080103003214.GB14155@torres.zugschlus.de>
	<c331d99a0801032356i4e8be690h56be9db32318bdfc@mail.gmail.com>
	<20080104094848.GB4528@downhill.g.la>
	<c331d99a0801040159q7be28a15ndf1883ba8d4a2f02@mail.gmail.com>
	<87tzlt6ddp.fsf@wheatstone.g10code.de>
Message-ID: <82wsqpg492.fsf@mid.bfk.de>

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

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra?e 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99


From wk at gnupg.org  Fri Jan  4 14:14:50 2008
From: wk at gnupg.org (Werner Koch)
Date: Fri, 04 Jan 2008 14:14:50 +0100
Subject: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <87k5mpbwfl.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Fri, 04 Jan 2008 13:35:26 +0100")
References: <20080103003214.GB14155@torres.zugschlus.de>
	<c331d99a0801032356i4e8be690h56be9db32318bdfc@mail.gmail.com>
	<20080104113847.GJ22955@kiste.smurf.noris.de>
	<c331d99a0801040355v2785cd0ei87e02beb7395717e@mail.gmail.com>
	<20080104122116.GK22955@kiste.smurf.noris.de>
	<87k5mpbwfl.fsf@mocca.josefsson.org>
Message-ID: <87ve694trp.fsf@wheatstone.g10code.de>

On Fri,  4 Jan 2008 13:35, simon at josefsson.org said:

> I think the daemon is there to help libgcrypt maintain randomness state
> between invocations of applications that use randomness from libgcrypt.

Right.  And it is still flagged as experimental because it lacks any
fair distribution of random to requesting clients.

> The 3000+ bits part doesn't seem excessive to me, but I think the
> problem is that it is required each time a server or client starts up.
> Saving a random seeds file would help with this.  Or using the libgcrypt

You need a seed file for good performace.  That's all.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.



From wk at gnupg.org  Fri Jan  4 14:45:00 2008
From: wk at gnupg.org (Werner Koch)
Date: Fri, 04 Jan 2008 14:45:00 +0100
Subject: Bug#448775: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <87fxxdbw59.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Fri, 04 Jan 2008 13:41:38 +0100")
References: <20080103003214.GB14155@torres.zugschlus.de>
	<c331d99a0801032356i4e8be690h56be9db32318bdfc@mail.gmail.com>
	<20080104094848.GB4528@downhill.g.la>
	<c331d99a0801040159q7be28a15ndf1883ba8d4a2f02@mail.gmail.com>
	<87tzlt6ddp.fsf@wheatstone.g10code.de> <82wsqpg492.fsf@mid.bfk.de>
	<87fxxdbw59.fsf@mocca.josefsson.org>
Message-ID: <87r6gx4sdf.fsf@wheatstone.g10code.de>

On Fri,  4 Jan 2008 13:41, simon at josefsson.org said:

> 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

Let's say this description is very conservative and mostly written for
security evaluations.  The "up to 16 bytes of weak random " is not even
correct for Linux because there we will always read 16 bytes from
/dev/urandom and thus the whole theoretical attack won't work.  I'll
revise the description a bit.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.



From simon at josefsson.org  Fri Jan  4 15:16:57 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 04 Jan 2008 15:16:57 +0100
Subject: Bug#448775: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <87r6gx4sdf.fsf@wheatstone.g10code.de> (Werner Koch's message of
	"Fri, 04 Jan 2008 14:45:00 +0100")
References: <20080103003214.GB14155@torres.zugschlus.de>
	<c331d99a0801032356i4e8be690h56be9db32318bdfc@mail.gmail.com>
	<20080104094848.GB4528@downhill.g.la>
	<c331d99a0801040159q7be28a15ndf1883ba8d4a2f02@mail.gmail.com>
	<87tzlt6ddp.fsf@wheatstone.g10code.de> <82wsqpg492.fsf@mid.bfk.de>
	<87fxxdbw59.fsf@mocca.josefsson.org>
	<87r6gx4sdf.fsf@wheatstone.g10code.de>
Message-ID: <87tzltr7za.fsf@mocca.josefsson.org>

Werner Koch <wk at gnupg.org> writes:

> On Fri,  4 Jan 2008 13:41, simon at josefsson.org said:
>
>> 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
>
> Let's say this description is very conservative and mostly written for
> security evaluations.  The "up to 16 bytes of weak random " is not even
> correct for Linux because there we will always read 16 bytes from
> /dev/urandom and thus the whole theoretical attack won't work.  I'll
> revise the description a bit.

Ok.  Still, my main question is whether GnuTLS could utilize these hooks
somehow.  I guess we could have two functions:

int
gnutls_set_random_seed_file (const char *filename);
int
gnutls_update_random_seed ();

The first function would have to be called before gnutls_global_init().
Then exim could invoke the function, to avoid having to call libgcrypt
directly.

However, when is it useful for an application to save the seed?  Is it
useful to do this often, or only when the process exits?

Isn't it more reliable to never save the seed file, but to have a cron
job to generate a new seed file that can be run every other week or so?

Maybe the gnutls_update_random_seed function isn't needed.

There is also the problem if something other than gnutls has already
initialized libgcrypt.  This could happen if exim links to some other
library that uses libgcrypt, for example, a LDAP or database library,
which gets initialized before.  I'm not sure what we can do about this
situation.  I also dislike global functions like this.

/Simon


From simon at josefsson.org  Fri Jan  4 15:39:20 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 04 Jan 2008 15:39:20 +0100
Subject: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <87ve694trp.fsf@wheatstone.g10code.de> (Werner Koch's message of
	"Fri, 04 Jan 2008 14:14:50 +0100")
References: <20080103003214.GB14155@torres.zugschlus.de>
	<c331d99a0801032356i4e8be690h56be9db32318bdfc@mail.gmail.com>
	<20080104113847.GJ22955@kiste.smurf.noris.de>
	<c331d99a0801040355v2785cd0ei87e02beb7395717e@mail.gmail.com>
	<20080104122116.GK22955@kiste.smurf.noris.de>
	<87k5mpbwfl.fsf@mocca.josefsson.org>
	<87ve694trp.fsf@wheatstone.g10code.de>
Message-ID: <87prwhr6xz.fsf@mocca.josefsson.org>

Werner Koch <wk at gnupg.org> writes:

> On Fri,  4 Jan 2008 13:35, simon at josefsson.org said:
>
>> I think the daemon is there to help libgcrypt maintain randomness state
>> between invocations of applications that use randomness from libgcrypt.
>
> Right.  And it is still flagged as experimental because it lacks any
> fair distribution of random to requesting clients.

You mean the problem where one client requests a lot of randomness,
which would hurt the randomness received by other clients?

Maybe we could simply punt on that problem.  The /dev/*random devices
have the same problem, doesn't it?

What practical problem would there be in documentation that states 'Make
sure you don't run clients that requests too much entropy from the
daemon'?

Another solution, how about to refuse to give out entropy to processes
not listed in a world-readable but root-writable file
/etc/libgcryptd.conf file?

/Simon


From wk at gnupg.org  Fri Jan  4 16:46:55 2008
From: wk at gnupg.org (Werner Koch)
Date: Fri, 04 Jan 2008 16:46:55 +0100
Subject: Bug#448775: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <87tzltr7za.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Fri, 04 Jan 2008 15:16:57 +0100")
References: <20080103003214.GB14155@torres.zugschlus.de>
	<c331d99a0801032356i4e8be690h56be9db32318bdfc@mail.gmail.com>
	<20080104094848.GB4528@downhill.g.la>
	<c331d99a0801040159q7be28a15ndf1883ba8d4a2f02@mail.gmail.com>
	<87tzlt6ddp.fsf@wheatstone.g10code.de> <82wsqpg492.fsf@mid.bfk.de>
	<87fxxdbw59.fsf@mocca.josefsson.org>
	<87r6gx4sdf.fsf@wheatstone.g10code.de>
	<87tzltr7za.fsf@mocca.josefsson.org>
Message-ID: <87k5mp385s.fsf@wheatstone.g10code.de>

On Fri,  4 Jan 2008 15:16, simon at josefsson.org said:

> int
> gnutls_set_random_seed_file (const char *filename);

I don't think that is a good idea.  gnutls does not provide the required
thread hook function for libgcrypt and thus the appliaction needs to do
this.  If you want these functions you should also add the threading
wrappers. 

Another problem is that if gnutls is used indirectly no seed file is
used and thus the appliaction needs to do it anyway.  The seed file
should be application specific and not library specific.  Thus I suggest
to document this and change the application.

> However, when is it useful for an application to save the seed?  Is it
> useful to do this often, or only when the process exits?

Only at exit.  In theory libgcrypt could do this automagically, but
installing atexit handlers in libaries should in general be avoided.

> Isn't it more reliable to never save the seed file, but to have a cron
> job to generate a new seed file that can be run every other week or so?

No, no.  This is specific to libgcrypt and only the libgcrypt process
may create it.  The format and size may change without notice.

> There is also the problem if something other than gnutls has already
> initialized libgcrypt.  This could happen if exim links to some other
> library that uses libgcrypt, for example, a LDAP or database library,
> which gets initialized before.  I'm not sure what we can do about this
> situation.  I also dislike global functions like this.

You can't do anything about it unless you turn gnutls into an RPC
server so that it has its own process.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.



From wk at gnupg.org  Fri Jan  4 16:50:45 2008
From: wk at gnupg.org (Werner Koch)
Date: Fri, 04 Jan 2008 16:50:45 +0100
Subject: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <87prwhr6xz.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Fri, 04 Jan 2008 15:39:20 +0100")
References: <20080103003214.GB14155@torres.zugschlus.de>
	<c331d99a0801032356i4e8be690h56be9db32318bdfc@mail.gmail.com>
	<20080104113847.GJ22955@kiste.smurf.noris.de>
	<c331d99a0801040355v2785cd0ei87e02beb7395717e@mail.gmail.com>
	<20080104122116.GK22955@kiste.smurf.noris.de>
	<87k5mpbwfl.fsf@mocca.josefsson.org>
	<87ve694trp.fsf@wheatstone.g10code.de>
	<87prwhr6xz.fsf@mocca.josefsson.org>
Message-ID: <87fxxd37ze.fsf@wheatstone.g10code.de>

On Fri,  4 Jan 2008 15:39, simon at josefsson.org said:

> You mean the problem where one client requests a lot of randomness,
> which would hurt the randomness received by other clients?

Right.  Though the IPC mechanims allows for several concurrent requests,
the hear of the RNG serializes everything.

> Maybe we could simply punt on that problem.  The /dev/*random devices
> have the same problem, doesn't it?

Yes /dev/random has the same property.

> Another solution, how about to refuse to give out entropy to processes
> not listed in a world-readable but root-writable file
> /etc/libgcryptd.conf file?

Well it is experimental and I had similar ideas.  If I remember right I
implemented the daemon thing when we first talked about the exim problem
or to help other short-living processes.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.



From simon at josefsson.org  Fri Jan  4 17:01:20 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 04 Jan 2008 17:01:20 +0100
Subject: Bug#448775: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <87k5mp385s.fsf@wheatstone.g10code.de> (Werner Koch's message of
	"Fri, 04 Jan 2008 16:46:55 +0100")
References: <20080103003214.GB14155@torres.zugschlus.de>
	<c331d99a0801032356i4e8be690h56be9db32318bdfc@mail.gmail.com>
	<20080104094848.GB4528@downhill.g.la>
	<c331d99a0801040159q7be28a15ndf1883ba8d4a2f02@mail.gmail.com>
	<87tzlt6ddp.fsf@wheatstone.g10code.de> <82wsqpg492.fsf@mid.bfk.de>
	<87fxxdbw59.fsf@mocca.josefsson.org>
	<87r6gx4sdf.fsf@wheatstone.g10code.de>
	<87tzltr7za.fsf@mocca.josefsson.org>
	<87k5mp385s.fsf@wheatstone.g10code.de>
Message-ID: <8763y9r35b.fsf@mocca.josefsson.org>

Werner Koch <wk at gnupg.org> writes:

> On Fri,  4 Jan 2008 15:16, simon at josefsson.org said:
>
>> int
>> gnutls_set_random_seed_file (const char *filename);
>
> I don't think that is a good idea.  gnutls does not provide the required
> thread hook function for libgcrypt and thus the appliaction needs to do
> this.  If you want these functions you should also add the threading
> wrappers.

Ok.

> Another problem is that if gnutls is used indirectly no seed file is
> used and thus the appliaction needs to do it anyway.  The seed file
> should be application specific and not library specific.

My idea would be that the filename in the API comes from the
application.

> Thus I suggest to document this and change the application.

Right.  So what should applications like exim do exactly?  Is there
anything more to think about than this:

#include <gcrypt.h>

int main ()
{
  gcry_error_t rc;

  rc = gcry_control (GCRYCTL_SET_RANDOM_SEED_FILE,
                     "/var/run/exim4/random.seed");
  if (rc)
    error (EXIT_FAILURE, 0, "gcry_control SET_RANDOM_SEED_FILE");

  DoIT();  /* initialize gnutls, runs the MTA.. */

  rc = gcry_control (GCRYCTL_UPDATE_RANDOM_SEED_FILE);
  if (rc)
    fprintf (stderr,
       "warning: gcry_control UPDATE_RANDOM_SEED_FILE failed (%d): %s",
       rc, gpg_strerror (rc));

  return 0;
}

/Simon


From simon at josefsson.org  Fri Jan  4 17:08:03 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 04 Jan 2008 17:08:03 +0100
Subject: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <87fxxd37ze.fsf@wheatstone.g10code.de> (Werner Koch's message of
	"Fri, 04 Jan 2008 16:50:45 +0100")
References: <20080103003214.GB14155@torres.zugschlus.de>
	<c331d99a0801032356i4e8be690h56be9db32318bdfc@mail.gmail.com>
	<20080104113847.GJ22955@kiste.smurf.noris.de>
	<c331d99a0801040355v2785cd0ei87e02beb7395717e@mail.gmail.com>
	<20080104122116.GK22955@kiste.smurf.noris.de>
	<87k5mpbwfl.fsf@mocca.josefsson.org>
	<87ve694trp.fsf@wheatstone.g10code.de>
	<87prwhr6xz.fsf@mocca.josefsson.org>
	<87fxxd37ze.fsf@wheatstone.g10code.de>
Message-ID: <871w8xr2u4.fsf@mocca.josefsson.org>

Werner Koch <wk at gnupg.org> writes:

>> Another solution, how about to refuse to give out entropy to processes
>> not listed in a world-readable but root-writable file
>> /etc/libgcryptd.conf file?
>
> Well it is experimental and I had similar ideas.  If I remember right I
> implemented the daemon thing when we first talked about the exim problem
> or to help other short-living processes.

So I guess the question is for the exim people: which approach do you
prefer?

  1) Require that the system run the libgcrypt daemon to maintain a
     global randomness pool.  (Or if the user uses a kernel that doesn't
     have PRNG saturation problems that Linux does... anyone knows if
     FreeBSD or GNU/Hurd have similar issues?)

  2) To make exim link to and call libgcrypt's functions to read and
     update a random seed file instead?

  3) continue discussing other solutions...

For simplicity and non-experimentalness, I would recommend 2).  I can
assist in implementing this in exim, if that would help.  We'd
definitely need a good example of how to do this in the gnutls manual
anyway.

/Simon


From simon at josefsson.org  Fri Jan  4 18:24:46 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 04 Jan 2008 18:24:46 +0100
Subject: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <20080104170649.GA4550@downhill.g.la> (Andreas Metzler's message
	of "Fri, 4 Jan 2008 18:06:49 +0100")
References: <20080103003214.GB14155@torres.zugschlus.de>
	<c331d99a0801032356i4e8be690h56be9db32318bdfc@mail.gmail.com>
	<20080104113847.GJ22955@kiste.smurf.noris.de>
	<c331d99a0801040355v2785cd0ei87e02beb7395717e@mail.gmail.com>
	<20080104122116.GK22955@kiste.smurf.noris.de>
	<87k5mpbwfl.fsf@mocca.josefsson.org>
	<87ve694trp.fsf@wheatstone.g10code.de>
	<87prwhr6xz.fsf@mocca.josefsson.org>
	<87fxxd37ze.fsf@wheatstone.g10code.de>
	<871w8xr2u4.fsf@mocca.josefsson.org>
	<20080104170649.GA4550@downhill.g.la>
Message-ID: <87ejcxpkpt.fsf@mocca.josefsson.org>

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

> On 2008-01-04 Simon Josefsson <simon at josefsson.org> wrote:
> [...]
>>   2) To make exim link to and call libgcrypt's functions to read and
>>      update a random seed file instead?
> [...]
>> For simplicity and non-experimentalness, I would recommend 2).  I can
>> assist in implementing this in exim, if that would help.  We'd
>> definitely need a good example of how to do this in the gnutls manual
>> anyway.
> [...]
>
> Well, the basic patch for testing seems to be this one, basically
> identical to the skeleton you described. I gets down entropy-usage
> for a single STARTTLS to <300 bits from > 3000. 

Nice.  How much does a similar server consume using openssl?  Do openssl
used by exim use a seed file?

/Simon


From linux at paip.net  Fri Jan  4 16:33:43 2008
From: linux at paip.net (Ian Goldberg)
Date: Fri, 4 Jan 2008 10:33:43 -0500
Subject: Bug#448775: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <87tzltr7za.fsf@mocca.josefsson.org>
References: <20080103003214.GB14155@torres.zugschlus.de>
	<c331d99a0801032356i4e8be690h56be9db32318bdfc@mail.gmail.com>
	<20080104094848.GB4528@downhill.g.la>
	<c331d99a0801040159q7be28a15ndf1883ba8d4a2f02@mail.gmail.com>
	<87tzlt6ddp.fsf@wheatstone.g10code.de> <82wsqpg492.fsf@mid.bfk.de>
	<87fxxdbw59.fsf@mocca.josefsson.org>
	<87r6gx4sdf.fsf@wheatstone.g10code.de>
	<87tzltr7za.fsf@mocca.josefsson.org>
Message-ID: <20080104153343.GF31039@thunk.cs.uwaterloo.ca>

On Fri, Jan 04, 2008 at 03:16:57PM +0100, Simon Josefsson wrote:
> There is also the problem if something other than gnutls has already
> initialized libgcrypt.  This could happen if exim links to some other
> library that uses libgcrypt, for example, a LDAP or database library,
> which gets initialized before.  I'm not sure what we can do about this
> situation.  I also dislike global functions like this.

This is a nontrivial problem.  If there are multiple clients of
libgcrypt, and they use the globals in different ways, Bad Things
happen.  I've run into this with the Off-the-Record Messaging (OTR)
plugin for pidgin: if another plugin (say, Jabber) uses gnutls, which
initializes libgcrypt, and OTR also initializes libgcrypt (perhaps with
custom allocation functions), you can easily cause a crash.

It would be very nice to have all of the libgcrypt global state
encapsulated into a dynamically allocated region that's returned by the
libgcrypt initialization, and passed into all other functions.  [Macros
could be provided that automatically reference the most recent
allocation for backwards compatibility purposes.]

   - Ian


From ametzler at downhill.at.eu.org  Fri Jan  4 19:07:36 2008
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Fri, 4 Jan 2008 19:07:36 +0100
Subject: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <87ejcxpkpt.fsf@mocca.josefsson.org>
References: <20080104113847.GJ22955@kiste.smurf.noris.de>
	<c331d99a0801040355v2785cd0ei87e02beb7395717e@mail.gmail.com>
	<20080104122116.GK22955@kiste.smurf.noris.de>
	<87k5mpbwfl.fsf@mocca.josefsson.org>
	<87ve694trp.fsf@wheatstone.g10code.de>
	<87prwhr6xz.fsf@mocca.josefsson.org>
	<87fxxd37ze.fsf@wheatstone.g10code.de>
	<871w8xr2u4.fsf@mocca.josefsson.org>
	<20080104170649.GA4550@downhill.g.la>
	<87ejcxpkpt.fsf@mocca.josefsson.org>
Message-ID: <20080104180736.GB4550@downhill.g.la>

On 2008-01-04 Simon Josefsson <simon at josefsson.org> wrote:
> Andreas Metzler <ametzler at downhill.at.eu.org> writes:

> > On 2008-01-04 Simon Josefsson <simon at josefsson.org> wrote:
> > [...]
> >>   2) To make exim link to and call libgcrypt's functions to read and
> >>      update a random seed file instead?
> > [...]
> >> For simplicity and non-experimentalness, I would recommend 2).  I can
> >> assist in implementing this in exim, if that would help.  We'd
> >> definitely need a good example of how to do this in the gnutls manual
> >> anyway.
> > [...]

> > Well, the basic patch for testing seems to be this one, basically
> > identical to the skeleton you described. I gets down entropy-usage
> > for a single STARTTLS to <300 bits from > 3000. 

> Nice.  How much does a similar server consume using openssl?  Do openssl
> used by exim use a seed file?

Hello,

testing with a exim linked against OpenSSL I get *slightly* less
entropy usage (235 vs 289 bits in the first testrun) when connecting
with swaks (perl/OpenSSL).

These numbers were generated with the most simple method possible. -
Watch /proc/sys/kernel/random/entropy_avail when STARTTLSing from
localhost. Then STARTTLS from localhost to a remote server to find out
how much of the the total entropy usage was generated by the client,
instead of the server.

OpenSSL does not safe any random seed.
cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From ametzler at downhill.at.eu.org  Fri Jan  4 18:06:49 2008
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Fri, 4 Jan 2008 18:06:49 +0100
Subject: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <871w8xr2u4.fsf@mocca.josefsson.org>
References: <20080103003214.GB14155@torres.zugschlus.de>
	<c331d99a0801032356i4e8be690h56be9db32318bdfc@mail.gmail.com>
	<20080104113847.GJ22955@kiste.smurf.noris.de>
	<c331d99a0801040355v2785cd0ei87e02beb7395717e@mail.gmail.com>
	<20080104122116.GK22955@kiste.smurf.noris.de>
	<87k5mpbwfl.fsf@mocca.josefsson.org>
	<87ve694trp.fsf@wheatstone.g10code.de>
	<87prwhr6xz.fsf@mocca.josefsson.org>
	<87fxxd37ze.fsf@wheatstone.g10code.de>
	<871w8xr2u4.fsf@mocca.josefsson.org>
Message-ID: <20080104170649.GA4550@downhill.g.la>

On 2008-01-04 Simon Josefsson <simon at josefsson.org> wrote:
[...]
>   2) To make exim link to and call libgcrypt's functions to read and
>      update a random seed file instead?
[...]
> For simplicity and non-experimentalness, I would recommend 2).  I can
> assist in implementing this in exim, if that would help.  We'd
> definitely need a good example of how to do this in the gnutls manual
> anyway.
[...]

Well, the basic patch for testing seems to be this one, basically
identical to the skeleton you described. I gets down entropy-usage
for a single STARTTLS to <300 bits from > 3000. 

----------------------------
diff -Nur exim-orig/src/tls-gnu.c exim-4.68/src/tls-gnu.c
--- exim-orig/build-tree/src/tls-gnu.c	2007-08-30 16:31:06.000000000 +0200
+++ exim-4.68/build-tree/src/tls-gnu.c	2008-01-04 15:58:40.000000000 +0100
@@ -20,6 +20,7 @@
 #include <gnutls/gnutls.h>
 #include <gnutls/x509.h>
 
+#include <gcrypt.h>
 
 #define UNKNOWN_NAME "unknown"
 #define DH_BITS      1024
@@ -444,6 +445,8 @@
 
 initialized = (host == NULL)? INITIALIZED_SERVER : INITIALIZED_CLIENT;
 
+gcry_control (GCRYCTL_SET_RANDOM_SEED_FILE,"/var/run/exim4/random.seed");
+
 rc = gnutls_global_init();
 if (rc < 0) return tls_error(US"tls-init", host, rc);
 
@@ -1305,6 +1308,7 @@
 {
 if (tls_active < 0) return;  /* TLS was not active */
 
+gcry_control (GCRYCTL_UPDATE_RANDOM_SEED_FILE);
 if (shutdown)
   {
   DEBUG(D_tls) debug_printf("tls_close(): shutting down TLS\n");
----------------------------

Error checking, and having the file in spool_directory instead (since
it is a private directoy present on any exim installation) is missing.
cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From simon at josefsson.org  Fri Jan  4 20:40:44 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 04 Jan 2008 20:40:44 +0100
Subject: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <20080104180736.GB4550@downhill.g.la> (Andreas Metzler's message
	of "Fri, 4 Jan 2008 19:07:36 +0100")
References: <20080104113847.GJ22955@kiste.smurf.noris.de>
	<c331d99a0801040355v2785cd0ei87e02beb7395717e@mail.gmail.com>
	<20080104122116.GK22955@kiste.smurf.noris.de>
	<87k5mpbwfl.fsf@mocca.josefsson.org>
	<87ve694trp.fsf@wheatstone.g10code.de>
	<87prwhr6xz.fsf@mocca.josefsson.org>
	<87fxxd37ze.fsf@wheatstone.g10code.de>
	<871w8xr2u4.fsf@mocca.josefsson.org>
	<20080104170649.GA4550@downhill.g.la>
	<87ejcxpkpt.fsf@mocca.josefsson.org>
	<20080104180736.GB4550@downhill.g.la>
Message-ID: <87wsqpnzur.fsf@mocca.josefsson.org>

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

> On 2008-01-04 Simon Josefsson <simon at josefsson.org> wrote:
>> Andreas Metzler <ametzler at downhill.at.eu.org> writes:
>
>> > On 2008-01-04 Simon Josefsson <simon at josefsson.org> wrote:
>> > [...]
>> >>   2) To make exim link to and call libgcrypt's functions to read and
>> >>      update a random seed file instead?
>> > [...]
>> >> For simplicity and non-experimentalness, I would recommend 2).  I can
>> >> assist in implementing this in exim, if that would help.  We'd
>> >> definitely need a good example of how to do this in the gnutls manual
>> >> anyway.
>> > [...]
>
>> > Well, the basic patch for testing seems to be this one, basically
>> > identical to the skeleton you described. I gets down entropy-usage
>> > for a single STARTTLS to <300 bits from > 3000. 
>
>> Nice.  How much does a similar server consume using openssl?  Do openssl
>> used by exim use a seed file?
>
> Hello,
>
> testing with a exim linked against OpenSSL I get *slightly* less
> entropy usage (235 vs 289 bits in the first testrun) when connecting
> with swaks (perl/OpenSSL).

For my curiosity, what are those numbers if you run gnutls with a
NORMAL:%COMPAT priority?  Cipher padding needs one byte of randomness
for every encrypted packet, disabling padding may thus reduce the
randomness needed further.  This assumes you actually sent some data
back and forward, I don't whether you did.

> These numbers were generated with the most simple method possible. -
> Watch /proc/sys/kernel/random/entropy_avail when STARTTLSing from
> localhost. Then STARTTLS from localhost to a remote server to find out
> how much of the the total entropy usage was generated by the client,
> instead of the server.

So this result is both good and bad.

It is good because we are now on par with openssl on this.

It is bad because it suggests busier sites would run into the same
problem, with both gnutls and openssl.  However, that seems beyond the
current problem.

> OpenSSL does not safe any random seed.

Interesting, 235/8=29.375 bytes.  The minimum randomness needed per TLS
session would be 28 bytes for client hello random_bytes plus 46 bytes
for the PreMasterSecret (if RSA is used for key exchange).  If openssl
is using /dev/urandom, I think it is overly optimistic about the quality
of that data.

/Simon


From fweimer at bfk.de  Fri Jan  4 15:29:03 2008
From: fweimer at bfk.de (Florian Weimer)
Date: Fri, 04 Jan 2008 15:29:03 +0100
Subject: Bug#448775: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <87tzltr7za.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Fri, 04 Jan 2008 15:16:57 +0100")
References: <20080103003214.GB14155@torres.zugschlus.de>
	<c331d99a0801032356i4e8be690h56be9db32318bdfc@mail.gmail.com>
	<20080104094848.GB4528@downhill.g.la>
	<c331d99a0801040159q7be28a15ndf1883ba8d4a2f02@mail.gmail.com>
	<87tzlt6ddp.fsf@wheatstone.g10code.de> <82wsqpg492.fsf@mid.bfk.de>
	<87fxxdbw59.fsf@mocca.josefsson.org>
	<87r6gx4sdf.fsf@wheatstone.g10code.de>
	<87tzltr7za.fsf@mocca.josefsson.org>
Message-ID: <828x35ekb4.fsf@mid.bfk.de>

* Simon Josefsson:

> Ok.  Still, my main question is whether GnuTLS could utilize these hooks
> somehow.  I guess we could have two functions:
>
> int
> gnutls_set_random_seed_file (const char *filename);
> int
> gnutls_update_random_seed ();
>
> The first function would have to be called before gnutls_global_init().
> Then exim could invoke the function, to avoid having to call libgcrypt
> directly.

I'm not sure how this applies to Exim, though.  In many interesting
scenarios, we've got a central daemon process.  We could try to grab
an exclusive log on the seed file, and if it succeeds, call
gnutls_set_random_seed_file, and the update function when the daemon
exits.  However, I'm not really sure if this helps much because GNUTLS
isn't run until after a fork, and the library needs to reinitialize
the random pool anyway.

We'd need a separate daemon for that (IIRC, this is what Cryptlib
does).  Or we could fix the kernel.  The latter is hard because it is
kind of difficult to show that there actually is a problem.
Portability considerations favor the daemon approach, too, if you
aren't interested in shifting blame around.

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra?e 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99


From mh+gnutls-devel at zugschlus.de  Fri Jan  4 21:18:36 2008
From: mh+gnutls-devel at zugschlus.de (Marc Haber)
Date: Fri, 4 Jan 2008 21:18:36 +0100
Subject: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <87wsqpnzur.fsf@mocca.josefsson.org>
References: <20080104122116.GK22955@kiste.smurf.noris.de>
	<87k5mpbwfl.fsf@mocca.josefsson.org>
	<87ve694trp.fsf@wheatstone.g10code.de>
	<87prwhr6xz.fsf@mocca.josefsson.org>
	<87fxxd37ze.fsf@wheatstone.g10code.de>
	<871w8xr2u4.fsf@mocca.josefsson.org>
	<20080104170649.GA4550@downhill.g.la>
	<87ejcxpkpt.fsf@mocca.josefsson.org>
	<20080104180736.GB4550@downhill.g.la>
	<87wsqpnzur.fsf@mocca.josefsson.org>
Message-ID: <20080104201836.GD600@torres.zugschlus.de>

On Fri, Jan 04, 2008 at 08:40:44PM +0100, Simon Josefsson wrote:
> Interesting, 235/8=29.375 bytes.  The minimum randomness needed per TLS
> session would be 28 bytes for client hello random_bytes plus 46 bytes
> for the PreMasterSecret (if RSA is used for key exchange).  If openssl
> is using /dev/urandom, I think it is overly optimistic about the quality
> of that data.

I suspect that it only uses data from /dev/u?random to seed its own
PRNG.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190


From ametzler at downhill.at.eu.org  Sat Jan  5 13:09:38 2008
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sat, 5 Jan 2008 13:09:38 +0100
Subject: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <87wsqpnzur.fsf@mocca.josefsson.org>
References: <20080104122116.GK22955@kiste.smurf.noris.de>
	<87k5mpbwfl.fsf@mocca.josefsson.org>
	<87ve694trp.fsf@wheatstone.g10code.de>
	<87prwhr6xz.fsf@mocca.josefsson.org>
	<87fxxd37ze.fsf@wheatstone.g10code.de>
	<871w8xr2u4.fsf@mocca.josefsson.org>
	<20080104170649.GA4550@downhill.g.la>
	<87ejcxpkpt.fsf@mocca.josefsson.org>
	<20080104180736.GB4550@downhill.g.la>
	<87wsqpnzur.fsf@mocca.josefsson.org>
Message-ID: <20080105120938.GA4579@downhill.g.la>

On 2008-01-04 Simon Josefsson <simon at josefsson.org> wrote:
> Andreas Metzler <ametzler at downhill.at.eu.org> writes:
[...]
>> testing with a exim linked against OpenSSL I get *slightly* less
>> entropy usage (235 vs 289 bits in the first testrun) when connecting
>> with swaks (perl/OpenSSL).

> For my curiosity, what are those numbers if you run gnutls with a
> NORMAL:%COMPAT priority?

Sorry, I have no go these numbers a hand, since exim is not using
gnutls_priority_init() yet.

> Cipher padding needs one byte of randomness
> for every encrypted packet, disabling padding may thus reduce the
> randomness needed further.  This assumes you actually sent some data
> back and forward, I don't whether you did.
[...]

I just sent QUIT over the encrypted channel.

cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From ametzler at downhill.at.eu.org  Sat Jan  5 14:08:06 2008
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sat, 5 Jan 2008 14:08:06 +0100
Subject: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <20080104170649.GA4550@downhill.g.la>
References: <c331d99a0801032356i4e8be690h56be9db32318bdfc@mail.gmail.com>
	<20080104113847.GJ22955@kiste.smurf.noris.de>
	<c331d99a0801040355v2785cd0ei87e02beb7395717e@mail.gmail.com>
	<20080104122116.GK22955@kiste.smurf.noris.de>
	<87k5mpbwfl.fsf@mocca.josefsson.org>
	<87ve694trp.fsf@wheatstone.g10code.de>
	<87prwhr6xz.fsf@mocca.josefsson.org>
	<87fxxd37ze.fsf@wheatstone.g10code.de>
	<871w8xr2u4.fsf@mocca.josefsson.org>
	<20080104170649.GA4550@downhill.g.la>
Message-ID: <20080105130806.GB4579@downhill.g.la>

On 2008-01-04 Andreas Metzler <ametzler at downhill.at.eu.org> wrote:
[...]
> Well, the basic patch for testing seems to be this one, basically
> identical to the skeleton you described. I gets down entropy-usage
> for a single STARTTLS to <300 bits from > 3000. 
[...]
> Error checking, and having the file in spool_directory instead (since
> it is a private directoy present on any exim installation) is missing.

Updated version submitted to http://bugs.exim.org/show_bug.cgi?id=654
cu andreas


From wk at gnupg.org  Tue Jan  8 10:20:46 2008
From: wk at gnupg.org (Werner Koch)
Date: Tue, 08 Jan 2008 10:20:46 +0100
Subject: Bug#448775: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <20080104153343.GF31039@thunk.cs.uwaterloo.ca> (Ian Goldberg's
	message of "Fri, 4 Jan 2008 10:33:43 -0500")
References: <20080103003214.GB14155@torres.zugschlus.de>
	<c331d99a0801032356i4e8be690h56be9db32318bdfc@mail.gmail.com>
	<20080104094848.GB4528@downhill.g.la>
	<c331d99a0801040159q7be28a15ndf1883ba8d4a2f02@mail.gmail.com>
	<87tzlt6ddp.fsf@wheatstone.g10code.de> <82wsqpg492.fsf@mid.bfk.de>
	<87fxxdbw59.fsf@mocca.josefsson.org>
	<87r6gx4sdf.fsf@wheatstone.g10code.de>
	<87tzltr7za.fsf@mocca.josefsson.org>
	<20080104153343.GF31039@thunk.cs.uwaterloo.ca>
Message-ID: <871w8s65ch.fsf@wheatstone.g10code.de>

On Fri,  4 Jan 2008 16:33, linux at paip.net said:

> plugin for pidgin: if another plugin (say, Jabber) uses gnutls, which
> initializes libgcrypt, and OTR also initializes libgcrypt (perhaps with
> custom allocation functions), you can easily cause a crash.

At least we have a way to test whether libgcrypt is intialized (modulo
threading issues).

> It would be very nice to have all of the libgcrypt global state
> encapsulated into a dynamically allocated region that's returned by the
> libgcrypt initialization, and passed into all other functions.  [Macros

Right, however that means a complete API break.  It is also a sign that
such deep linking hierarchies are not very well thought-out.  We need to
live with it, though.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.



From wk at gnupg.org  Tue Jan  8 10:50:05 2008
From: wk at gnupg.org (Werner Koch)
Date: Tue, 08 Jan 2008 10:50:05 +0100
Subject: Bug#448775: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <8763y9r35b.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Fri, 04 Jan 2008 17:01:20 +0100")
References: <20080103003214.GB14155@torres.zugschlus.de>
	<c331d99a0801032356i4e8be690h56be9db32318bdfc@mail.gmail.com>
	<20080104094848.GB4528@downhill.g.la>
	<c331d99a0801040159q7be28a15ndf1883ba8d4a2f02@mail.gmail.com>
	<87tzlt6ddp.fsf@wheatstone.g10code.de> <82wsqpg492.fsf@mid.bfk.de>
	<87fxxdbw59.fsf@mocca.josefsson.org>
	<87r6gx4sdf.fsf@wheatstone.g10code.de>
	<87tzltr7za.fsf@mocca.josefsson.org>
	<87k5mp385s.fsf@wheatstone.g10code.de>
	<8763y9r35b.fsf@mocca.josefsson.org>
Message-ID: <87wsqk4pf6.fsf@wheatstone.g10code.de>

On Fri,  4 Jan 2008 17:01, simon at josefsson.org said:

> Right.  So what should applications like exim do exactly?  Is there

My suggestion is:

int
main ()
{
  int rc;
        
#ifdef WE_USE_PTHREADS
  rc = gcry_control (GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread);
  if (rc)
    error (EXIT_FAILURE, 0, "can't register Pthreads with Libgcrypt: %s\n",
           gpg_strerror (rc));
#endif

#ifndef WE_NEED_SECMEM
  gcry_control (GCRYCTL_DISABLE_SECMEM, 0);
#endif

  if (!gcry_check_version (NEED_LIBGCRYPT_VERSION) )
    error (EXIT_FAILURE, 0, "%s is too old (need %s, have %s)\n"), "libgcrypt",
           NEED_LIBGCRYPT_VERSION, gcry_check_version (NULL) );

  rc = gcry_control (GCRYCTL_SET_RANDOM_SEED_FILE, "foo/random-seed");
  if (rc)
    error (0, 0, "Warning: Error reading seed file: %s", gpg_strerror (rc));

#ifdef WE_NEED_SECMEM
  gcry_control (GCRYCTL_INIT_SECMEM, 32768, 0);
#endif

  gcry_control (GCRYCTL_INITIALIZATION_FINISHED, 0);

  DoIT();  /* initialize gnutls, runs the MTA.. */

  rc = gcry_control (GCRYCTL_UPDATE_RANDOM_SEED_FILE);
  if (rc)
    error (0, 0, "Warning: Updating seed file failed: %s", gpg_strerror (rc));
  return 0;
}


If you don't want to track libgcrypt dependencies just use 

  if (!gcry_check_version (NULL) )
    error (EXIT_FAILURE, 0, "problem intializing Libgcrypt version %s"), 
           gcry_check_version (NULL) );

This is a sufficient initialization.  GNUTLS may later still check the
version.  GNUTLS or any other library may use

  if (!gcry_control (GCRYCTL_INITIALIZATION_FINISHED_P))
    missing_libgcrypt_initialization ();

to check whether libgcrypt has already been initialized.  Nikos and me
came up with that scheme some years ago.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.



From wk at gnupg.org  Tue Jan  8 12:39:02 2008
From: wk at gnupg.org (Werner Koch)
Date: Tue, 08 Jan 2008 12:39:02 +0100
Subject: [patch] Re: Bug#448775: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <87bq7w4m7i.fsf@wheatstone.g10code.de> (Werner Koch's message of
	"Tue, 08 Jan 2008 11:59:29 +0100")
References: <20080103003214.GB14155@torres.zugschlus.de>
	<c331d99a0801032356i4e8be690h56be9db32318bdfc@mail.gmail.com>
	<20080104094848.GB4528@downhill.g.la>
	<20080105131725.GK3717@sliepen.org>
	<87sl184p8x.fsf@wheatstone.g10code.de>
	<878x30ab2u.fsf@mocca.josefsson.org>
	<87bq7w4m7i.fsf@wheatstone.g10code.de>
Message-ID: <87zlvg35t5.fsf_-_@wheatstone.g10code.de>

On Tue,  8 Jan 2008 11:59, wk at gnupg.org said:

> Anyway there 3000 calls to /dev/urandom are far too many for an initial
> pool filling.  I need to check this.

Found it.  The bug was introduced with libgcrypt 1.3.1.  Here is a patch:

2008-01-08  Werner Koch  <wk at g10code.com>

	* random.c (add_randomness): Do not just increment
	POOL_FILLED_COUNTER but update it by the actual amount of data.

Index: cipher/random.c
===================================================================
--- cipher/random.c	(revision 1277)
+++ cipher/random.c	(working copy)
@@ -1115,6 +1115,7 @@
 add_randomness (const void *buffer, size_t length, enum random_origins origin)
 {
   const unsigned char *p = buffer;
+  size_t count = 0;
 
   assert (pool_is_locked);
 
@@ -1123,6 +1124,7 @@
   while (length-- )
     {
       rndpool[pool_writepos++] ^= *p++;
+      count++;
       if (pool_writepos >= POOLSIZE )
         {
           /* It is possible that we are invoked before the pool is
@@ -1132,7 +1134,9 @@
              separately.  See also the remarks about the seed file. */
           if (origin >= RANDOM_ORIGIN_SLOWPOLL && !pool_filled)
             {
-              if (++pool_filled_counter >= POOLSIZE)
+              pool_filled_counter += count;
+              count = 0;
+              if (pool_filled_counter >= POOLSIZE)
                 pool_filled = 1;
             }
           pool_writepos = 0;


Also commited to SVN.  Old and new stats:

$ LD_PRELOAD=/usr/local/lib/libgcrypt.so ./benchmark --verbose random
random       130ms    30ms
random usage: poolsize=600 mixed=972 polls=3000/200 added=4200/378400
              outmix=200 getlvl1=200/13600 getlvl2=0/0

$ ./benchmark --verbose random
random        40ms    30ms
random usage: poolsize=600 mixed=377 polls=25/200 added=1225/21400
              outmix=200 getlvl1=200/13600 getlvl2=0/0



Shalom-Salam,

   Werner



-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.



From simon at josefsson.org  Tue Jan  8 17:16:02 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 08 Jan 2008 17:16:02 +0100
Subject: [patch] Re: Bug#448775: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <87zlvg35t5.fsf_-_@wheatstone.g10code.de> (Werner Koch's message
	of "Tue, 08 Jan 2008 12:39:02 +0100")
References: <20080103003214.GB14155@torres.zugschlus.de>
	<c331d99a0801032356i4e8be690h56be9db32318bdfc@mail.gmail.com>
	<20080104094848.GB4528@downhill.g.la>
	<20080105131725.GK3717@sliepen.org>
	<87sl184p8x.fsf@wheatstone.g10code.de>
	<878x30ab2u.fsf@mocca.josefsson.org>
	<87bq7w4m7i.fsf@wheatstone.g10code.de>
	<87zlvg35t5.fsf_-_@wheatstone.g10code.de>
Message-ID: <87myrgnvi5.fsf@mocca.josefsson.org>

Werner Koch <wk at gnupg.org> writes:

> On Tue,  8 Jan 2008 11:59, wk at gnupg.org said:
>
>> Anyway there 3000 calls to /dev/urandom are far too many for an initial
>> pool filling.  I need to check this.
>
> Found it.  The bug was introduced with libgcrypt 1.3.1.  Here is a patch:

Thanks.  Running gnutls-cli using libgcrypt SVN leads to:

random usage: poolsize=600 mixed=25 polls=25/113 added=593/12956
              outmix=3 getlvl1=3/136 getlvl2=0/0

Compared to the old situation:

random usage: poolsize=600 mixed=621 polls=3000/117 added=3588/370308
              outmix=3 getlvl1=3/136 getlvl2=0/0

So we have reduced /dev/urandom consumption from 3000*120=360kb to
25*120=3kb, right?  Strace also confirms the latter amount.  That's
good.

Still, 3kb per TLS connection is excessive, so I still recommend exim to
set a libgcrypt seeds file to solve the problem.

Thanks,
/Simon


From wk at gnupg.org  Tue Jan  8 19:13:52 2008
From: wk at gnupg.org (Werner Koch)
Date: Tue, 08 Jan 2008 19:13:52 +0100
Subject: [patch] Re: Bug#448775: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <87myrgnvi5.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Tue, 08 Jan 2008 17:16:02 +0100")
References: <20080103003214.GB14155@torres.zugschlus.de>
	<c331d99a0801032356i4e8be690h56be9db32318bdfc@mail.gmail.com>
	<20080104094848.GB4528@downhill.g.la>
	<20080105131725.GK3717@sliepen.org>
	<87sl184p8x.fsf@wheatstone.g10code.de>
	<878x30ab2u.fsf@mocca.josefsson.org>
	<87bq7w4m7i.fsf@wheatstone.g10code.de>
	<87zlvg35t5.fsf_-_@wheatstone.g10code.de>
	<87myrgnvi5.fsf@mocca.josefsson.org>
Message-ID: <87bq7wyylb.fsf@wheatstone.g10code.de>

On Tue,  8 Jan 2008 17:16, simon at josefsson.org said:

> Still, 3kb per TLS connection is excessive, so I still recommend exim to
> set a libgcrypt seeds file to solve the problem.

Yes, definitely.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.



From marcus.brinkmann at ruhr-uni-bochum.de  Wed Jan  9 12:22:32 2008
From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann)
Date: Wed, 09 Jan 2008 12:22:32 +0100
Subject: Bug#448775: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <871w8s65ch.fsf@wheatstone.g10code.de>
References: <20080103003214.GB14155@torres.zugschlus.de>
	<c331d99a0801032356i4e8be690h56be9db32318bdfc@mail.gmail.com>
	<20080104094848.GB4528@downhill.g.la>
	<c331d99a0801040159q7be28a15ndf1883ba8d4a2f02@mail.gmail.com>
	<87tzlt6ddp.fsf@wheatstone.g10code.de> <82wsqpg492.fsf@mid.bfk.de>
	<87fxxdbw59.fsf@mocca.josefsson.org>
	<87r6gx4sdf.fsf@wheatstone.g10code.de>
	<87tzltr7za.fsf@mocca.josefsson.org>
	<20080104153343.GF31039@thunk.cs.uwaterloo.ca>
	<871w8s65ch.fsf@wheatstone.g10code.de>
Message-ID: <87fxx79rbb.wl%marcus.brinkmann@ruhr-uni-bochum.de>

At Tue, 08 Jan 2008 10:20:46 +0100,
'Werner Koch' wrote:
> 
> On Fri,  4 Jan 2008 16:33, linux at paip.net said:
> 
> > plugin for pidgin: if another plugin (say, Jabber) uses gnutls, which
> > initializes libgcrypt, and OTR also initializes libgcrypt (perhaps with
> > custom allocation functions), you can easily cause a crash.
> 
> At least we have a way to test whether libgcrypt is intialized (modulo
> threading issues).

I think I also implemented it so that thread initialization can happen
multiple times, without conflicts, if the same thread package is used
everytime (otherwise you get an error).  It's a long time ago, though,
I may misremember something or it may have changed.

But there are other initialization issues which may not be so
forgiving (random pool, etc).  I don't know.

Thanks,
Marcus



From stefanmalte at gmail.com  Thu Jan 10 03:54:44 2008
From: stefanmalte at gmail.com (Stefan Malte Schumacher)
Date: Thu, 10 Jan 2008 03:54:44 +0100
Subject: Compiling libgcrypt 1.4.0
Message-ID: <fc1b0e2b0801091854o574f6b73qa48f8896ccb9ccda@mail.gmail.com>

Hello

I am currently trying to build GnuPG 2.08 from the source. I have compiled
and installed the latest versions of the necessary libraries (libksba-1.0.2,
libgpg-error-1.6,  libassuan-1.0.4 and pth-2.0.7) except libgcrypt
1.4.0which unfortunately aborts during the compile process. I have
tried to
install an older version (1.2.2) but it also aborted with an error in
rijndael.lol . I am using GNU Make 3.80 and gcc (GCC) 3.3.3 (SuSE Linux).
Below are the outputs of make and the configure-script while trying to build
libgcrypt 1.4.0. How can I get this working ?

Yours sincerely
Stefan Malte Schumacher

This is the make output :

/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I..
-I../src -I../src   -I/usr/local/include -g -O2 -Wall -Wpointer-arith -MT
rijndael.lo -MD -MP -MF .deps/rijndael.Tpo -c -o rijndael.lo rijndael.c
 gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g -O2
-Wall -Wpointer-arith -MT rijndael.lo -MD -MP -MF .deps/rijndael.Tpo -c
rijndael.c  -fPIC -DPIC -o .libs/rijndael.o
 gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g -O2
-Wall -Wpointer-arith -MT rijndael.lo -MD -MP -MF .deps/rijndael.Tpo -c
rijndael.c -o rijndael.o >/dev/null 2>&1
make[2]: *** [rijndael.lo] Fehler 1
make[2]: Leaving directory `/home/stefan/Software/Packed/libgcrypt-1.4.0
/cipher'
make[1]: *** [all-recursive] Fehler 1
make[1]: Leaving directory `/home/stefan/Software/Packed/libgcrypt-1.4.0'
make: *** [all] Fehler 2

And this is the output of configure :

checking for mmap... yes
checking for getpagesize... yes
checking for sysconf... yes
checking for waitpid... yes
checking for wait4... yes
checking for gettimeofday... yes
checking for getrusage... yes
checking for gethrtime... no
checking for clock_gettime... no
checking for fcntl... yes
checking for ftruncate... yes
checking for mlock... yes
checking for sysconf... (cached) yes
checking for getpagesize... (cached) yes
checking whether mlock is broken... no
checking for random device... yes
checking for _ prefix in compiled symbols... no
checking for mpi assembler functions... done
checking if gcc supports -Wpointer-arith... yes
checking whether non excutable stack support is requested... yes
checking whether assembler supports --noexecstack option... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating m4/Makefile
config.status: creating mpi/Makefile
config.status: creating cipher/Makefile
config.status: creating doc/Makefile
config.status: creating src/Makefile
config.status: creating src/gcrypt.h
config.status: creating src/libgcrypt-config
config.status: creating src/versioninfo.rc
config.status: creating tests/Makefile
config.status: creating config.h
config.status: config.h is unchanged
config.status: linking ./mpi/i386/mpih-add1.S to mpi/mpih-add1-asm.S
config.status: linking ./mpi/i386/mpih-sub1.S to mpi/mpih-sub1-asm.S
config.status: linking ./mpi/i386/mpih-mul1.S to mpi/mpih-mul1-asm.S
config.status: linking ./mpi/i386/mpih-mul2.S to mpi/mpih-mul2-asm.S
config.status: linking ./mpi/i386/mpih-mul3.S to mpi/mpih-mul3-asm.S
config.status: linking ./mpi/i386/mpih-lshift.S to mpi/mpih-lshift-asm.S
config.status: linking ./mpi/i386/mpih-rshift.S to mpi/mpih-rshift-asm.S
config.status: linking ./mpi/generic/mpi-asm-defs.h to mpi/mpi-asm-defs.h
config.status: executing depfiles commands
config.status: executing gcrypt-conf commands

                Configured for: GNU/Linux (i686-pc-linux-gnu)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20080110/eaa2b6f6/attachment-0001.htm>

From Axel.Thimm at ATrpms.net  Sun Jan 13 10:01:43 2008
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Sun, 13 Jan 2008 11:01:43 +0200
Subject: 1.4.0/rijndael.c/do_padlock: can't find a register in class
	`GENERAL_REGS' while reloading `asm' on elder gccs
Message-ID: <20080113090143.GA7458@puariko.nirvana>

Hi,

trying to build libgcrypt on RHEL4 (gcc 3.4.6) and RHEL3 (gcc 3.2.3)
fails with the above on i386 (which is register starved anyway),
x86_64 for example builds fine.

As later gcc version can build this even on i386 it looks like a gcc
shortcoming of that era. Still one would like to be able to build
libgcrypt on these distros :(

With RHEL4's gcc 3.4.6 a possible workaround is to use -O0 to gcc, but
that doesn't work with RHEL3's 3.2.3. :(

bash-2.05b# gcc -O0 -DHAVE_CONFIG_H -I. -I..  -I../src -I../src -c -o rijndael.o rijndael.c
rijndael.c: In function `do_padlock':
rijndael.c:2062: can't find a register in class `GENERAL_REGS' while reloading `asm'

Is there any workaround to get this building on older gccs? Thanks!
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: </pipermail/attachments/20080113/7e6e35c7/attachment.pgp>

From ismail at pardus.org.tr  Sun Jan 13 12:52:39 2008
From: ismail at pardus.org.tr (Ismail =?utf-8?q?D=C3=B6nmez?=)
Date: Sun, 13 Jan 2008 13:52:39 +0200
Subject: 1.4.0/rijndael.c/do_padlock: can't find a register in class
	`GENERAL_REGS' while reloading `asm' on elder gccs
In-Reply-To: <20080113090143.GA7458@puariko.nirvana>
References: <20080113090143.GA7458@puariko.nirvana>
Message-ID: <200801131352.39313.ismail@pardus.org.tr>

Sunday 13 January 2008 11:01:43 tarihinde Axel Thimm ?unlar? yazm??t?:
> Hi,
>
> trying to build libgcrypt on RHEL4 (gcc 3.4.6) and RHEL3 (gcc 3.2.3)
> fails with the above on i386 (which is register starved anyway),
> x86_64 for example builds fine.
>
> As later gcc version can build this even on i386 it looks like a gcc
> shortcoming of that era. Still one would like to be able to build
> libgcrypt on these distros :(
>
> With RHEL4's gcc 3.4.6 a possible workaround is to use -O0 to gcc, but
> that doesn't work with RHEL3's 3.2.3. :(
>
> bash-2.05b# gcc -O0 -DHAVE_CONFIG_H -I. -I..  -I../src -I../src -c -o
> rijndael.o rijndael.c rijndael.c: In function `do_padlock':
> rijndael.c:2062: can't find a register in class `GENERAL_REGS' while
> reloading `asm'
>
> Is there any workaround to get this building on older gccs? Thanks!

At least try -O2 -fomit-frame-pointer as CFLAGS so that it can optimize away 
some code which can reduce register usage.

Regards,
ismail

-- 
Never learn by your mistakes, if you do you may never dare to try again.


From wk at gnupg.org  Mon Jan 14 20:13:09 2008
From: wk at gnupg.org (Werner Koch)
Date: Mon, 14 Jan 2008 20:13:09 +0100
Subject: 1.4.0/rijndael.c/do_padlock: can't find a register in class
	`GENERAL_REGS' while reloading `asm' on elder gccs
In-Reply-To: <20080113090143.GA7458@puariko.nirvana> (Axel Thimm's message of
	"Sun, 13 Jan 2008 11:01:43 +0200")
References: <20080113090143.GA7458@puariko.nirvana>
Message-ID: <87hchgjk56.fsf@wheatstone.g10code.de>

On Sun, 13 Jan 2008 10:01, Axel.Thimm at ATrpms.net said:

> Is there any workaround to get this building on older gccs? Thanks!

./configure --disable-padlock

should help.

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.



From Axel.Thimm at ATrpms.net  Tue Jan 15 05:04:34 2008
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Tue, 15 Jan 2008 06:04:34 +0200
Subject: 1.4.0/rijndael.c/do_padlock: can't find a register in class
	`GENERAL_REGS' while reloading `asm' on elder gccs
In-Reply-To: <87hchgjk56.fsf@wheatstone.g10code.de>
	<200801131352.39313.ismail@pardus.org.tr>
References: <20080113090143.GA7458@puariko.nirvana>
	<87hchgjk56.fsf@wheatstone.g10code.de>
	<20080113090143.GA7458@puariko.nirvana>
	<200801131352.39313.ismail@pardus.org.tr>
Message-ID: <20080115040434.GA20593@puariko.nirvana>

On Sun, Jan 13, 2008 at 01:52:39PM +0200, Ismail D?nmez wrote:
> Sunday 13 January 2008 11:01:43 tarihinde Axel Thimm ?unlar? yazm??t?:
> > trying to build libgcrypt on RHEL4 (gcc 3.4.6) and RHEL3 (gcc 3.2.3)
> > fails with the above on i386 (which is register starved anyway),
> > x86_64 for example builds fine.
> >
> > As later gcc version can build this even on i386 it looks like a gcc
> > shortcoming of that era. Still one would like to be able to build
> > libgcrypt on these distros :(
> >
> > With RHEL4's gcc 3.4.6 a possible workaround is to use -O0 to gcc, but
> > that doesn't work with RHEL3's 3.2.3. :(
> >
> > bash-2.05b# gcc -O0 -DHAVE_CONFIG_H -I. -I..  -I../src -I../src -c -o
> > rijndael.o rijndael.c rijndael.c: In function `do_padlock':
> > rijndael.c:2062: can't find a register in class `GENERAL_REGS' while
> > reloading `asm'
> >
> > Is there any workaround to get this building on older gccs? Thanks!
> 
> At least try -O2 -fomit-frame-pointer as CFLAGS so that it can optimize away 
> some code which can reduce register usage.

Thanks, that did it!

On Mon, Jan 14, 2008 at 08:13:09PM +0100, Werner Koch wrote:
> > Is there any workaround to get this building on older gccs? Thanks!
> 
> ./configure --disable-padlock
> 
> should help.

Should I prefer this over the -fomit-frame-pointer flag?
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: </pipermail/attachments/20080115/0c92d509/attachment.pgp>

From simon at josefsson.org  Wed Jan 16 15:25:17 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 16 Jan 2008 15:25:17 +0100
Subject: MinGW+Wine and "DBG: rndw32: get performance data problem: ec=2"
Message-ID: <871w8hg84y.fsf@mocca.josefsson.org>

Hi!  On MinGW built binaries run under Wine, libgcrypt generates a lot
of these error messages:

DBG: rndw32: get performance data problem: ec=2
DBG: rndw32: get performance data problem: ec=2
DBG: rndw32: get performance data problem: ec=2
DBG: rndw32: get performance data problem: ec=2
DBG: rndw32: get performance data problem: ec=2
DBG: rndw32: get performance data problem: ec=2
DBG: rndw32: get performance data problem: ec=2

The relevant code in cipher/rndw32.c:registry_poll:

  pPerfData = gcry_xmalloc (cbPerfData);
  for (iterations=0; iterations < 10; iterations++)
    {
      dwSize = cbPerfData;
      if ( debug_me )
        log_debug ("rndw32#slow_gatherer_nt: get perf data\n" );

      status = RegQueryValueEx (HKEY_PERFORMANCE_DATA, "Global", NULL,
                                NULL, (LPBYTE) pPerfData, &dwSize);
      if (status == ERROR_SUCCESS)
        {
          if (!memcmp (pPerfData->Signature, L"PERF", 8))
            (*add) ( pPerfData, dwSize, requester );
          else
            log_debug ("rndw32: no PERF signature\n");
          break;
        }
      else if (status == ERROR_MORE_DATA)
        {
          cbPerfData += PERFORMANCE_BUFFER_STEP;
          pPerfData = gcry_xrealloc (pPerfData, cbPerfData);
        }
      else
        {
          log_debug ("rndw32: get performance data problem: ec=%ld\n",
                     status);
          break;
        }
    }
  gcry_free (pPerfData);

The error code 2:

/usr/i586-mingw32msvc/include/winerror.h:#define ERROR_FILE_NOT_FOUND 2L

According to:

http://msdn2.microsoft.com/en-us/library/ms724911(VS.85).aspx

  Return Value
...
  If the lpValueName registry value does not exist, the function returns
  ERROR_FILE_NOT_FOUND.

Libgcrypt can't know that the syscall will fail, but is there any reason
to believe that if the first of the 10 calls returns FILE_NOT_FOUND,
that another call to the same function with the same parameters will
succeed?  Possibly the code should just abort the loop in this
situation.

In any case, other calls to log_debug in that file are protected behind
a 'if (debug_me)' so I would suggest the patch below as a first step.

Thanks,
Simon

Index: rndw32.c
===================================================================
--- rndw32.c	(revision 1280)
+++ rndw32.c	(working copy)
@@ -1,5 +1,5 @@
 /* rndw32.c  -  W32 entropy gatherer
- * Copyright (C) 1999, 2000, 2002, 2003, 2007 Free Software Foundation, Inc.
+ * Copyright (C) 1999, 2000, 2002, 2003, 2007, 2008 Free Software Foundation, Inc.
  * Copyright Peter Gutmann, Matt Thomlinson and Blake Coverett 1996-2006
  *
  * This file is part of Libgcrypt.
@@ -440,8 +440,9 @@
         }
       else
         {
-          log_debug ("rndw32: get performance data problem: ec=%ld\n",
-                     status);
+	  if ( debug_me )
+	    log_debug ("rndw32: get performance data problem: ec=%ld\n",
+		       status);
           break;
         }
     }


From wk at gnupg.org  Wed Jan 16 20:02:57 2008
From: wk at gnupg.org (Werner Koch)
Date: Wed, 16 Jan 2008 20:02:57 +0100
Subject: MinGW+Wine and "DBG: rndw32: get performance data problem: ec=2"
In-Reply-To: <871w8hg84y.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Wed, 16 Jan 2008 15:25:17 +0100")
References: <871w8hg84y.fsf@mocca.josefsson.org>
Message-ID: <87r6ghfva6.fsf@wheatstone.g10code.de>

On Wed, 16 Jan 2008 15:25, simon at josefsson.org said:

> Libgcrypt can't know that the syscall will fail, but is there any reason
> to believe that if the first of the 10 calls returns FILE_NOT_FOUND,
> that another call to the same function with the same parameters will
> succeed?  Possibly the code should just abort the loop in this
> situation.

Frankly, I don't know.  The code is by Peter Gutmann and I would need to
do some research why it fails.

> In any case, other calls to log_debug in that file are protected behind
> a 'if (debug_me)' so I would suggest the patch below as a first step.

Well, the reason for always printing it is so that you could send this
complaint ;-).

What about printing the warning only once per process?


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.



From simon at josefsson.org  Wed Jan 16 21:26:16 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 16 Jan 2008 21:26:16 +0100
Subject: MinGW+Wine and "DBG: rndw32: get performance data problem: ec=2"
In-Reply-To: <87r6ghfva6.fsf@wheatstone.g10code.de> (Werner Koch's message of
	"Wed, 16 Jan 2008 20:02:57 +0100")
References: <871w8hg84y.fsf@mocca.josefsson.org>
	<87r6ghfva6.fsf@wheatstone.g10code.de>
Message-ID: <8763xtfrfb.fsf@mocca.josefsson.org>

Werner Koch <wk at gnupg.org> writes:

> On Wed, 16 Jan 2008 15:25, simon at josefsson.org said:
>
>> Libgcrypt can't know that the syscall will fail, but is there any reason
>> to believe that if the first of the 10 calls returns FILE_NOT_FOUND,
>> that another call to the same function with the same parameters will
>> succeed?  Possibly the code should just abort the loop in this
>> situation.
>
> Frankly, I don't know.  The code is by Peter Gutmann and I would need to
> do some research why it fails.

I suspect Wine doesn't emulate this part of Windows.

>> In any case, other calls to log_debug in that file are protected behind
>> a 'if (debug_me)' so I would suggest the patch below as a first step.
>
> Well, the reason for always printing it is so that you could send this
> complaint ;-).
>
> What about printing the warning only once per process?

Works for me.  How about this patch?

/Simon

Index: rndw32.c
===================================================================
--- rndw32.c	(revision 1280)
+++ rndw32.c	(working copy)
@@ -1,5 +1,5 @@
 /* rndw32.c  -  W32 entropy gatherer
- * Copyright (C) 1999, 2000, 2002, 2003, 2007 Free Software Foundation, Inc.
+ * Copyright (C) 1999, 2000, 2002, 2003, 2007, 2008 Free Software Foundation, Inc.
  * Copyright Peter Gutmann, Matt Thomlinson and Blake Coverett 1996-2006
  *
  * This file is part of Libgcrypt.
@@ -440,8 +440,11 @@
         }
       else
         {
-          log_debug ("rndw32: get performance data problem: ec=%ld\n",
-                     status);
+	  static int been_here = 1;
+	  if (been_here)
+	    log_debug ("rndw32: get performance data problem: ec=%ld\n",
+		       status);
+	  been_here = 0;
           break;
         }
     }


From simon at josefsson.org  Wed Jan 16 21:43:06 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 16 Jan 2008 21:43:06 +0100
Subject: MinGW+Wine and "DBG: rndw32: get performance data problem: ec=2"
In-Reply-To: <8763xtfrfb.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Wed, 16 Jan 2008 21:26:16 +0100")
References: <871w8hg84y.fsf@mocca.josefsson.org>
	<87r6ghfva6.fsf@wheatstone.g10code.de>
	<8763xtfrfb.fsf@mocca.josefsson.org>
Message-ID: <871w8hfqn9.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

> Works for me.  How about this patch?

I reversed the logic in the variable name, here is a better patch...

/Simon

Index: rndw32.c
===================================================================
--- rndw32.c	(revision 1280)
+++ rndw32.c	(working copy)
@@ -1,5 +1,5 @@
 /* rndw32.c  -  W32 entropy gatherer
- * Copyright (C) 1999, 2000, 2002, 2003, 2007 Free Software Foundation, Inc.
+ * Copyright (C) 1999, 2000, 2002, 2003, 2007, 2008 Free Software Foundation, Inc.
  * Copyright Peter Gutmann, Matt Thomlinson and Blake Coverett 1996-2006
  *
  * This file is part of Libgcrypt.
@@ -440,8 +440,11 @@
         }
       else
         {
-          log_debug ("rndw32: get performance data problem: ec=%ld\n",
-                     status);
+	  static int been_here = 0;
+	  if (!been_here)
+	    log_debug ("rndw32: get performance data problem: ec=%ld\n",
+		       status);
+	  been_here = 1;
           break;
         }
     }


From simon at josefsson.org  Thu Jan 17 21:33:38 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 17 Jan 2008 21:33:38 +0100
Subject: MinGW+Wine and "DBG: rndw32: get performance data problem: ec=2"
In-Reply-To: <871w8hfqn9.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Wed, 16 Jan 2008 21:43:06 +0100")
References: <871w8hg84y.fsf@mocca.josefsson.org>
	<87r6ghfva6.fsf@wheatstone.g10code.de>
	<8763xtfrfb.fsf@mocca.josefsson.org>
	<871w8hfqn9.fsf@mocca.josefsson.org>
Message-ID: <878x2oi44d.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

> Simon Josefsson <simon at josefsson.org> writes:
>
>> Works for me.  How about this patch?
>
> I reversed the logic in the variable name, here is a better patch...

This patch is somewhat better -- if the return codes for some reason
differ between invocations, the code will print a new debug message
every time it changes.

(The first time, 'been_here' can never be ERROR_SUCCESS, or it wouldn't
have reached that if clause.)

/Simon

Index: rndw32.c
===================================================================
--- rndw32.c	(revision 1280)
+++ rndw32.c	(working copy)
@@ -1,5 +1,5 @@
 /* rndw32.c  -  W32 entropy gatherer
- * Copyright (C) 1999, 2000, 2002, 2003, 2007 Free Software Foundation, Inc.
+ * Copyright (C) 1999, 2000, 2002, 2003, 2007, 2008 Free Software Foundation, Inc.
  * Copyright Peter Gutmann, Matt Thomlinson and Blake Coverett 1996-2006
  *
  * This file is part of Libgcrypt.
@@ -440,8 +440,11 @@
         }
       else
         {
-          log_debug ("rndw32: get performance data problem: ec=%ld\n",
-                     status);
+	  static int been_here = ERROR_SUCCESS;
+	  if (been_here != status)
+	    log_debug ("rndw32: get performance data problem: ec=%ld\n",
+		       status);
+	  been_here = status;
           break;
         }
     }


From ametzler at downhill.at.eu.org  Sun Jan 20 18:10:51 2008
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sun, 20 Jan 2008 18:10:51 +0100
Subject: [patch] Uses too much entropy (Debian Bug #343085)
In-Reply-To: <87bq7wyylb.fsf@wheatstone.g10code.de>
References: <20080103003214.GB14155@torres.zugschlus.de>
	<c331d99a0801032356i4e8be690h56be9db32318bdfc@mail.gmail.com>
	<20080104094848.GB4528@downhill.g.la>
	<20080105131725.GK3717@sliepen.org>
	<87sl184p8x.fsf@wheatstone.g10code.de>
	<878x30ab2u.fsf@mocca.josefsson.org>
	<87bq7w4m7i.fsf@wheatstone.g10code.de>
	<87zlvg35t5.fsf_-_@wheatstone.g10code.de>
	<87myrgnvi5.fsf@mocca.josefsson.org>
	<87bq7wyylb.fsf@wheatstone.g10code.de>
Message-ID: <20080120171051.GC4576@downhill.g.la>

On 2008-01-08 Werner Koch <wk at gnupg.org> wrote:
> On Tue,  8 Jan 2008 17:16, simon at josefsson.org said:

> > Still, 3kb per TLS connection is excessive, so I still recommend exim to
> > set a libgcrypt seeds file to solve the problem.

> Yes, definitely.

I gues it is not a god idea to share this seed file between multiple
hosts accessing a central mailq queue. Is this this assumption correct?
cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From ismail at pardus.org.tr  Mon Jan 21 00:04:00 2008
From: ismail at pardus.org.tr (Ismail =?utf-8?q?D=C3=B6nmez?=)
Date: Mon, 21 Jan 2008 01:04:00 +0200
Subject: Inline asm fix for padlock support
Message-ID: <200801210104.00614.ismail@pardus.org.tr>

Hi,

Jakub Jelinek of gcc and glibc fame fixed inline asm in padlock support code. 
His patch and explanation is available at 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34725#c4 .

I tested the patch and it works.

Regards,
ismail

-- 
Never learn by your mistakes, if you do you may never dare to try again.


From wk at gnupg.org  Mon Jan 21 13:07:01 2008
From: wk at gnupg.org (Werner Koch)
Date: Mon, 21 Jan 2008 13:07:01 +0100
Subject: [patch] Uses too much entropy (Debian Bug #343085)
In-Reply-To: <20080120171051.GC4576@downhill.g.la> (Andreas Metzler's message
	of "Sun, 20 Jan 2008 18:10:51 +0100")
References: <20080103003214.GB14155@torres.zugschlus.de>
	<c331d99a0801032356i4e8be690h56be9db32318bdfc@mail.gmail.com>
	<20080104094848.GB4528@downhill.g.la>
	<20080105131725.GK3717@sliepen.org>
	<87sl184p8x.fsf@wheatstone.g10code.de>
	<878x30ab2u.fsf@mocca.josefsson.org>
	<87bq7w4m7i.fsf@wheatstone.g10code.de>
	<87zlvg35t5.fsf_-_@wheatstone.g10code.de>
	<87myrgnvi5.fsf@mocca.josefsson.org>
	<87bq7wyylb.fsf@wheatstone.g10code.de>
	<20080120171051.GC4576@downhill.g.la>
Message-ID: <878x2j9yca.fsf@wheatstone.g10code.de>

On Sun, 20 Jan 2008 18:10, ametzler at downhill.at.eu.org said:

> I gues it is not a god idea to share this seed file between multiple
> hosts accessing a central mailq queue. Is this this assumption correct?

Yes.  You better avoid that if possible.



Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.



From marcus.brinkmann at ruhr-uni-bochum.de  Mon Jan 21 18:02:20 2008
From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann)
Date: Mon, 21 Jan 2008 18:02:20 +0100
Subject: Inline asm fix for padlock support
In-Reply-To: <200801210104.00614.ismail@pardus.org.tr>
References: <200801210104.00614.ismail@pardus.org.tr>
Message-ID: <87ve5n9ko3.wl%marcus.brinkmann@ruhr-uni-bochum.de>

At Mon, 21 Jan 2008 01:04:00 +0200,
Ismail D?nmez <ismail at pardus.org.tr> wrote:
> Jakub Jelinek of gcc and glibc fame fixed inline asm in padlock support code. 
> His patch and explanation is available at 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34725#c4 .
> 
> I tested the patch and it works.

Yes, but it leaves a superfluous %0 which is not used.  So, I put in a
slightly simpler fix:

  asm volatile
    ("pushl %%ebx\n\t"           /* Save GOT register.  */
     "xorl  %%eax, %%eax\n\t"    /* 0 -> EAX.  */
     "cpuid\n\t"                 /* Get vendor ID.  */
     "movl  %%ebx, (%0)\n\t"     /* EBX,EDX,ECX -> VENDOR_ID.  */
     "movl  %%edx, 4(%0)\n\t"
     "movl  %%ecx, 8(%0)\n\t"
     "popl  %%ebx\n"
     :
     : "S" (&vendor_id[0])
     : "%eax", "%ecx", "%edx", "cc"
     );

Thanks,
Marcus



From stefanmalte at gmail.com  Tue Jan 22 07:20:18 2008
From: stefanmalte at gmail.com (Stefan Malte Schumacher)
Date: Tue, 22 Jan 2008 07:20:18 +0100
Subject: Compiling libgcrypt - again
Message-ID: <fc1b0e2b0801212220u2374c8cbl7e21ad4a2682e7c6@mail.gmail.com>

Hi

It seems that the first posting did not arrive completely, so I am trying it
again
I want to compile libgcrypt (current I am trying version 1.4.0) in order to
compile the latest version of gnupg. Unfortunately the compiling process
stops with the following error :

 gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g -O2
-Wall -Wpointer-
h -MT rijndael.lo -MD -MP -MF .deps/rijndael.Tpo -c rijndael.c  -fPIC -DPIC
-o .libs/rijndae
 gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g -O2
-Wall -Wpointer-
h -MT rijndael.lo -MD -MP -MF .deps/rijndael.Tpo -c rijndael.c -o
rijndael.o>/dev/null 2>&1
make[2]: *** [rijndael.lo] Fehler 1
make[2]: Leaving directory `/home/stefan/Software/Packed/libgcrypt-1.4.0
/cipher'
make[1]: *** [all-recursive] Fehler 1
make[1]: Leaving directory `/home/stefan/Software/Packed/libgcrypt-1.4.0'
make: *** [all] Fehler 2

I am using Suse Linux 9.1 with gcc 3.3.3-41. You can have a look at the
complete output of configure at the following URL :
http://www.pagan.mynetcologne.de/Temp/configure-output

If you require any additional information to solve the problem please let me
know.

Bye
Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20080122/87e275f4/attachment.htm>

From nmav at gnutls.org  Sun Jan 27 11:08:47 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 27 Jan 2008 12:08:47 +0200
Subject: padlock + SIGSEGV
Message-ID: <200801271208.48191.nmav@gnutls.org>

In some occasions I've noticed some segmentation fauls on padlock code. This 
was using the debian libldap + gnutls13 + libgcrypt 1.4.0.

I'm trying to understand why this is happening, but I have no clue. Notice 
that the stack changes after entering the "asm volatile". To make it more 
interesting gnutls-cli compiled with gnutls13 and libgcrypt 1.4.0 works as 
expected. gnutls_global_init() is used in both cases so it shouldn't be 
initialization error. Any suggestions on why this might happen?

gdb ls
(gdb) break do_padlock
Breakpoint 4 at 0xb7958dca: file rijndael.c, line 2043.
(gdb) run -al /home/
Breakpoint 4 at 0xb79b4dca: file rijndael.c, line 2043.
[Switching to Thread -1210574656 (LWP 12034)]

Breakpoint 2, do_padlock (ctx=0xbfc3addc, decrypt_flag=0, 
bx=0xbfc3afe8 "(?\006\b??\237??????o??", 
    ax=0xb79f9ac8 "\001K?\"x?\2353\035Q\200\0206C?\232") at rijndael.c:2043
2043    {
(gdb) cont
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0xb79b4e41 in do_padlock (ctx=0xbfc3ac5c, decrypt_flag=<value optimized out>, 
    bx=0xbfc3afe8 "(?\006\b??\237??????o??", ax=0x1 <Address 0x1 out of 
bounds>) at rijndael.c:2062
2062      asm volatile 
(gdb) 
(gdb) bt
#0  0xb79b4e41 in do_padlock (ctx=0xbfc3ac5c, decrypt_flag=<value optimized 
out>, 
    bx=0xbfc3afe8 "(?\006\b??\237??????o??", ax=0x1 <Address 0x1 out of 
bounds>) at rijndael.c:2062
#1  0xb79b5442 in rijndael_encrypt (context=0xbfc3addc, b=0x1 <Address 0x1 out 
of bounds>, 
    a=0xb79f9ac8 "\001K?\"x?\2353\035Q\200\0206C?\232") at rijndael.c:2091
#2  0xb79b5b54 in rijndael_setkey (context=0x808dee0, 
key=0x80900e8 "\034L?g?5D\231j>#?=\0024???\b\b?\001\t\b ", 
    keylen=16) at rijndael.c:2288
#3  0xb79a1123 in _gcry_cipher_ctl (h=0x808de90, cmd=1, buffer=0x80900e8, 
buflen=16) at cipher.c:774
#4  0xb7998e62 in gcry_cipher_ctl (h=0x808de90, cmd=1, buffer=0x80900e8, 
buflen=16) at visibility.c:504
#5  0xb7b1f4d3 in ?? () from /usr/lib/libgnutls.so.13
#6  0x0808de90 in ?? ()
#7  0x00000001 in ?? ()
#8  0x080900e8 in ?? ()
#9  0x00000010 in ?? ()
#10 0x0806b1b8 in ?? ()
#11 0xb7b4c91c in ?? () from /usr/lib/libgnutls.so.13
#12 0xbfc3b0b4 in ?? ()
#13 0xb7affa72 in _gnutls_cipher_init () from /usr/lib/libgnutls.so.13
Backtrace stopped: frame did not save the PC
(gdb) 



From marcus.brinkmann at ruhr-uni-bochum.de  Sun Jan 27 14:35:16 2008
From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann)
Date: Sun, 27 Jan 2008 14:35:16 +0100
Subject: padlock + SIGSEGV
In-Reply-To: <200801271208.48191.nmav@gnutls.org>
References: <200801271208.48191.nmav@gnutls.org>
Message-ID: <87bq775r3f.wl%marcus.brinkmann@ruhr-uni-bochum.de>

At Sun, 27 Jan 2008 12:08:47 +0200,
Nikos Mavrogiannopoulos wrote:
> 
> In some occasions I've noticed some segmentation fauls on padlock code. This 
> was using the debian libldap + gnutls13 + libgcrypt 1.4.0.
> 
> I'm trying to understand why this is happening, but I have no clue. Notice 
> that the stack changes after entering the "asm volatile". To make it more 
> interesting gnutls-cli compiled with gnutls13 and libgcrypt 1.4.0 works as 
> expected. gnutls_global_init() is used in both cases so it shouldn't be 
> initialization error. Any suggestions on why this might happen?

Can you test if this was fixed in the SVN repository by:

2008-01-21  Marcus Brinkmann  <marcus at g10code.de>

        * hwfeatures.c (detect_ia32_gnuc): Fix inline asm.

It seems to be the same bug as was reported before.

Thanks,
Marcus



From nmav at gnutls.org  Sun Jan 27 15:53:34 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 27 Jan 2008 16:53:34 +0200
Subject: padlock + SIGSEGV
In-Reply-To: <87bq775r3f.wl%marcus.brinkmann@ruhr-uni-bochum.de>
References: <200801271208.48191.nmav@gnutls.org>
	<87bq775r3f.wl%marcus.brinkmann@ruhr-uni-bochum.de>
Message-ID: <200801271653.34818.nmav@gnutls.org>

On Sunday 27 January 2008, Marcus Brinkmann wrote:

> Can you test if this was fixed in the SVN repository by:
>
> 2008-01-21  Marcus Brinkmann  <marcus at g10code.de>
>
>         * hwfeatures.c (detect_ia32_gnuc): Fix inline asm.
> It seems to be the same bug as was reported before.

No it doesn't seem to fix it. Note that this board uses the padlock engine 
(via processor).

regards,
Nikos


From marcus.brinkmann at ruhr-uni-bochum.de  Sun Jan 27 16:10:12 2008
From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann)
Date: Sun, 27 Jan 2008 16:10:12 +0100
Subject: padlock + SIGSEGV
In-Reply-To: <200801271653.34818.nmav@gnutls.org>
References: <200801271208.48191.nmav@gnutls.org>
	<87bq775r3f.wl%marcus.brinkmann@ruhr-uni-bochum.de>
	<200801271653.34818.nmav@gnutls.org>
Message-ID: <87abmr5mp7.wl%marcus.brinkmann@ruhr-uni-bochum.de>

At Sun, 27 Jan 2008 16:53:34 +0200,
Nikos Mavrogiannopoulos wrote:
> 
> On Sunday 27 January 2008, Marcus Brinkmann wrote:
> 
> > Can you test if this was fixed in the SVN repository by:
> >
> > 2008-01-21  Marcus Brinkmann  <marcus at g10code.de>
> >
> >         * hwfeatures.c (detect_ia32_gnuc): Fix inline asm.
> > It seems to be the same bug as was reported before.
> 
> No it doesn't seem to fix it. Note that this board uses the padlock engine 
> (via processor).

Sorry, I was confused.

Thanks,
Marcus



From vasili3000 at hotmail.com  Tue Jan 29 12:43:39 2008
From: vasili3000 at hotmail.com (Vassilios Zafiropoulos)
Date: Tue, 29 Jan 2008 11:43:39 +0000
Subject: proper init and destruction
Message-ID: <BAY127-W306CBCB32E3A0695FD86B7C4350@phx.gbl>


hello list,

i am currently debugging a library that uses libgrypt, ver 11.2.3.

running a sample program through valgrind, i noticed that some memory allocated when using function

gcry_randomize

is never released. the samle program follows:

#include "stdio.h"
#include "stdlib.h"

#include <gcrypt.h>

int main(){

  char message[16];
  memset(message, 0, sizeof(message));
  int i =0;
  for(;i<100;i++){
    gcry_randomize(message, 16, GCRY_VERY_STRONG_RANDOM);
  }
  return 1;
}


this call uses only once some 1500 bytes that are never released. Is there something I can do about it? am i missing something on proper initialization and destruction of the library internal structures?

also, in some other part of the lib i am debugging, successive calls to 

gcry_check_version

allocate up to 500 bytes that are never released. Do you have any clues on that?


thank you,

vasilis.

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20080129/d2624ea2/attachment.htm>

From marcus.brinkmann at ruhr-uni-bochum.de  Tue Jan 29 14:07:57 2008
From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann)
Date: Tue, 29 Jan 2008 14:07:57 +0100
Subject: proper init and destruction
In-Reply-To: <BAY127-W306CBCB32E3A0695FD86B7C4350@phx.gbl>
References: <BAY127-W306CBCB32E3A0695FD86B7C4350@phx.gbl>
Message-ID: <87k5ls4w5u.wl%marcus.brinkmann@ruhr-uni-bochum.de>

At Tue, 29 Jan 2008 11:43:39 +0000,
Vassilios Zafiropoulos <vasili3000 at hotmail.com> wrote:
> this call uses only once some 1500 bytes that are never released. Is there something I can do about it? am i missing something on proper initialization and destruction of the library internal structures?
> 
> also, in some other part of the lib i am debugging, successive calls to 
> 
> gcry_check_version
> 
> allocate up to 500 bytes that are never released. Do you have any clues on that?

Some results are cached statically in libgcrypt.  This is not a bug.

A bug would be unbounded growth of memory allocations.

Thanks,
Marcus



From ametzler at downhill.at.eu.org  Wed Jan 30 19:20:10 2008
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Wed, 30 Jan 2008 19:20:10 +0100
Subject: Bug#448775: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <87wsqk4pf6.fsf@wheatstone.g10code.de>
References: <20080104094848.GB4528@downhill.g.la>
	<c331d99a0801040159q7be28a15ndf1883ba8d4a2f02@mail.gmail.com>
	<87tzlt6ddp.fsf@wheatstone.g10code.de> <82wsqpg492.fsf@mid.bfk.de>
	<87fxxdbw59.fsf@mocca.josefsson.org>
	<87r6gx4sdf.fsf@wheatstone.g10code.de>
	<87tzltr7za.fsf@mocca.josefsson.org>
	<87k5mp385s.fsf@wheatstone.g10code.de>
	<8763y9r35b.fsf@mocca.josefsson.org>
	<87wsqk4pf6.fsf@wheatstone.g10code.de>
Message-ID: <20080130182010.GA5173@downhill.g.la>

On 2008-01-08 Werner Koch <wk at gnupg.org> wrote:
> On Fri,  4 Jan 2008 17:01, simon at josefsson.org said:

> > Right.  So what should applications like exim do exactly?  Is there

> My suggestion is:
[...]

Hello,

which yields this stripped down version for exim:
------------------------------
diff -urNad exim4-4.68~/build-tree/src/tls-gnu.c exim4-4.68/build-tree/src/tls-gnu.c
--- exim4-4.68~/build-tree/src/tls-gnu.c	2007-08-30 14:31:06.000000000 +0000
+++ exim4-4.68/build-tree/src/tls-gnu.c	2008-01-27 18:42:00.000000000 +0000
@@ -20,6 +20,7 @@
 #include <gnutls/gnutls.h>
 #include <gnutls/x509.h>
 
+#include <gcrypt.h>
 
 #define UNKNOWN_NAME "unknown"
 #define DH_BITS      1024
@@ -440,10 +441,32 @@
   uschar *crl)
 {
 int rc;
+uschar filename[200];
 uschar *cert_expanded, *key_expanded, *cas_expanded, *crl_expanded;
+gcry_error_t gcr_rc;
 
 initialized = (host == NULL)? INITIALIZED_SERVER : INITIALIZED_CLIENT;
 
+/* Use a random_seed file for gcrypt's RNG */
+if (host_number_string != NULL)
+  {
+  if (!string_format(filename, sizeof(filename), "%s/random.seed%s",
+    spool_directory, host_number_string))
+  return tls_error(US"overlong filename spool_directory/random.seedlocalhost_number", host, 0);
+  } 
+else
+  {
+  if (!string_format(filename, sizeof(filename), "%s/random.seed",
+    spool_directory))
+  return tls_error(US"overlong filename spool_directory/random.seed", host, 0);
+  }
+
+gcr_rc = gcry_control (GCRYCTL_SET_RANDOM_SEED_FILE,filename);
+if (gcr_rc)
+  return tls_error(US"Failure to set random_seed file", host, gcr_rc);
+
+gcry_control (GCRYCTL_INITIALIZATION_FINISHED, 0);
+
 rc = gnutls_global_init();
 if (rc < 0) return tls_error(US"tls-init", host, rc);
 
@@ -1303,8 +1326,19 @@
 void
 tls_close(BOOL shutdown)
 {
+gcry_error_t gcr_rc;
+
 if (tls_active < 0) return;  /* TLS was not active */
 
+gcr_rc = gcry_control (GCRYCTL_UPDATE_RANDOM_SEED_FILE);
+
+if (gcr_rc)
+  {
+  DEBUG(D_tls) debug_printf(
+    "GCRYCTL_UPDATE_RANDOM_SEED_FILE failed: (%d): (%s)\n",
+    gcr_rc,gcry_strerror(gcr_rc));
+  }
+
 if (shutdown)
   {
   DEBUG(D_tls) debug_printf("tls_close(): shutting down TLS\n");
------------------------------

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
not available.

thanks, cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From wk at gnupg.org  Thu Jan 31 09:26:07 2008
From: wk at gnupg.org (Werner Koch)
Date: Thu, 31 Jan 2008 09:26:07 +0100
Subject: Bug#448775: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <20080130182010.GA5173@downhill.g.la> (Andreas Metzler's message
	of "Wed, 30 Jan 2008 19:20:10 +0100")
References: <20080104094848.GB4528@downhill.g.la>
	<c331d99a0801040159q7be28a15ndf1883ba8d4a2f02@mail.gmail.com>
	<87tzlt6ddp.fsf@wheatstone.g10code.de> <82wsqpg492.fsf@mid.bfk.de>
	<87fxxdbw59.fsf@mocca.josefsson.org>
	<87r6gx4sdf.fsf@wheatstone.g10code.de>
	<87tzltr7za.fsf@mocca.josefsson.org>
	<87k5mp385s.fsf@wheatstone.g10code.de>
	<8763y9r35b.fsf@mocca.josefsson.org>
	<87wsqk4pf6.fsf@wheatstone.g10code.de>
	<20080130182010.GA5173@downhill.g.la>
Message-ID: <87fxwe4d0g.fsf@wheatstone.g10code.de>

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


Shalom-Salam,

   Werner




-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.