On Wednesday 03 February 2010 16:44:35 Michael Rogers wrote: > Not quite, because a CHK would also include a decryption key, which you > don't need in this case. > > 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? A CHK without a decryption key is possible, but imho not a good idea. And it's not *usably* short - what is the benefit? The usual proposal is to have a per-node configured lookup table e.g. tufi/toad... > > Cheers, > Michael > > alex wrote: > > Call me stoopid but I have just described a CHK, right? > > > > alex wrote: > > > >> I was pondering the hideous length of freenet keys. I know they have to be > >> like that since they're the necessary crypto to decrypt the contents. > >> However, I got this idea for shorter alternate keys. It's maybe not > >> readily practical but perhaps you think of something better derived from > >> this. > >> > >> Let's say we have a new key type (HSH from hash). This key is just a > >> renamed KSK. However, the gist is that the content hash must match the key > >> itself. The content, in turn, is a proper key to redirect to. > >> > >> These keys are as long as the hash used (e.g. for sha1 they would be 28 > >> chars, pity it's broken) and the content is sane, as long as collisions > >> aren't practical to generate. And now you can paste keys that don't wrap > >> at 80 chars, for example. > >> > >> Certainly, being KSKs, they can be spammed, but they're a convenience, and > >> the node can check that the content is legit and discard it if spoofed. > >> > >> Example: > >> > >> HSH at 1d229271928d3f9e2bb0375bd6ce5db6c6d348d9 > >> > >> or may be > >> > >> HSH at sha1/1d229271928d3f9e2bb0375bd6ce5db6c6d348d9 > >> > > HSH at > > sha256/66a045b452102c59d840ec097d59d9467e13a3f34f6494e539ffd32c1bb35f18 > >> to make it generic on the hash used. > >> > >> Dunno if attacks to short hashes are able to provide colliding content of > >> the same length as the original. Otherwise, even if flawed, short hashes > >> could be still usable as long as the expected content has to be a valid > >> CHK. > > > > > > _______________________________________________ > > Tech mailing list > > Tech at freenetproject.org > > http://osprey.vm.bytemark.co.uk/cgi-bin/mailman/listinfo/tech > > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://osprey.vm.bytemark.co.uk/cgi-bin/mailman/listinfo/tech > > -------------- 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/20100204/09364932/attachment.pgp>
