Mailing List Archive

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


_______________________________________________
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:35, simon@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

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

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


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

Werner Koch <wk@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

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

On 2008-01-04 Simon Josefsson <simon@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'

_______________________________________________
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-04 Simon Josefsson <simon@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

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

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

> > On 2008-01-04 Simon Josefsson <simon@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'

_______________________________________________
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-04 Simon Josefsson <simon@josefsson.org> wrote:
>> Andreas Metzler <ametzler@downhill.at.eu.org> writes:
>
>> > On 2008-01-04 Simon Josefsson <simon@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

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

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

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

On 2008-01-04 Simon Josefsson <simon@josefsson.org> wrote:
> Andreas Metzler <ametzler@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'

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

On 2008-01-04 Andreas Metzler <ametzler@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

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