On Wed, Feb 3, 2010 at 11:11 AM, alex <alejandro at mosteo.com> 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.
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 at abcedfg... It then takes the first n characters of the hash in the CHK (say n=4, so "abcd") and tries fetching KSK at 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
