Re: "tiny" keys for freenet

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@sha1/blahblah, just use KSK@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@1d229271928d3f9e2bb0375bd6ce5db6c6d348d9
> >>
> >> or may be
> >>
> >> HSH@sha1/1d229271928d3f9e2bb0375bd6ce5db6c6d348d9
> >>
> > HSH@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
> > [email protected]
> > http://osprey.vm.bytemark.co.uk/cgi-bin/mailman/listinfo/tech
> 
> _______________________________________________
> Tech mailing list
> [email protected]
> http://osprey.vm.bytemark.co.uk/cgi-bin/mailman/listinfo/tech
> 
>

_______________________________________________
Tech mailing list
[email protected]
http://osprey.vm.bytemark.co.uk/cgi-bin/mailman/listinfo/tech

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQIcBAABCAAGBQJLat6XAAoJEHsvjZi+xPTDEHUP/jkoda6BPOHYYWDk3HX3OWHP
YlfhGHr3OIcFNfXf5/a5J2GHMzWIMg6OXtAguFLHt0AQiIoWcKLUTY7Hd9Slt7nh
K1+1GmNJmJmUKw7xNq2+Z3g2AcsNhbvjOnmkfs9pt2q1MfZPejfeQv5eb+n2X9aa
BHxYb9gmQBBBzxC1AX66Wo3Jl3I6Rs1zx8Jvle+b7V0Gefa4abgOZ2yWyZMoCzz9
xj59eKyqsCSDBpYsbGZmbWX5b36DXxYr5B7ygsmWolbYTdHOHpgJKi8/7gAajlyq
ZCQOLSa/7kidBjgirRGse7acwg0qBGe2LAuNOaqJxJDlaHZgeLz2lvH5LEEv8dKo
wV+hF98zgphvfaFwc6EDPBnRzSVECmeXrJ3oTpfTnS2ad89AjphqSrUX5nhJP46I
kSBWx9Yk1mkPhoP3700S3i8b6oJYY6epAugVeafrK1ZgRaafCv+UOyaL01/0spMI
RDFiezrtj5FxMpr3aqQIGl2wVoaXxJih1kAZ3j19x5fDwjysGb/iF2I8d/0xV1uH
nfadfrBCTfjDDJU9G8gLtlqQOpqD8hChXs7g4ZQh6KSPeAD1oJVambUAqSzukGtU
YXhBAmALa04u+ntYwfEspwtu7nhiPfkf9CSyH5QRsQIgb9PDscLHHK45ecgB1uwF
OYw0OJXQiiFrDH/JB6g8
=Kezy
-----END PGP SIGNATURE-----