Re: "tiny" keys for freenet

On Thursday 04 February 2010 15:45:50 Michael Rogers wrote:
> Matthew Toseland wrote:
> >> Your suggestion seems like a great idea to me, but how about this 
> >> modification: instead of HSH@sha1/blahblah, just use
> >> KSK@sha1/blahblah. That way no modifications to the node are
> >> necessary - apps can start using your scheme immediately, with the
> >> app being responsible for checking that the received content hashes
> >> to the expected value, then resubmitting it to the node as a key.
> > 
> > IMHO that would be messy and dangerous, what happens when they insert
> > the wrong content?
> 
> Anyone can insert any content under KSK@sha1/blahblah if that key
> doesn't already exist, but that's detectable (1) by the person
> retrieving the key, because the content won't hash to the expected
> value, and (2) by the person trying to insert the real content, who will
> get a collision. So, finding the key squatted, what does the inserter
> do? Try another key.
> 
> The inserter has a practically unlimited number of attempts to insert a
> KSK that the attacker hasn't already squatted, by inserting redirects to
> the same data (it's not necessary to reinsert the data) and turning the
> keys of the redirects into KSKs. 

It's not unlimited, unless you want each requestor to fetch all the attacker's redirects, and the content they point to, first. That can be limited *to a degree* by implementing enforced checksums at the top block metadata.

> Each KSK is unguessable in advance by 
> the attacker, who can only squat them by seeing the redirect being
> inserted and inserting KSK@sha1/hash_of_the_key_of_the_redirect before
> the inserter does.

Basically it's the classic KSK war, just like with chat, assuming the attacker can guess the content. The attacker inserts once for each slot; everyone fetching it fetches all the slots, multiplying his effort.
> 
> Assuming the inserter's not surrounded by attacker-controlled nodes,
> *eventually* the inserter will learn the key of one of its redirects
> before the attacker does, and be able to insert
> KSK@sha1/hash_of_the_key_of_the_redirect before the attacker does - at
> which point the inserter has a secure and working KSK, and knows it,
> because the KSK insert didn't collide.
> 
> The inserter doesn't have to bother giving any of the squatted KSKs to
> anyone else - the whole process of inserting redirects and checking for
> KSK collisions can be automated.
> 
> > A CHK without a decryption key is possible, but imho not a good idea.
> > And it's not *usably* short - what is the benefit?
> 
> Sorry, I wasn't proposing CHKs without decryption keys, just pointing
> out that using the hash of the data as the KSK keyword isn't quite the
> same as a CHK.
> 
> As for usability: I agree with Alex that 20-30 characters would be more
> usable than current Freenet keys. But the advantage of the
> KSK@sha1/blahblah scheme is that we don't all have to agree about this:
> people who think it's useful can start using it without special support
> from the node.
> 
> Cheers,
> Michael

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

iQIcBAABCAAGBQJLbKKgAAoJEHsvjZi+xPTDrDYP/i2abPtzP9wQ16kW2w4wpipS
PP6azl5VuxqH6FRGVo1T9iPTAuPtRdoI7HoaHQ/VOTOqpskajvrM7FAk0FV/7pF9
gmC9nkgm4TnN6L7mPiWuEHPd/vwBnPgRsSKCDlR4pGbIs8r1NXyouuxZKZvVuXgm
cUnf2PJXgzh1ZqpVEvAVJBRN0uNTIjcjXSU6vuLbNYHMBTYlu5xiIgo5yCQpsSst
m6lPKsGFlBeLJN5/cp6JmuV8E5Nnfv3XXKC6VMpLZxHBnib0o0nz5LMfGIQ65Wgg
k17z4+vVXlXlAgAwqPEZGqVFvH4uEWmbfQitMWTDJPvkme0ah4SGPR9YAJw0iYQ8
jSwFz2CXzhN7FYkTrrspHRR3OqlSZe7REwNM6C02eTg+W9wAYhQwNnuXmiKDOrTn
lDbKFHyDpQ1dXfFACRHKdy10gNUPdG/nldSPlf2J3YAJiHS9yqdIsZ11E4J67NVy
UaSI1dWL26buDkcc9WDcGWWnDhEub6FnQxEqGhIkrb+wIbRQ7Bat9AK4TgUkEMa7
sQemYD2FNQqDsrN5ll8FOlX1A/ZqVThKo+ExpIK+kMkugOzwtNFNgdTL702sTfu0
ylV5/F8eyoPjiBQ48CehbXuCiSTSHEzU1YDRBqF7Cdhg/Cu/3nWSRYjX21aBtJx2
R+2xobK4mGb+PX3nOExa
=HXix
-----END PGP SIGNATURE-----