--- 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. Think of it like this. If some guys has your address and sends you 2 tons of junk mail a day, you'll have trouble reading your mail. If the postal service doubles the cost of postage stamps, he'll still send you 1 ton of junk mail. If the postal service ups the cost by factor 10000, nobody will be able to afford to send you anything anyway. Hey wait, will this work?!? Maybe it's different. ----Route based on the hashcash!!! User caclulates b+c a bit x such that hash(<key,x>) has first b bits 0. There should be about 2^c possibile x's. Route in hashspace to hash(<key,x>) not hash(key). Real numbers: b=10, c=2 In order to use a key I have to do about 2^b=1024 hashes, should happen in a few ms*CPU. There could be about 2^c=4 possible solutions, that's ok, a little redundancy. Since an adversary doesn't know what x is until he caculates it, he can't know where in hashspace a key will wind up until after he has "paid" for it already. Does this work, or am I missing something? Attacks Left: I suppose an adversary with a certain fraction of nodes would probably still be able to use the keys already mapped to a target area to do dammage. An advesary with f nodes compromised would get about f/N *<arverage route hops> of the messages in the system(for f<<N). If he collected all the keys in the target keyspace and requested them all repeatedly from all over the place, it might overload the area of the network responsible. Caching would help some. There's still the SSK attack, but you can fight this with a some caching and a realistic limit on the update rate. If given enough time an adversary could build up enough crap to still do the attack for a short period. The only thing I can think of to fight this is a time dependent hash, or one based on a global random oracle which spits out salt every now and then. Damnit why didn't I think of this before? It beats the crap out of my key sharing stuff I came up with! Please somebody tell me if I'm right about this. __________________________________________________________________ Gesendet von Yahoo! Mail - http://mail.yahoo.de Logos und Klingeltöne fürs Handy bei http://sms.yahoo.de _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
