George Kadianakis <desnac...@riseup.net> writes: > George Kadianakis <desnac...@riseup.net> writes: > >> juanjo <jua...@avanix.es> writes: >> >>> Ok, thanks, I was actually thinking about PoW on the Introduction Point >>> itself, but it would need to add a round trip, like some sort of >>> "authentication based PoW" before allowing to send the INTRODUCE1 cell. >>> At least it would make the overhead of clients higher than I.P. as the >>> clients would need to compute the PoW function and the I.P. only to >>> verify it. So if right now the cost of the attack is "low" we can add an >>> overhead of +10 to the client and only +2 to the I.P. (for example) and >>> the hidden service doesn't need to do anything. >>> >> >> Also see the idea in (b) (1) here: >> https://lists.torproject.org/pipermail/tor-dev/2019-April/013790.html >> and how it couples with the "rendezvous approver" from ticket #16059. >> Given a generic system there, adding proof-of-work is a possibility. >> >> Another option would be to add the proof-of-work in the public parts of >> INTRO1 and have the introduction point verify it which is not covered in >> our email above. >> >> Proof-of-work systems could be something to consider, altho tweaking a >> proof-of-work system that would deny attackers and still allow normal >> clients to visit it (without e.g. burning the battery of mobile clients) >> is an open problem AFAIK. >> >> > > Here is how this could work after a discussion with dgoulet and arma on IRC: > > 1) Service enables DoS protection in its torrc. > > 2) Service uploads descriptor with PoW parameters. > > 3) Service sends special flag in its ESTABLISH_INTRO to its intro points > that says "Enable PoW defences". > > 4) Clients fetch descriptor, parse the PoW parameters and now need to > complete PoW before they send a valid INTRO1 cell, otherwise it gets > dropped by the intro point. > > All the above seems like they could work for some use cases. > > As said above, I doubt there are parameters that would help against DoS > and still allow people to pleasantly visit such onion services through > an uncharged mobile phone, but this choice is up to the onion > service. The onion service can turn this feature on when they want, and > disable it when they want. And mobile clients could also disallow visits > to such sites to avoid battery/CPU burns. > > All the above seems likely, but it's significant work. We first need a > proposal to discuss, and then there is lots of code to be written... >
FWIW, thinking about this more, I think it's quite unlikely that we will find a non-interactive PoW system here (like hashcash) whose parameters would allow a legit client to compute a PoW in a reasonable time frame, and still disallow a motivated attacker with GPUs to compute hundreds/thousands of them in a single second (which can be enough to DoS a service). We should look into parameters and tuning non-interactive PoW systems, or we could look into interactive proof-of-work systems like CAPTCHAs (or something else), which would be additional work but might suit as more. _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
