[130178] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: OpenID/Debian PRNG/DNS Cache poisoning advisory

daemon@ATHENA.MIT.EDU (Tim Dierks)
Fri Aug 8 16:02:07 2008

Date: Fri, 8 Aug 2008 15:52:47 -0400
From: "Tim Dierks" <tim@dierks.org>
To: "Dan Kaminsky" <dan@doxpara.com>
Cc: "Eric Rescorla" <ekr@networkresonance.com>, 
	"Dave Korn" <dave.korn@artimi.com>, "Ben Laurie" <benl@google.com>, 
	bugtraq@securityfocus.com, security@openid.net, 
	"OpenID List" <general@openid.net>, cryptography@metzdowd.com, 
	full-disclosure@lists.grok.org.uk
In-Reply-To: <489C85D9.6080803@doxpara.com>

[Sorry for duplicates, but I got multiple requests for a non-HTML
version, and I didn't want to fork the thread. Also sorry for
initially sending HTML; I didn't realize it was so abhorrent these
days. ]

On Fri, Aug 8, 2008 at 1:43 PM, Dan Kaminsky <dan@doxpara.com> wrote:
>>
>> It's easy to compute all the public keys that will be generated
>> by the broken PRNG. The clients could embed that list and refuse
>> to accept any certificate containing one of them. So, this
>> is distinct from CRLs in that it doesn't require knowing which servers have which cert...
>
> Funnily enough I was just working on this -- and found that we'd end up adding a couple megabytes to every browser.  #DEFINE NONSTARTER.  I am curious about the feasibility of a large bloom filter that fails back to online checking though.  This has side effects but perhaps they can be made statistically very unlikely, without blowing out the size of a browser.

Using this Bloom filter calculator:
http://www.cc.gatech.edu/~manolios/bloom-filters/calculator.html ,
plus the fact that there are 32,768 weak keys for every key type &
size, I get various sizes of necessary Bloom filter, based on how many
key type / sizes you want to check and various false positive rates:
 * 3 key types/sizes with 1e-6 false positive rate: 2826759 bits = 353 KB
 * 3 key types/sizes with 1e-9 false positive rate: 4240139 bits = 530 KB
 * 7 key types/sizes with 1e-6 false positive rate: 6595771 bits = 824 KB
 * 7 key types/sizes with 1e-9 false positive rate: 9893657 bits = 1237 KB

I presume that the first 3 & first 7 key type/sizes in this list
http://metasploit.com/users/hdm/tools/debian-openssl/ are the best to
incorporate into the filter.

Is there any chance it would be feasible to get a list of all the weak
keys that were actually certified by browser-installed CAs, or those
weak certificates? Presumably, this list would be much smaller and
would be more effectively distributed in Bloom filter form.

 - Tim

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

home help back first fref pref prev next nref lref last post