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.

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


Reply via email to