> Of course, we need to make sure that the data isn't modified on the way from the client. Why is this necessary if every layer of the onion is a trustable encrypted link?
Counter Galois Onion: Improved encryption for Tor circuit traffic
21–30 of 34 posts
Re: Counter Galois Onion: Improved encryption for Tor circuit traffic
#22> Of course, we need to make sure that the data isn't modified on the way from the client. Why is this necessary if every layer of the onion is a trustable encrypted link?
Relays can be malicious and try to tamper with the data. Think of Tor relay encryption like Signal's E2E encryption, where the relays are analogous to Signal's servers. You want to ensure they can neither see what you sent (confidentiality) nor modify it without detection (integrity).
Re: Counter Galois Onion: Improved encryption for Tor circuit traffic
#23Earlier quoted context omitted.
This FUD comes up whenever Tor is mentioned on Hacker News. The answer is: let's say you think Tor isn't 100% flawless. What are you going to do? Not use Tor? It's better than any other option.
What you'd do is that you'd write a distributed remailer where fixed-size messages are sent on fixed timeslots, possibly with some noise in when it's transmitted, with a message always being sent on its timeslot, even if a dummy message must be sent. I've been writing a system like this in Erlang, intended to be short enough that you can take a picture of the source code and then type it in by hand in a reasonable am…
Re: Counter Galois Onion: Improved encryption for Tor circuit traffic
#24Earlier quoted context omitted.
Relays can be malicious and try to tamper with the data. Think of Tor relay encryption like Signal's E2E encryption, where the relays are analogous to Signal's servers. You want to ensure they can neither see what you sent (confidentiality) nor modify it without detection (integrity).
Yes, but if it's all encrypted tunnels inside encrypted tunnels (recursively), then those relays can't really see the data, right?
Re: Counter Galois Onion: Improved encryption for Tor circuit traffic
#25hey guys, anyone believes Tor still can provide anonymity to users ? just trying to ask politely.
This FUD comes up whenever Tor is mentioned on Hacker News. The answer is: let's say you think Tor isn't 100% flawless. What are you going to do? Not use Tor? It's better than any other option.
If you're trying to browse the web then you won't find many alternatives, but if you're looking to avoid the authorities doing some data exchange, you have options.
Re: Counter Galois Onion: Improved encryption for Tor circuit traffic
#26Earlier quoted context omitted.
broadly yes, but the real question is: what's your threat model? https://ssd.eff.org/glossary/threat-model
I mean definitely state level actor, for example, let's say you can access all data centers in EU as most tor nodes are located in EU.
There is no single state actor that has access to all data centers in the EU, though. For some countries, there's barely a state actor that can access all data centers within a single country.
There is no tool that will let you become immune against a theoretical hyper powerful super government that controls all data centers, just by clicking a button. There never will be.
Re: Counter Galois Onion: Improved encryption for Tor circuit traffic
#27Earlier quoted context omitted.
Yes, but if it's all encrypted tunnels inside encrypted tunnels (recursively), then those relays can't really see the data, right?
That is correct. But, (in general) encryption does not necessarily guarantees integrity of the data. In other words, a plaintext can be encrypted, the ciphertext given to another party, and they can tamper with the ciphertext in a way that produces predictable changes in the message obtained by decrypting the tampered ciphertext.
Re: Counter Galois Onion: Improved encryption for Tor circuit traffic
#28Earlier quoted context omitted.
That is correct. But, (in general) encryption does not necessarily guarantees integrity of the data. In other words, a plaintext can be encrypted, the ciphertext given to another party, and they can tamper with the ciphertext in a way that produces predictable changes in the message obtained by decrypting the tampered ciphertext.
Ok, but if I run (say) HTTPS over the innermost tunnel, then I suppose that HTTPS will take care of any discrepancies.
To reach this point, though, you first need to set up the Tor circuit itself. This is done in a 'telescopic' fashion: the user connects via TLS to the first relay, then sends a message to extend the circuit to a second relay, then to the third (and usually last) relay. Finally, to open Wikipedia, you send a layered encrypted message to the last relay. All this data is link-protected by TLS on the wire, but protected by Tor's relay encryption mechanism while being processed by the nodes.
Re: Counter Galois Onion: Improved encryption for Tor circuit traffic
#29Earlier quoted context omitted.
I mean definitely state level actor, for example, let's say you can access all data centers in EU as most tor nodes are located in EU.
There are countermeasures you can take against timing attacks, pattern analysis, and other capabilities an attacker may have if they control many relays. If you're trying to exfiltrate military secrets to the Russians, you can probably do it, but you'll have to be extremely careful. Your behaviour is as important as the network you use to communicate over, if not more important. There is no single state actor that ha…
Maybe no such techniques could ever apply to the internet, but I'm not sure it's proven impossible. You would need a well defined threat model but if you can show that your enemy is working with noisy data and strictly in the digital space, I don't see why statistical de-anonymization couldn't be foiled.
Re: Counter Galois Onion: Improved encryption for Tor circuit traffic
#30Earlier quoted context omitted.
What you'd do is that you'd write a distributed remailer where fixed-size messages are sent on fixed timeslots, possibly with some noise in when it's transmitted, with a message always being sent on its timeslot, even if a dummy message must be sent. I've been writing a system like this in Erlang, intended to be short enough that you can take a picture of the source code and then type it in by hand in a reasonable am…
You may be interested in Katzenpost and the research behind it: https://katzenpost.network/
I guess my approach is more P2P, more simplicity, shortness and clarity focused, as well as perhaps emphasizing general networking less-- I sacrifice more, I'm fine with 3-6 second delays on all messages, for example. I guess I also emphasize scale in that I intend to have 10,000+ connection open simultaneously on every peer, and because of this you don't even always need the retransmission aspect, since the person you want to talk to might be in the group of 10,000 that you send a message to every second.
So in my thing the mixing is less important and the retransmission aspect is only needed when the network grows so big that you, when you connect don't happen to randomly end up directly peering with the person you want to talk to.