Mailing List Archive

On Fri, 4 Jan 2008 10:59, nmav@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.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Werner Koch <wk@gnupg.org> writes:

> On Fri, 4 Jan 2008 10:59, nmav@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

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

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

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Florian Weimer <fweimer@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

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Fri, 4 Jan 2008 13:41, simon@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.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Werner Koch <wk@gnupg.org> writes:

> On Fri, 4 Jan 2008 13:41, simon@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

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

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

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

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

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Fri, 4 Jan 2008 15:16, simon@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.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Werner Koch <wk@gnupg.org> writes:

> On Fri, 4 Jan 2008 15:16, simon@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

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Fri, 4 Jan 2008 16:33, linux@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.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Fri, 4 Jan 2008 17:01, simon@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.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

At Tue, 08 Jan 2008 10:20:46 +0100,
'Werner Koch' wrote:
>
> On Fri, 4 Jan 2008 16:33, linux@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


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On 2008-01-08 Werner Koch <wk@gnupg.org> wrote:
> On Fri, 4 Jan 2008 17:01, simon@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'

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Wed, 30 Jan 2008 19:20, ametzler@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.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On 2008-01-31 Werner Koch <wk@gnupg.org> wrote:
> On Wed, 30 Jan 2008 19:20, ametzler@downhill.at.eu.org said:

>> Any obvious breakage? Exim does not use any threading. I have not
>> included an gcry_check_version(NULL) since I thought gcry_control()
>> would fail as reliably as gcry_check_version() would, if gcrypt was

> Better insert a gcry_check_version because this is the safe way to
> initialize gcrypt. The initialization is also done with most other
> gcry_control calls but that is a failsafe feature. Explicitly
> initialization is better (you don't need to check the return code, just
> call it.)

Hello,

we still seem have not been able to find a really working solution,
this patch <http://svn.debian.org/wsvn/pkg-exim4/exim/trunk/debian/patches/65_saverandomseed.dpatch?op=file&rev=0&sc=0>
causes crashes in exim.

Quoting Marc Haber in http://bugs.exim.org/show_bug.cgi?id=654
| However, the secondary MX (which delivers some spam to the primary MX) noted
| that the primary box had become unreliable in TLS:
| 2008-01-30 14:51:21 1JKDKT-0003ME-AG Remote host mailgate.zugschlus.de
| [85.214.68.41] closed connection in response to STARTTLS
|
| When this happened (a couple of times per hour), I didn't get any
| atypical log entries on mailgate.
|
| This was a repeating, but intermittent failure since mailgate
| continued to work normally, and STARTTLS was successful most of the
| time.
[...]
| Going back to the same exim sans the random-seed patch, entropy
| average went back to 200, but the STARTTLS failures vanished.

We have tried to isolate what actually breaks, by only applying parts
of the patch (e.g setting up dthe seed file, but not updating it.),
but it looks like the mere presence of
gcry_control (GCRYCTL_SET_RANDOM_SEED_FILE,filename)
causes the crashes.

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

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

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

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

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

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

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

/Simon

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On 2008-03-08 Simon Josefsson <simon@josefsson.org> wrote:
> Andreas Metzler <ametzler@downhill.at.eu.org> writes:
[...]
> > We have tried to isolate what actually breaks, by only applying parts
> > of the patch (e.g setting up dthe seed file, but not updating it.),
> > but it looks like the mere presence of
> > gcry_control (GCRYCTL_SET_RANDOM_SEED_FILE,filename)
> > causes the crashes.

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

Yes, we did.
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'

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Sat, 8 Mar 2008 09:48, ametzler@downhill.at.eu.org said:

> but it looks like the mere presence of
> gcry_control (GCRYCTL_SET_RANDOM_SEED_FILE,filename)
> causes the crashes.

That should be easy to debug:

void
_gcry_set_random_seed_file( const char *name )
{
if (seed_file_name)
BUG ();
seed_file_name = gcry_xstrdup (name);
}

I guess you are running the init code twice. Isn't there any output to
stderr?


Shalom-Salam,

Werner

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


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On 2008-03-11 Werner Koch <wk@gnupg.org> wrote:
> On Sat, 8 Mar 2008 09:48, ametzler@downhill.at.eu.org said:

> > but it looks like the mere presence of
> > gcry_control (GCRYCTL_SET_RANDOM_SEED_FILE,filename)
> > causes the crashes.

> That should be easy to debug:

> void
> _gcry_set_random_seed_file( const char *name )
> {
> if (seed_file_name)
> BUG ();
> seed_file_name = gcry_xstrdup (name);
> }

> I guess you are running the init code twice. Isn't there any output to
> stderr?

Hello,
The exim daemon forks and closes stderr/out. Marc, can you try running
exim in the foreground and check whether gcrypt throws an error
(case GCRY_LOG_BUG: fputs("Ohhhh jeeee: ", stderr); break;)?

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'

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Wed, Mar 12, 2008 at 08:20:44PM +0100, Andreas Metzler wrote:
> The exim daemon forks and closes stderr/out. Marc, can you try running
> exim in the foreground and check whether gcrypt throws an error
> (case GCRY_LOG_BUG: fputs("Ohhhh jeeee: ", stderr); break;)?

Yes, it does.

$ sudo exim -bdf -q30m -oX 587:465:25 -oP /var/run/exim4/exim.pid
Ohhhh jeeee: ... this is a bug (random.c:528:_gcry_set_random_seed_file)
Ohhhh jeeee: ... this is a bug (random.c:528:_gcry_set_random_seed_file)
Ohhhh jeeee: ... this is a bug (random.c:528:_gcry_set_random_seed_file)
Ohhhh jeeee: ... this is a bug (random.c:528:_gcry_set_random_seed_file)
Ohhhh jeeee: ... this is a bug (random.c:528:_gcry_set_random_seed_file)
Ohhhh jeeee: ... this is a bug (random.c:528:_gcry_set_random_seed_file)
Ohhhh jeeee: ... this is a bug (random.c:528:_gcry_set_random_seed_file)
Ohhhh jeeee: ... this is a bug (random.c:528:_gcry_set_random_seed_file)
Ohhhh jeeee: ... this is a bug (random.c:528:_gcry_set_random_seed_file)
Ohhhh jeeee: ... this is a bug (random.c:528:_gcry_set_random_seed_file)
Ohhhh jeeee: ... this is a bug (random.c:528:_gcry_set_random_seed_file)
Ohhhh jeeee: ... this is a bug (random.c:528:_gcry_set_random_seed_file)

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

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

* Andreas Metzler:

> we still seem have not been able to find a really working solution,
> this patch <http://svn.debian.org/wsvn/pkg-exim4/exim/trunk/debian/patches/65_saverandomseed.dpatch?op=file&rev=0&sc=0>
> causes crashes in exim.

IIRC, I have already posted this, but perhaps my wording was a bit
unclear.

I don't think the seed file approach works for a forking daemon like
Exim because you cannot guaranteed an undisturbed read/modify/write
cycle on the seed file. Locking is out of the question, too, because
it would bring the mail system to a standstill. And it's arguably not
a good idea to reuse the same seed file in different forked children.

You need a separate daemon, or trust the kernel and read fewer bytes
from /dev/urandom.

--
Florian Weimer <fweimer@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

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Thu, 13 Mar 2008 09:32, fweimer@bfk.de said:

> I don't think the seed file approach works for a forking daemon like
> Exim because you cannot guaranteed an undisturbed read/modify/write
> cycle on the seed file. Locking is out of the question, too, because

It depends on how much entropy you want to have in the pool. Even with
all processes using the same random seed, libgcrypt will add extra
random to each process (e.g. 16 bytes from /dev/urandom). This turns it
into a PRNG which is not worse than using /dev/urandom directly.

The advantage reading a the seed file is that libgcrypt does not need to
initialize its own random pool. You may view this initialization as
assuring that the random pool is not plain zeroed out.

If you don't like that approach you cat limit the reuse of the seed file
by using a seed file name depending on the pid, like
asprintf ("/foo/bar/andom_seed.%d", ((int)getpid() % 5))


Salam-Shalom,

Werner

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


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel