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.
Agreed, the HSH is purely a convenience in the sense that the done would do the checking for the client. Alex. > > 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
