full-disclosure - Re: OpenID/Debian PRNG/DNS Cache poisoning advisory

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <aafe62bf0808081154i62fb15bfp6153938d1bb90ce6@mail.gmail.com>
Date: Fri, 8 Aug 2008 14:54:21 -0400
From: "Tim Dierks" <tim@...rks.org>
To: "Dan Kaminsky" <dan@...para.com>
Cc: cryptography@...zdowd.com, Eric Rescorla <ekr@...workresonance.com>,
	Dave Korn <dave.korn@...imi.com>,
	full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com,
	OpenID List <general@...nid.net>, security@...nid.net
Subject: Re: OpenID/Debian PRNG/DNS Cache poisoning
	advisory

On Fri, Aug 8, 2008 at 1:43 PM, Dan Kaminsky <dan@...para.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

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/