Hi,
Given the significant environmental impact of POW in other distributed systems (blockchain), we should not implement schemes that solve a problem for Tor but create problems for people elsewhere (potentially irreversible environmental damage).
https://www.theguardian.com/technology/2018/nov/05/energy-cost-of-mining-bit...
Other less-destructive schemes exist to prevent DoS attacks. POW is a method, not a goal in itself. Taking a step back and examining the full spectrum of available tools would be better.
Chelsea
On 2019-06-13 06:21, George Kadianakis wrote:
juanjo juanjo@avanix.es writes:
Hello, this is my view of things, please be gentle as this is my first proposal draft :)
Hello,
thanks for working on this. IMO any proof-of-work introduction proposal can be seen as orthogonal to David's prop305 which is a rate-limiting proposal (even tho it's not named as such) and hence deserves its own thread.
_ADAPTIVE POW PROPOSAL:_
Client sends the INTRODUCE1 as normal.
Introduction Point checks the Current Requests Rate and checks the DoS settings.
-DoS check is OK: send INTRODUCE2 to Hidden Service etc...
So far so good (even tho this is not our usual proposal format).
-DoS settings/rate limit reached: then
1.Introduction Point generates a random 8 bytes key (IPKey) and associates it with the client circuit. Then send INTRODUCE_POW to the Client with the IPKey.
Is this a new cell? What's the format? Are these really keys or are they just nonces?
IMO we should not do this through a new cell because that increases the round-trip by one. Instead we should just embed the PoW parameters in the onion service descriptor and clients find them there.
2.Client computes POW. Do{ Generates random 8 bytes key (ClientKey). Generates hash(sha512/256 or sha3??) of hash(IPKey + ClientKey) } while (hash does not start with "abcde")
That looks like a naive PoW scheme. It would perhaps be preferable to try to find a GPU/ASIC-resistant or memory-hard PoW scheme here, to minimize the advantage of adversaries with GPUs etc.? Are there any good such schemes?
Also services should definitely be able to configure the difficulty of the PoW, and IMO this should again happen through the descriptor.
3. Client sends INTRODUCE_POWR to the I.P. with the generated POW and the ClientKey.
IMO this should happen as part of the INTRODUCE1 cell.
4. I.P. checks the POW:
-POW is correct: send INTRODUCE2 to HS. -POW is not correct: send INTRODUCE_POW_ERROR to client with new IPKey.
*I say 8 bytes for the Keys just for example.
PROS AND CONS, who needs to update Tor version?:
Only rate limit: Introduction Point and Hidden Service. No breakage.
POW: Client, Introduction Point and Hidden Service. POW will break compatibility with other v3 Hidden Services clients, if we implement a way to bypass POW for old clients then this feature won't work as intended.
A forgotten guy here: Authenticated Rends cell: where we make sure the Client established a connection to the Rend Point before requesting the INTRODUCE1.
Yep, that's yet another proposal (ticket #25066). _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev