On Jan 4, 2008 11:48 AM, Andreas Metzler <ametzler@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
_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
> >> 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
_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel