-
Website
http://www.matasano.com/log -
Original page
http://www.matasano.com/log/466/notarized-advisories-prove-you-found-something-without-giving-up-secrets/ -
Subscribe
All Comments -
Community
-
Top Commenters
-
Press Controls
3 comments · 2 points
-
ChrisMtso
12 comments · 1 points
-
Eric Monti
11 comments · 1 points
-
StatlerAndWaldorf
12 comments · 3 points
-
Dave G.
7 comments · 1 points
-
-
Popular Threads
This mechanism may also have the added value of being one that courts are familiar with.
One of the purposes of such a list was for people to post their encrypted exploits. That way, they could just post the key at a later date, and prove that they had something at a particular time.
The hash version is perhaps a little more elegant. Though, the hash algorithms need to quit failing so fast.
For some reason, SecurityFocus wasn't interested in hosting such a list, go figure. So I never started it.
How much better is SHA1 at this point anyways?
http://blogs.msdn.com/oldnewthing/archive/2006/...
(It provoked a really interesting response: people thought it was a challenge to decode his prediction!)
I haven't looked at Tom's idea above more than just the initial glance to read the post (i.e., I haven't read it in detail yet), but to point out other potential way you could extend this or augment it, here are some ideas.
Add blinding, and a third party to be the notary. The canonical (Applied Crypto, 2nd Ed.) simple example is something like (from memory):
1. Peter Pwnerson takes his expoit (code and notes, or whatever) and multiples it by a random value. Peter now has a blinded exploit and the random value is a blinding factor.
2. Peter sends the blinded exploit to Nancy Notary.
3. Nancy signs the blinded document.
4. Peter divides the blinded exploit by the blinding factor, leaving the original exploit, signed by Nancy.
There are, of course, a whole bunch of caveats regarding randomness, etc. Mostly this helps Tom's protocol, which relies on Peter to create the timestamp and can be subverted. Nothing stops me from backdating a bunch of stuff, except maybe that no one saw me "publish" the hash when I claim I did. Still.
One other somewhat related thing I've been idly thinking about this week has been what kind of real-world zero-knowedge protcol could be implemented to address the issue that David Maynor and Jon Ellch have been dealing with.
This proposal works in the absence of any infrastructure. Unless someone tells me "you idiot, this won't work because...", we'll probably publish most of our advisory backlog this weekend using it.
One extension I came up with since last night: tack a key to the end of your advisory before you notarize it (head /dev/urandom | openssl sha1). This gives you the option, though you probably won't take it, of publishing an advisory later WITHOUT disclosing how long the vendor took (just change the key).
http://www.citi.umich.edu/projects/smartcard/le...
http://www.citi.umich.edu/projects/smartcard/sm...
Definitly not a new idea, but still interesting.
http://www.cl.cam.ac.uk/~rja14/Papers/fawkes.pdf