Opened 7 years ago

Closed 7 years ago

#883 closed enhancement (not a bug)

Bad floodfill protection

Reported by: DISABLED Owned by: zzz
Priority: major Milestone:
Component: router/netdb Version: 0.9.4
Keywords: FF UCSB DHT Cc:
Parent Tickets: Sensitive: no

Description

<AndChat134400> Hey
<AndChat134400> I have an idea to protect from hostile floodfills
<AndChat134400> Instead of using ddmmyyyy in the hash for the floodfill dht
<AndChat134400> Use a random few bytes agreed by all the floodfills at 11.30
<AndChat134400> And require floodfills to be know for 24 hours before they are trusted
<AndChat134400> Then its impossible to get into a specific place in the dht for an eclipse attack before all the nodes move again
<AndChat134400> Im not an expert on key exchange or anything but surely theres a way for ~500 nodes to agree on a nonce?
<eche|on> AndChat134400: please add to post on zzz.i2p
<eche|on> AndChat134400: usual there is a problem for 500+ nodes to agree on a nonce in a "secure"
<eche|on> way…

I have no account on zzz.i2p, i only hope this will do.

At around 11.30 each floodfill sends to all the others a few bytes from /dev/random. Each floodfill then SHA's all of the floodfill's random bytes, and then XOR's the whole lot. This way there is a nonce that is refreshed evey day, and not predicatable. As long as at least one node is not bad, the SHA outcome will be random, and thus the final XOR will be random. Floodfill should have been up since before the allocated time to be trusted. This means that they will not be able to move to follow the victim. FF DHT id's cannot be precalculated ahed of time. Any router whose DHT id is not SHA(dest+nonce) is not trusted.

Subtickets

Change History (1)

comment:1 Changed 7 years ago by zzz

Resolution: not a bug
Status: newclosed

An interesting idea, but:

  • Backward-incompatible
  • There's no master list of all the floodfills, so no way for everybody to get the same result unless somebody is in charge
  • The alternative, a centralized authority that generates the key for the day, is failure prone… the alternative to that, a group of trusted authorities that generates a consensus, is what Tor does
  • None of this prevents the attacker from generating hashes from 11:30 to midnight, that's plenty of time with a reasonable amount of computing power
  • Where and how do routers starting after midnight get the nonce-of-the-day?

Followups and discussion best done on IRC or some forum. An account on zzz.i2p takes about 30 seconds to create.

Note: See TracTickets for help on using tickets.