* 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=filerev=0sc=0
causes crashes in exim.
IIRC, I have already posted this, but perhaps my wording was a
On Thu, 13 Mar 2008 09:32, [EMAIL PROTECTED] 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
On 2008-03-11 Werner Koch [EMAIL PROTECTED] wrote:
On Sat, 8 Mar 2008 09:48, [EMAIL PROTECTED] 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(
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(O j: , stderr); break;)?
Yes, it does.
$ sudo exim -bdf
On Sat, 8 Mar 2008 09:48, [EMAIL PROTECTED] 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 ();
On 2008-01-31 Werner Koch [EMAIL PROTECTED] wrote:
On Wed, 30 Jan 2008 19:20, [EMAIL PROTECTED] 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
Andreas Metzler [EMAIL PROTECTED] writes:
On 2008-01-31 Werner Koch [EMAIL PROTECTED] wrote:
On Wed, 30 Jan 2008 19:20, [EMAIL PROTECTED] 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
On 2008-03-08 Simon Josefsson [EMAIL PROTECTED] wrote:
Andreas Metzler [EMAIL PROTECTED] 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
On Wed, 30 Jan 2008 19:20, [EMAIL PROTECTED] 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
On 2008-01-08 Werner Koch [EMAIL PROTECTED] wrote:
On Fri, 4 Jan 2008 17:01, [EMAIL PROTECTED] 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
At Tue, 08 Jan 2008 10:20:46 +0100,
'Werner Koch' wrote:
On Fri, 4 Jan 2008 16:33, [EMAIL PROTECTED] 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
On Fri, 4 Jan 2008 17:01, [EMAIL PROTECTED] 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
On Fri, 4 Jan 2008 16:33, [EMAIL PROTECTED] 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
Werner Koch [EMAIL PROTECTED] writes:
On Sat, 5 Jan 2008 14:17, [EMAIL PROTECTED] said:
gnutls-serv reads 3000 times 120 bytes from /dev/urandom, yes, 360
kilobytes!
Run
gcry_control (GCRYCTL_DUMP_RANDOM_STATS);
to get statistics about libgcrypt's RNG.
How should I interpret the
On Sat, 5 Jan 2008 14:17, [EMAIL PROTECTED] said:
gnutls-serv reads 3000 times 120 bytes from /dev/urandom, yes, 360
kilobytes!
Run
gcry_control (GCRYCTL_DUMP_RANDOM_STATS);
to get statistics about libgcrypt's RNG.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Auschnahme
On Tue, 8 Jan 2008 11:03, [EMAIL PROTECTED] said:
random usage: poolsize=600 mixed=621 polls=3000/117 added=3588/370308
outmix=3 getlvl1=3/136 getlvl2=0/0
- The random pool has been mixed 621 times.
- The slow random poll function has been called 3000 times to fill and
update
On Tue, 8 Jan 2008 11:59, [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
*
Werner Koch [EMAIL PROTECTED] writes:
On Tue, 8 Jan 2008 11:59, [EMAIL PROTECTED] 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
On Tue, 8 Jan 2008 17:16, [EMAIL PROTECTED] 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.
--
On 2008-01-04 Simon Josefsson [EMAIL PROTECTED] wrote:
Andreas Metzler [EMAIL PROTECTED] 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
On Fri, Jan 04, 2008 at 10:48:48AM +0100, Andreas Metzler wrote:
When acting as a server gnutls pulls that much data from /dev/urandom
that entropy available for /dev/random is down to its minimum
safeguard. ((it is not possible to completely deplete /dev/random by
reading from /dev/urandom
On 2008-01-04 Andreas Metzler [EMAIL PROTECTED] 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
On Jan 3, 2008 2:32 AM, Marc Haber [EMAIL PROTECTED] wrote:
Hi,
Debian Bug #343085, http://bugs.debian.org/343085
This is an example bug for the entropy issue which seems to be the
most pressing issue with Exim4 and GnuTLS at the moment. Let me give
you a little background: Exim4's
On Fri, 4 Jan 2008 13:35, [EMAIL PROTECTED] 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
Hi,
Nikos Mavrogiannopoulos:
However on the point. I still believe it is a kernel
issue. A process should not be able to deplete randomness in a system.
There's a trade-off between make /dev/urandom as random as possible
(which requires mixing in random bits from hardware), and make
A workaround might be to use the libgcrypt's random number process
feature which uses a single server process to feed other processes
with entropy (I've never worked with it so I don't know if it can be
used in that case). This might solve this issue.
Disagree.
* /dev/(u)random is more
Matthias Urlichs [EMAIL PROTECTED] 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
* 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
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
On Fri, 4 Jan 2008 13:41, [EMAIL PROTECTED] 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
Werner Koch [EMAIL PROTECTED] writes:
On Fri, 4 Jan 2008 13:35, [EMAIL PROTECTED] 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
Werner Koch [EMAIL PROTECTED] writes:
On Fri, 4 Jan 2008 13:41, [EMAIL PROTECTED] 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
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
Werner Koch [EMAIL PROTECTED] writes:
On Fri, 4 Jan 2008 15:16, [EMAIL PROTECTED] 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
On Fri, 4 Jan 2008 15:16, [EMAIL PROTECTED] 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
On Fri, 4 Jan 2008 15:39, [EMAIL PROTECTED] 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.
Werner Koch [EMAIL PROTECTED] 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
On 2008-01-04 Simon Josefsson [EMAIL PROTECTED] 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
Andreas Metzler [EMAIL PROTECTED] writes:
On 2008-01-04 Simon Josefsson [EMAIL PROTECTED] 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
On 2008-01-04 Simon Josefsson [EMAIL PROTECTED] wrote:
Andreas Metzler [EMAIL PROTECTED] writes:
On 2008-01-04 Simon Josefsson [EMAIL PROTECTED] wrote:
[...]
2) To make exim link to and call libgcrypt's functions to read and
update a random seed file instead?
[...]
For
Andreas Metzler [EMAIL PROTECTED] writes:
On 2008-01-04 Simon Josefsson [EMAIL PROTECTED] wrote:
Andreas Metzler [EMAIL PROTECTED] writes:
On 2008-01-04 Simon Josefsson [EMAIL PROTECTED] wrote:
[...]
2) To make exim link to and call libgcrypt's functions to read and
update a
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
42 matches
Mail list logo
