[130172] in cryptography@c2.net mail archive
Re: OpenID/Debian PRNG/DNS Cache poisoning advisory
daemon@ATHENA.MIT.EDU (Nicolas Williams)
Fri Aug 8 15:41:01 2008
Date: Fri, 8 Aug 2008 14:33:10 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Eric Rescorla <ekr@networkresonance.com>
Cc: Dan Kaminsky <dan@doxpara.com>, Dave Korn <dave.korn@artimi.com>,
"'Ben Laurie'" <benl@google.com>, bugtraq@securityfocus.com,
security@openid.net, "'OpenID List'" <general@openid.net>,
cryptography@metzdowd.com, full-disclosure@lists.grok.org.uk
In-Reply-To: <20080808182015.B7DE350846@romeo.rtfm.com>
On Fri, Aug 08, 2008 at 11:20:15AM -0700, Eric Rescorla wrote:
> At Fri, 08 Aug 2008 10:43:53 -0700,
> Dan Kaminsky wrote:
> > 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
> [...]
You could store {<hash>, <seed>} and check matches for false positives
by generating a key with the corresponding seed and then checking for an
exact match -- slow, but rare. This way you could choose your false
positive rate / table size comfort zone and vary the size of the hash
accordingly.
Nico
--
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
