4 ms·

> "As far as we can determine, practical privacy preserving contact discovery remains an unsolved problem." This reminds me of an idea I had which I would love

by Shish2k 11y ago

> "As far as we can determine, practical privacy preserving contact discovery remains an unsolved problem." This reminds me of an idea I had which I would love for people to tear apart (I know that the obvious bandwidth problem makes it completely impractical, but I wonder if there are theoretical flaws): Have a central server which everybody connects to. All clients send a constant stream of data, 24/7 - if they don't have anything useful to send, they send /dev/random. When they do have something to send, they send a GPG public-key-encrypted message. Every client then receives the entire stream of data, handles the data which it can decrypt using its private key, and discards the rest. - Your contacts list is a GPG keyring - The server knows nothing - Anyone intercepting your internet traffic can't tell where your packets are destined for - You can't even look at two people's traffic patterns and say "these two people were active at the same time, they must be talking to each other"

cbhl 11y ago
/dev/random has a nonzero chance of emitting a valid GPG public-key-encrypted message. How does the server tell the two apart? How do you make sure that an external watcher can't tell them apart?
codethief 11y ago
You don't even need a central server for that. Just set up a p2p network and have all peers broadcast their messages (¶) to everyone they're connected to. Those peers in turn forward everything they receive to everyone they are connected to and so on. (And, of course, they try to decrypt everything in the meantime to see if any message is meant for them.) (¶) I think you could do without sending random data unless network consists of only two active peers and your adversary taps every single internet link. (As in, even the cable underneath the street in front of your house.) If he doesn't, broadcasting your message to your (physical) neighbors would likely be enough to obfuscate the message's origin. Anyway, the idea of broadcasting / flooding to protect metadata is not new. See, for instance, Bitmessage and Ethereum Whisper. If you ask me, though, (and you mentioned that, too) the traffic and performance issues originating from broadcasting and brute-force decryption make this approach rather impractical to pretty much impossible – at least if you want this to work for the masses. (Even if it's just for text messages, not cat pics or anything.)
- Nutomic 11y ago
  I'm currently working on a decentralized instant messenger Ensichat [1] which does exactly that. Right now, it only works over Bluetooth, but internet support will be coming very soon! [1] https://github.com/Nutomic/ensichat https://github.com/Nutomic/ensichat
- Tiksi 11y ago
  >broadcast their messages (¶) to everyone they're connected to. Those peers in turn forward everything they receive to everyone they are connected to and so on. That sounds like a great way to DDoS everyone using it and every network in between.
  - codethief 11y ago
    Well, there're obviously a lot of things you could improve to lower the chances of a DDoS. (E.g. introducing a TTL / maximum number of hops for a message or forwarding some messages only to some peers, thereby influencing the exact way messages are routed through the network.) But I agree it doesn't look like the most viable idea for a medium for mass communication, not even if it's just for high-latency messages. Yet, people are working on it.

by Shish2k 11y ago

cbhl 11y ago

/dev/random has a nonzero chance of emitting a valid GPG public-key-encrypted message. How does the server tell the two apart? How do you make sure that an external watcher can't tell them apart?

codethief 11y ago

You don't even need a central server for that. Just set up a p2p network and have all peers broadcast their messages (¶) to everyone they're connected to. Those peers in turn forward everything they receive to everyone they are connected to and so on. (And, of course, they try to decrypt everything in the meantime to see if any message is meant for them.) (¶) I think you could do without sending random data unless network consists of only two active peers and your adversary taps every single internet link. (As in, even the cable underneath the street in front of your house.) If he doesn't, broadcasting your message to your (physical) neighbors would likely be enough to obfuscate the message's origin. Anyway, the idea of broadcasting / flooding to protect metadata is not new. See, for instance, Bitmessage and Ethereum Whisper. If you ask me, though, (and you mentioned that, too) the traffic and performance issues originating from broadcasting and brute-force decryption make this approach rather impractical to pretty much impossible – at least if you want this to work for the masses. (Even if it's just for text messages, not cat pics or anything.)

Nutomic 11y ago
I'm currently working on a decentralized instant messenger Ensichat [1] which does exactly that. Right now, it only works over Bluetooth, but internet support will be coming very soon! [1] https://github.com/Nutomic/ensichat https://github.com/Nutomic/ensichat
Tiksi 11y ago
>broadcast their messages (¶) to everyone they're connected to. Those peers in turn forward everything they receive to everyone they are connected to and so on. That sounds like a great way to DDoS everyone using it and every network in between.
- codethief 11y ago
  Well, there're obviously a lot of things you could improve to lower the chances of a DDoS. (E.g. introducing a TTL / maximum number of hops for a message or forwarding some messages only to some peers, thereby influencing the exact way messages are routed through the network.) But I agree it doesn't look like the most viable idea for a medium for mass communication, not even if it's just for high-latency messages. Yet, people are working on it.