[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: 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
