And is that the kind of hardware that the users in regimes that TOR is supposed to help have?
Proof-of-Work Defense for Onion Services
101–110 of 159 posts
Re: Proof-of-Work Defense for Onion Services
#102I'm wondering if there is a more elegant way to solve sybil attacks here. For example: many CPUs are provisioned with key pairs that are unique to the processor and can be verified with the CA root cert of the issuer (Intel, AMD, etc.) You could tie PoW to successive signing and allow it to be verified in parallel. Then the operation couldn't be parallelized to a botnet as all PoWs would be unique to a CPU. It seems…
Re: Proof-of-Work Defense for Onion Services
#103Re: Proof-of-Work Defense for Onion Services
#104Really interesting! Digging into the proposal [1]: > 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…
So now you have the drawbacks of both as well, in that the guy who has the most compute to use as a toaster can DoS everyone else. Plus, PoW is nothing but wasted, needless computation . Computing is not free . Every watt spent doing anything PoW is just that much more intensification of our current climate crisis. As someone with temps of 109 with heat index of 120 coming in the next few days, with all due respect,…
Re: Proof-of-Work Defense for Onion Services
#105Really interesting! Digging into the proposal [1]: > 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…
So now you have the drawbacks of both as well, in that the guy who has the most compute to use as a toaster can DoS everyone else. Plus, PoW is nothing but wasted, needless computation . Computing is not free . Every watt spent doing anything PoW is just that much more intensification of our current climate crisis. As someone with temps of 109 with heat index of 120 coming in the next few days, with all due respect,…
Sorry it's hot there but this is absurd virtue signaling and should under no circumstance come into view as a reason to not do PoW.
Re: Proof-of-Work Defense for Onion Services
#106Surely the DDossers will just use some of their botnets for generating the POWs? I don't think I fully understand the scheme. Is the idea that as the attack progressed this would consume more and more of their resources making an attack impractical? Surely in that scenario more and more of the real traffic's resources would be consumed by them having to solve puzzles also, so Tor would in effect be cooperating with t…
Re: Proof-of-Work Defense for Onion Services
#107It's a shame that Torproject has decided to reinvent its own wheel, lagging 10 years behind the crypto crowd, instead of integrating with existing coin(s). The problem is, such integration would require the chosen coin to be anonymous, which is essentially forbidden: https://www.theverge.com/2023/8/23/23843161/tornado-cash-ind...
I agree with you in principle. Wasting energy like what this and hashcash do is unfortunate but that's what happens when you have an irrational hate towards a technology rather than how it is used. That said, modeling it after a general cryptocurrency is probably a bad idea since it rising prices may prevent legitimate clients from being able to connect to onion services due to the challenge being too expensive (eith…
Not modelling after but integrating of an existing one. Because this saves massive amount of engineering effort.
>rising prices may prevent legitimate clients from being able to connect to onion services due to the challenge being too expensive
Obviously, the price for legitimate clients would be much cheaper, as their requests shall be placed in the middle of priority queue (clients can wait a few seconds) while the attacker have to occupy the very top of this queue all the time. Also note that the bigger the DDoS in this scheme - the bigger profits server could make, which he could spend on expanding capacity.
>each visitor contribute to a partial solution that can then be combined to derive funds
This scheme predates monero, which was about 10 years ago.
>the next generation learns from our senseless technology-burnings.
Not if they would reinvent the wheel each time instead of adapting of existing tech to current needs.
Re: Proof-of-Work Defense for Onion Services
#108Surely the DDossers will just use some of their botnets for generating the POWs? I don't think I fully understand the scheme. Is the idea that as the attack progressed this would consume more and more of their resources making an attack impractical? Surely in that scenario more and more of the real traffic's resources would be consumed by them having to solve puzzles also, so Tor would in effect be cooperating with t…
Re: Proof-of-Work Defense for Onion Services
#109Earlier quoted context omitted.
real users have more CPU than a literal toaster (or smart air fryer, or IP camera, or many other common botnet devices)
Not only that, real users actually want to use the service, not overload it. A real user might only make one request a second. A botnet device is trying to make a thousand requests per second to overload the server. Even if they each have the same CPU as a normal user, now each node in the botnet can only make as many requests per second as a user or the user can outbid them.
Re: Proof-of-Work Defense for Onion Services
#110I'm surprised something like this wasn't done sooner, and also haven't read the proposal [0] in enough detail to tell if this will lead to more data affecting the anonymity of users. Should be fine though, since it's tied user-to-service and not stored anywhere. I'm wondering how much this will decrease load on the service being proxied vs the nodes themselves though, I assume it'll have more benefit to services sinc…
It should have been, but was delayed by people shrieking about oceans boiling.