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. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20100204/7cab6315/attachment.pgp>
