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. 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. 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
