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.


Reply via email to