4 ms·

> # Goals of Berty > Be resilient against mass surveillance by minimizing metadata leakage While that's an admirable goal, it's also a really difficult-to-sol

> # Goals of Berty > Be resilient against mass surveillance by minimizing metadata leakage While that's an admirable goal, it's also a really difficult-to-solve problem in the context of P2P, so simply mentioning a goal says nothing about the actual state of security of Berty or about whether it's achievable in the first place. By default (i.e. without any countermeasures like onion routing), a p2p network will expose more metadata to the 3-letter agencies than a centralized app with Sealed Sender[0] like Signal. The people at GNUnet have spent more several man decades trying to solve this issue and last time I checked they were still not happy with their solution. [0]: https://signal.org/blog/sealed-sender/ https://signal.org/blog/sealed-sender/

upofadown 4y ago
>Sealed Sender I have never understood how that works in practice. The server knows the IP addresses (and source ports) of where they are sending and receiving things. How can the server not know who is talking to who? Also, Signal Messenger Protocol requires a server to store and forward prekeys. Why can't that server just record who shows up to pick up who's prekeys?
- ementally 4y ago
  https://www.ndss-symposium.org/ndss-paper/improving-signals-sealed-sender/ https://www.ndss-symposium.org/ndss-paper/improving-signals-... explains it
all2 4y ago
Is there not a "One ticket West" algorithm for distributed networks? The message would arrive at a server and tell the server "I'm going this way." and the server forwards the message in a direction rather on a specific path to some destination. I'm not sure how one would apply the concept of "direction" to a communications graph. Also some means of discerning arrival would need to be provided for.
- codethief 4y ago
  What if that server were under the control of the NSA? In any case, your description > The message would arrive at a server and tell the server "I'm going this way." and the server forwards the message in a direction rather on a specific path to some destination. pretty much matches the idea of the IP protocol built on top of point-to-point connections. The problem is that you still need to specify a direction and that helps an attacker identify and track messages from sender to receiver. Look at it from a different angle: The most extreme version of a "one ticket west" algorithm would be one where your message would get broadcast to (or eventually pass by) all participants of the network and all of them would check whether the message is meant for them (e.g. by trying to decrypt it). Needless to say, this doesn't scale well at all, especially not for sending anything bigger than pure text. OTOH this is certainly the broadest sense of direction one could possibly think of and there would be no possible way for Eve to discern to whom Alice is sending her message. Contrast this with direct 1-to-1 connections between Alice and Bob. Any eavesdropper would immediately see Alice's and Bob's IP address. Now in between these two extremes lie "semi-direct" messages where the path that the message takes is – at the word says – not direct but instead gets obfuscated by some algorithm. (Your idea being one version of that.) Unfortunately, coming up with a good algorithm is anything but simple and the danger is that a nation state actor with sufficient power would still be able to "hack" the algorithm and undo the obfuscation. This is precisely what the people at Tor and GNUnet are concerned with.
sliken 4y ago
I've pondered p2p apps that are secure from traffic analysis, sniffing, and leaking metadata. Chat being the easiest. Chat is low bandwidth and tolerates latencies well, much more so than audio or video streaming. Tor has a much harder job, it's trying to handle full TCP communications, low latency, variable packet sizes, efficiency (no fake traffic), and high bandwidth all compound to make it very challenging. However you can make the challenge much simpler. First nix TCP, variable packet sizes, and low latency. Pick a packet size like 256 bytes, send packets every 300 ms, and use any spare traffic to maintain the health of a DHT. Then clients would use the same onion approach, decide the number of hops, and encrypt for those hops like an onion. So each node would receive messages, decrypt it, if it's a DHT update handle that, if they are the intended recipient decrypt, if it's a forward request decrypt it and queue it for sending on the next free 300ms boundary. Suddenly it's much harder to track traffic through the network, even with perfect knowledge of each packet's source and destination. Timing attacks don't work because everyone sends 256 bytes ever 300ms. Using packet size to watch traffic go through relays doesn't work. So much less useful than Tor, but also more resistant to traffic analysis, and plenty of bandwidth for chat.

upofadown 4y ago

>Sealed Sender I have never understood how that works in practice. The server knows the IP addresses (and source ports) of where they are sending and receiving things. How can the server not know who is talking to who? Also, Signal Messenger Protocol requires a server to store and forward prekeys. Why can't that server just record who shows up to pick up who's prekeys?

ementally 4y ago
https://www.ndss-symposium.org/ndss-paper/improving-signals-sealed-sender/ https://www.ndss-symposium.org/ndss-paper/improving-signals-... explains it

all2 4y ago

Is there not a "One ticket West" algorithm for distributed networks? The message would arrive at a server and tell the server "I'm going this way." and the server forwards the message in a direction rather on a specific path to some destination. I'm not sure how one would apply the concept of "direction" to a communications graph. Also some means of discerning arrival would need to be provided for.

codethief 4y ago
What if that server were under the control of the NSA? In any case, your description > The message would arrive at a server and tell the server "I'm going this way." and the server forwards the message in a direction rather on a specific path to some destination. pretty much matches the idea of the IP protocol built on top of point-to-point connections. The problem is that you still need to specify a direction and that helps an attacker identify and track messages from sender to receiver. Look at it from a different angle: The most extreme version of a "one ticket west" algorithm would be one where your message would get broadcast to (or eventually pass by) all participants of the network and all of them would check whether the message is meant for them (e.g. by trying to decrypt it). Needless to say, this doesn't scale well at all, especially not for sending anything bigger than pure text. OTOH this is certainly the broadest sense of direction one could possibly think of and there would be no possible way for Eve to discern to whom Alice is sending her message. Contrast this with direct 1-to-1 connections between Alice and Bob. Any eavesdropper would immediately see Alice's and Bob's IP address. Now in between these two extremes lie "semi-direct" messages where the path that the message takes is – at the word says – not direct but instead gets obfuscated by some algorithm. (Your idea being one version of that.) Unfortunately, coming up with a good algorithm is anything but simple and the danger is that a nation state actor with sufficient power would still be able to "hack" the algorithm and undo the obfuscation. This is precisely what the people at Tor and GNUnet are concerned with.

sliken 4y ago

I've pondered p2p apps that are secure from traffic analysis, sniffing, and leaking metadata. Chat being the easiest. Chat is low bandwidth and tolerates latencies well, much more so than audio or video streaming. Tor has a much harder job, it's trying to handle full TCP communications, low latency, variable packet sizes, efficiency (no fake traffic), and high bandwidth all compound to make it very challenging. However you can make the challenge much simpler. First nix TCP, variable packet sizes, and low latency. Pick a packet size like 256 bytes, send packets every 300 ms, and use any spare traffic to maintain the health of a DHT. Then clients would use the same onion approach, decide the number of hops, and encrypt for those hops like an onion. So each node would receive messages, decrypt it, if it's a DHT update handle that, if they are the intended recipient decrypt, if it's a forward request decrypt it and queue it for sending on the next free 300ms boundary. Suddenly it's much harder to track traffic through the network, even with perfect knowledge of each packet's source and destination. Timing attacks don't work because everyone sends 256 bytes ever 300ms. Using packet size to watch traffic go through relays doesn't work. So much less useful than Tor, but also more resistant to traffic analysis, and plenty of bandwidth for chat.