lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ