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
| ||
|
Date: Fri, 08 Aug 2008 11:20:15 -0700 From: Eric Rescorla <ekr@...workresonance.com> 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 At Fri, 08 Aug 2008 10:43:53 -0700, Dan Kaminsky wrote: > Eric Rescorla 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. Why do you say a couple of megabytes? 99% of the value would be 1024-bit RSA keys. There are ~32,000 such keys. If you devote an 80-bit hash to each one (which is easily large enough to give you a vanishingly small false positive probability; you could probably get away with 64 bits), that's 320KB. Given that the smallest Firefox build (Windows) is 7.1 MB, this doesn't sound like a nonstarter to me at all, especially since the browser could download it in the background. > Updating the filter could then be something we do on a 24 hour > autoupdate basis. Doing either this, or doing revocation checking over > DNS (seriously), is not necessarily a bad idea. We need to do better > than we've been. Yes, there are a number of approaches to more efficient CRL checking, I think that's a separate issue. -Ekr _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists