On Thu, Oct 30, 2003 at 11:38:25AM +0100, Some Guy wrote: > --- Tom Kaitchuck <[EMAIL PROTECTED]> wrote: > > On Wednesday 29 October 2003 07:39 pm, Toad wrote: > > > On Wed, Oct 29, 2003 at 07:34:08PM -0600, Tom Kaitchuck wrote: > > > > On Wednesday 29 October 2003 05:48 pm, Toad wrote: > > > > > On Wed, Oct 29, 2003 at 04:56:05PM -0600, Tom Kaitchuck wrote: > > > > > > WAIT. I've got it! Add another level of hashing. So the content is > > > > > > encrypted with it's hash, and it is stored in the hash of the hash of > > > > > > the hash, and attached to the request is the hash of the hash. This > > > > > > way they the attack is impossible to target. They would have to go > > > > > > through hashing values until they found ones that falls in the aria > > > > > > they are trying to attack. To make this more CPU intensive we could > > > > > > use a different hash algorithm, one with enough bit depth that trying > > > > > > to create even a limited lookup table based on it would be very > > > > > > impractical. This would break network compatability and require total > > > > > > datastore reset, so lets throughly discuss this and/or other > > > > > > solutions before implementing it. > > > > > > > > > > It's a nice idea but they could easily brute force the first few bytes. > > > > > > > > Is there some way to make a hash like function that is trivial to verify, > > > > but hard to generate? Maybe something like: index under the 3rd hash and > > > > include the second hash as well as the next greater value who's last X > > > > bits match the last X bits of the third hash. ( then set some bound of > > > > how close that number has to be to the original hash.) Anyone have a > > > > better algorithm? > > > > > > Yeah, it's called hash cash - but it'd slow down requests... > > > > > > > Anyways then to brute force 2 bytes it would take nearly 2^16th times as > > > > long as whatever is deemed an acceptable delay on a normal computer. > > > > Why would this particularly slow down requests? You could just as easily > > include the number values in the link to the content. Then the intermediate > > nodes only have to do two hashes of ints and a comparison. Wouldn't this take > > much less time than to verify the file when it comes back. If that really > > slows things down it could be done say only at nodes where HTL%3==1 or > > something like that. (Then it will still be caught before it gets too far). > > It would certainly slow down inserts but I see no problem with that. > > Look, with "hash cash" you can charge the initiator of a request/insert/ect some > average CPU time. > That's all well and a few jerks from overusing the system, but it only scales down > the attack > someone can do to targeted area in hashspace.
I think Tom's idea was to make the creator of a URL do the expensive calculation, perhaps while waiting for the insert to work. Hence: CHK@<hashcash/routing key>,<hash of encrypted content>,<decrypt key> Where <routing key> is derived from <hash of encrypted content> by some operation, say a large number of operations of a secure hash. This could be a nice idea, the only problem is extending it to SSKs: SSK@<pubkey hash>,<encryption entropy>,<hashcash>/<filename> Where <routing key> is derived from the others, and applies to the manifest file. The problem here is that the routing key cannot be derived from the filename, as we want the filename to vary within the SSK 'directory' - even if we use mapfiles, DBRs require SSK@<FIXED>/<changing string> One possibility would be for the hashcash to be derived once only for the SSK - but then we lose any security this gains us against flooders. I don't think that hashcash in the URL is compatible with subspace keys, sorry Tom. A further problem is that you need to be able to increase the required amount of hashcash over time, as machines become able to do more hashcash - this is NOT good for URLs! -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so.
signature.asc
Description: Digital signature
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
