Re: [Full-disclosure] OpenID/Debian PRNG/DNS Cache poisoning advisory

[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@xxxxxxxxxxx> 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: ,
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 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

Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia -