Re: "tiny" keys for freenet

On Wednesday 03 February 2010 16:42:32 Evan Daniel wrote:
> On Wed, Feb 3, 2010 at 11:11 AM, alex <[email protected]> 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.
> 
> It's an interesting idea.  However, I don't think keys that are only
> somewhat shorter than a CHK are all that useful.
> 
> Here's an idea I've had floating around for a little while, but
> haven't had the time to implement; if someone else wanted to, I'd be
> delighted.
> 
> We need a URL shortening plugin.  It works like this.  You give it a
> CHK (or SSK / USK, though that would require some changes), say
> CHK@abcedfg... It then takes the first n characters of the hash in the
> CHK (say n=4, so "abcd") and tries fetching KSK@abcd.  If that isn't
> found, it inserts it as a redirect to the CHK.  If it is found and is
> something else, it tries again with n=5, until it eventually finds a
> free KSK to use.  (I suppose it might be unable to if someone decided
> to run a really inefficient DoS against the possible redirects for a
> specific CHK.)
> 
> This has a number of advantages: no new key types, short URLs that,
> while not completely secure, have some amount of durability
> (especially if the creator reinserts the redirect a few times with
> intervals between), and only the person creating the short URL needs
> the plugin.
> 
> (To create redirects to USKs or SSKs we need some node changes.  Also,
> there isn't a hash provided as with CHKs, so redirects to different
> sites under the same SSK keypair are less obvious.  It probably needs
> to take the hash of the whole key, including both the crypto and
> docname portion of the SSK.)
> 
> Evan Daniel

How about we just use KSKs?

AFAICS what is needed to use KSKs:
- Acceptance of a certain level of risk that it might not be the same document.
- Minimising that risk somehow (e.g. by random routed requests fetching it from multiple places).
- Preventing spam on KSKs, or ignoring it.
- Ability to redirect from KSKs to USKs or CHKs.

The third item is the hardest, of course... Scarce KSKs were proposed some time ago ... but right now KSKs are not generally being spammed.

_______________________________________________
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)

iQIcBAABCAAGBQJLat5dAAoJEHsvjZi+xPTDSYsP/jft83hbhIYJwL0ZRornbBTh
ScrzX6ES7HWKBV/nmM8EU6AUIpbc0svVWF4Wthd7nQVlSN2ECS5KBvq6NhJ+tY9I
jnMikSw/chB9wx0VbuWITMHxAyuMatoCrXlrq4QEMbbXDWUN73OqvXeNH2ocvb76
CbttR1En5Ynm5aKHYEqVrnovfhpC4FGmySPCAmRNiCS9V64GBjW3cl4KLkQ6tIHF
KEIcY3eeaBGbZEB28TLV7lAmuFHq6lV87PV6r7G/F6yZpiBu6p0gOuTkD+1XLCLO
iuv1HsKZY3WvHxRlU0k26H2WSEIN5QjS64lr78lAFklTtJjIKSFtCNerAfFbns73
7/BjQ/hmNLMMakXv67Zut+xWr7ytu+qw6q/19lScCrz/+r7hJ/biY3HSYd7QmdxM
9Z8PYL7r0syRrdit5pN88iI11m07i+G5Dayxash4G1fjBVN3/lJtejr3JUXXq0Ia
soozHGWWO4ifkPot3J6HYW0KUkU8DA2aRhz5qQWxAPMsnAFyBHbxtPdOHyt9ywBu
6fz7iOBmw2zpGX8yZoNmbVOqUD7sTiW/2a+/BzbLtyS7Jq5OE24BftNi1m8NNomM
BDw6KaBeR8i11ZlqV42Q2s/dGNw+4EK9OUCmk1z66Efg9qTGhtVH3XPA7XkVeghd
uECiWhQTsa/iaJfBGJX5
=Qo2l
-----END PGP SIGNATURE-----