[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87d4kjrybw.fsf@mid.deneb.enyo.de>
Date: Fri, 08 Aug 2008 23:28:19 +0200
From: Florian Weimer <fw@...eb.enyo.de>
To: Eric Rescorla <ekr@...workresonance.com>
Cc: Dan Kaminsky <dan@...para.com>, Dave Korn <dave.korn@...imi.com>,
"'Ben Laurie'" <benl@...gle.com>, bugtraq@...urityfocus.com,
security@...nid.net, "'OpenID List'" <general@...nid.net>,
cryptography@...zdowd.com, full-disclosure@...ts.grok.org.uk
Subject: Re: OpenID/Debian PRNG/DNS Cache poisoning advisory
* Eric Rescorla:
> Why do you say a couple of megabytes? 99% of the value would be
> 1024-bit RSA keys. There are ~32,000 such keys.
There are three sets of keys, for big-endian 32-bit, little-endian
32-bit and little-endian 64-bit. On top of that, "openssl genrsa"
generates different keys depending on the existence of $HOME/.rnd (and
-3 creates yet another set of keys, but this is more in the league of
"different key length"). If the library is used for key generation
(instead of the command line tool), different keys might result.
On the other hand, the on-disk size would be comparable to the phishing
filter database.
Part of the problem of the CRL approach is that CAs usually have
policies against obtaining private keys and therefore can't prove to the
customer that their keys are compromised. And adding a CRL entry when
the customer isn't convinced that they've got a problem is probably not
a good idea, either.
Powered by blists - more mailing lists