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. _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
