Re: "tiny" keys for freenet

On Thu, Feb 4, 2010 at 9:49 AM, Matthew Toseland
<toad-EI5O+8PHWbJeeLb3ft/[email protected]> wrote:
> 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.

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