On Thu, Feb 4, 2010 at 9:49 AM, Matthew Toseland <toad at amphibian.dyndns.org> wrote: > On Wednesday 03 February 2010 16:42:32 Evan Daniel wrote: >> 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 > > 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.
That's basically what I was proposing: an automated way to create short KSKs, that doesn't require the user to manually check for the KSK being in use, etc. I mean, people could just use shorter, readable, manually created URLs, but URL shorteners are quite popular. The plugin could also handle the automated stuff like random routed fetches / multiple inserts to improve durability. I'm not suggesting anything new at the Freenet level (aside from KSK -> USK redirects), but rather a convenient UI. Evan Daniel
