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.
