* John Denker:

> Florian Weimer wrote:
>> Would you recommend to switch to /dev/urandom (which doesn't block if
>> the entropy estimate for the in-kernel pool reaches 0), and stick to
>> generating new DH parameters for each connection,
> No, I wouldn't.

Not even for the public parameters?

>> or ...  generate them once per day and use it for several
>> connections?
> I wouldn't do that, either.

> If the problem is a shortage of random bits, get more random bits!

We are talking about a stream of several kilobits per second on a busy
server (with suitable mailing lists, of course).  This is impossible
to obtain without special hardware.

> Almost every computer sold on the mass market these days has a sound
> system built in. That can be used to generate industrial-strength
> randomness at rates more than sufficient for the applications we're
> talking about.  

How many bits per second can you produce using an off-the-shelf sound
card?  Your paper gives a number in excess of 14 kbps, if I read it
correctly, which is surprisingly high.

It's an interesting approach, but for a mail server which mainly sends
to servers with self-signed certificates, it's overkill.  Debian also
supports a few architectures for which sound cards are hard to obtain.
And we would separate desktop and server implementations because the
sound card is used on desktops.  I'd rather sacrifice forward secrecy
than to add such complexity.

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to