This has been suggested before, for email spam. Cloudflare could do this, too. Every time you access a busy site, seconds to minutes of useless crunching. The overall effect would be to drain batteries worldwide.
Proof-of-Work Defense for Onion Services
21–30 of 159 posts
Re: Proof-of-Work Defense for Onion Services
#22What's preventing abusers from getting new identities when the PoW kicks in and continuing the DDoS? Edit: looks like PoW is set per "service" that's under attack rather than client?
Re: Proof-of-Work Defense for Onion Services
#23Re: Proof-of-Work Defense for Onion Services
#24This has been suggested before, for email spam. Cloudflare could do this, too. Every time you access a busy site, seconds to minutes of useless crunching. The overall effect would be to drain batteries worldwide.
The suggestion for PoW for email bonds was called Hashcash, by Adam Back, and involved partial hash collisions. http://www.hashcash.org/ It served as the inspiration for Bitcoin's PoW mining, interestingly enough.
Re: Proof-of-Work Defense for Onion Services
#25Also, since it is DDOSing, the server’s work is embarrassingly parallel, but the client work isn’t necessarily parallelized at all.
Even if it is only a factor of 6 (or one) they are talking about 1 minute solve times once a DDOS is detected.
At that point the service is basically down anyway, right?
Re: Proof-of-Work Defense for Onion Services
#26Hold on you just made DoS more expensive, but a hell of alot more effective. If I need a RTX4090 to access your site now, the attacker has succeeded.
There are PoW algorithms specifically developed to resist GPU and ASIC. Typically they do this by being memory intensive instead of (or in addition to) being compute intensive.
The article says they target 1 minute solve times under load. If that’s 1 minute on a 5GHz, 64 core machine with 512GB ram, an A100 and an FPGA, then it’s going to be at least 5-15 minutes on your phone.
Also, the server farm can parallelize work across an arbitrary number of challenges, but legitimate users cannot.
Re: Proof-of-Work Defense for Onion Services
#27Re: Proof-of-Work Defense for Onion Services
#28Earlier quoted context omitted.
I think difficulty also kind-of scales per-user, due to the queue mechanism.
Do those queues have a way of resisting a Sybil attack?
Re: Proof-of-Work Defense for Onion Services
#29The current proposal discussed in the post talks about "prioritize verified network traffic". It would be interesting if sharing "file pieces" could prioritize your traffic since you're actually helping the network. Instead of "proof-of-work" it would be "proof-of-bandwidth-contribution".
Re: Proof-of-Work Defense for Onion Services
#30> make it harder for attackers to overload the service with introduction request
> We hope that this proposal can help us defend against the script-kiddie attacker and small botnets.
Sets expectations: does not counter large botnets.
> We hope that this proposal will allow the motivated user to always connect
A user who really wants to connect can get through durring a DoS attack, but it may still take work.
Interesting choice of PoW algorithm: https://github.com/tevador/equix
> Hence, instead of forcing clients to go below a static target like in Bitcoin to be successful, we ask clients to "bid" using their PoW effort. Effectively, a client gets higher priority the higher effort they put into their proof-of-work. This is similar to how proof-of-stake works but instead of staking coins, you stake work.
[1] https://gitlab.torproject.org/tpo/core/torspec/-/raw/main/pr...