On Thursday 04 February 2010 15:45:50 Michael Rogers wrote: > Matthew Toseland wrote: > >> Your suggestion seems like a great idea to me, but how about this > >> modification: instead of HSH at sha1/blahblah, just use > >> KSK at sha1/blahblah. That way no modifications to the node are > >> necessary - apps can start using your scheme immediately, with the > >> app being responsible for checking that the received content hashes > >> to the expected value, then resubmitting it to the node as a key. > > > > IMHO that would be messy and dangerous, what happens when they insert > > the wrong content? > > Anyone can insert any content under KSK at sha1/blahblah if that key > doesn't already exist, but that's detectable (1) by the person > retrieving the key, because the content won't hash to the expected > value, and (2) by the person trying to insert the real content, who will > get a collision. So, finding the key squatted, what does the inserter > do? Try another key. > > The inserter has a practically unlimited number of attempts to insert a > KSK that the attacker hasn't already squatted, by inserting redirects to > the same data (it's not necessary to reinsert the data) and turning the > keys of the redirects into KSKs.
It's not unlimited, unless you want each requestor to fetch all the attacker's redirects, and the content they point to, first. That can be limited *to a degree* by implementing enforced checksums at the top block metadata. > Each KSK is unguessable in advance by > the attacker, who can only squat them by seeing the redirect being > inserted and inserting KSK at sha1/hash_of_the_key_of_the_redirect before > the inserter does. Basically it's the classic KSK war, just like with chat, assuming the attacker can guess the content. The attacker inserts once for each slot; everyone fetching it fetches all the slots, multiplying his effort. > > Assuming the inserter's not surrounded by attacker-controlled nodes, > *eventually* the inserter will learn the key of one of its redirects > before the attacker does, and be able to insert > KSK at sha1/hash_of_the_key_of_the_redirect before the attacker does - at > which point the inserter has a secure and working KSK, and knows it, > because the KSK insert didn't collide. > > The inserter doesn't have to bother giving any of the squatted KSKs to > anyone else - the whole process of inserting redirects and checking for > KSK collisions can be automated. > > > A CHK without a decryption key is possible, but imho not a good idea. > > And it's not *usably* short - what is the benefit? > > Sorry, I wasn't proposing CHKs without decryption keys, just pointing > out that using the hash of the data as the KSK keyword isn't quite the > same as a CHK. > > As for usability: I agree with Alex that 20-30 characters would be more > usable than current Freenet keys. But the advantage of the > KSK at sha1/blahblah scheme is that we don't all have to agree about this: > people who think it's useful can start using it without special support > from the node. > > Cheers, > Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20100205/7966e0a8/attachment.pgp>
