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: <20080808182015.B7DE350846@romeo.rtfm.com>
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/