Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Proof-of-Work Defense for Onion Services

blog.torproject.org

Post reply on HN
Print view View original

61–70 of 159 posts

Re: Proof-of-Work Defense for Onion Services

#61

Post by _blk »

salawat wrote: post #36
8organicbits wrote: post #30

Really 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,…

[flagged]

Re: Proof-of-Work Defense for Onion Services

#62

Post by pseudo0 »

hunter2_ wrote: post #45
cinntaile wrote: post #44

Earlier quoted context omitted.

> Computing is not free. That's the whole point.

What if instead of spending energy on compute, we just spend money instead? On the one hand, some people may be turned off by the idea of spending money, but on the other hand, the two are usually interchangeable unless you're stealing energy. Someone with a lot of money and no hardware or energy can purchase hardware and energy; someone with a lot of hardware and energy can sell the hardware and sell energy back to…

The goal with Tor is to preserve privacy. Payment systems come with significant legal and regulatory overhead, KYC and AML, etc. That introduces significant privacy risk. Meanwhile PoW just requires owning a computing device.

Re: Proof-of-Work Defense for Onion Services

#63

Post by Uptrenda »

I'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 that they're targeting memory as a way to make it more costly for botnets. I think that there are many other ways to help minimize this attack scenario, too. The same logic could also be applied to mobile phones using ESIM. Later authentication with the mobile network uses public key crypto so I feel like you could also do unique proofs there, too.

This is just a throw away comment though. I am probably missing obvious problems with this scheme.

Re: Proof-of-Work Defense for Onion Services

#64

Post by keyle »

8organicbits wrote: post #30

Really 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…

I never heard of CPP (client puzzle protocol) before. Interesting stuff. How can 'large botnets' go around this, by causing havok on other ports?

Re: Proof-of-Work Defense for Onion Services

#65

Post by keyle »

Uptrenda wrote: post #63

I'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…

"Waiting for pair client connection". That'd be something. Interesting thought but I can imagine a range of issues.

In the same vein, how about the server would hold a pool of IPs in which the client has to return a proof of port knocking? e.g. here is a token, send that to this IP:port and wait for a unique response I can verify. Call this proof of latency. It would be low CPU, would spread the load across various machines and ports. On the downside, of course, you need multiple IPs and potentially servers. It could be implemented on the same machine but that would shift the cpu load to port connections.

Re: Proof-of-Work Defense for Onion Services

#66

Post by nsvd »

Uptrenda wrote: post #63

I'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…

Of course, this wouldn't work if you don't trust Intel, AMD, etc's certificate, and I don't see why you would in this application.

Re: Proof-of-Work Defense for Onion Services

#67

Post by foota »

ssklash wrote: post #58
hunter2_ wrote: post #45

Earlier quoted context omitted.

What if instead of spending energy on compute, we just spend money instead? On the one hand, some people may be turned off by the idea of spending money, but on the other hand, the two are usually interchangeable unless you're stealing energy. Someone with a lot of money and no hardware or energy can purchase hardware and energy; someone with a lot of hardware and energy can sell the hardware and sell energy back to…

How do you suggest the people who are using Tor for anonymity pay money to use Tor? That might make sense for cryptocurrencies, but for Tor I think it's unusable.

I believe this could be done using zero knowledge proofs, ala tornado cash (which I'm not familiar with in practice, but I've read the algorithms behind it). You'd need some service that produces zero knowledge proofs that someone sent some funds to the service, and got their slot in return. Put down your pitchfork, but I think this would essentially be an NFT backed by a ZK-snark.

Re: Proof-of-Work Defense for Onion Services

#68

Post by comex »

keyle wrote: post #64
8organicbits wrote: post #30

Really 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…

I never heard of CPP (client puzzle protocol) before. Interesting stuff. How can 'large botnets' go around this, by causing havok on other ports?

Probably by having enough computers that they can overload the server even if the number of requests coming from each individual computer is relatively low, as a multiple of what a normal user would send – low enough that those computers have enough CPU time to solve the challenges.

Re: Proof-of-Work Defense for Onion Services

#69

Post by IngvarLynn »

It'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...

Re: Proof-of-Work Defense for Onion Services

#70

Post by pyinstallwoes »

IngvarLynn wrote: post #69

It'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...

What? Adopting a coin is nonsense. Your argument is also invalid based on the amount of coins that exist, each reinventing POW.
Post reply on HN