4 ms·

Oh, I see - it effectively hides the fact that a conversation occurred between two participants from their servers. They know that I'm at my IP, they know that

by geofft 8y ago

Oh, I see - it effectively hides the fact that a conversation occurred between two participants from their servers. They know that I'm at my IP, they know that you're at your IP, and they know that we're both sending messages, but this feature prevents them from knowing whether we're sending messages to each other.

tptacek 8y ago
Yes. I think there's a subtext here about other messengers, some of which not only log this, but keep it live in a database in order to populate their equivalent of buddy lists.
Spivak 8y ago
It seems like this is backwards: you have an address and username, they have an address and username. They see the source address and destination username. So suppose an attacker sees two packets: Encrypted("Indian for dinner?"): Their username, your address. Encrypted("Sure, sounds good."): Your username, their address. From this they could be reasonably sure you two are talking but it's less data than they had before and now that attacker needs to either know you're using the source address or see both messages to get the full picture.
- tialaramex 8y ago
  What do you mean here by "address" ? And indeed "username" ? Suppose Alice is asking about Indian and Bob replies that it sounds good. A passive attacker sees TCP/IP packets between Alice's IP address and Signal's and between Bob's IP address and Signal's. They get no other information from this beyond that Alice and Bob use Signal (and perhaps not even that if Signal shares IP addresses with other services) The Sealed Sender feature makes no difference in that layer If an attacker has control of Signal's servers (or perhaps Signal's server admins are secretly bad guys) ordinarily they would be able to see the sender and recipient of every message. With Sealed Sender, the servers don't know the Sender any more, only that the Sender seems to be someone permitted to send messages to this recipient. You could try to correlate IP addresses to Signal users, but you have absolutely no guarantee that they're correlated, much less that there's a nice 1:1 correspondence. In a mundane example, Alice proposes Indian food then leaves her office, her phone disconnects from WiFi and goes to a 3G network. The reply from Bob is picked up by Alice using a completely different IP address, because she isn't in the office any more.

by geofft 8y ago

tptacek 8y ago

Yes. I think there's a subtext here about other messengers, some of which not only log this, but keep it live in a database in order to populate their equivalent of buddy lists.

Spivak 8y ago

It seems like this is backwards: you have an address and username, they have an address and username. They see the source address and destination username. So suppose an attacker sees two packets: Encrypted("Indian for dinner?"): Their username, your address. Encrypted("Sure, sounds good."): Your username, their address. From this they could be reasonably sure you two are talking but it's less data than they had before and now that attacker needs to either know you're using the source address or see both messages to get the full picture.

tialaramex 8y ago
What do you mean here by "address" ? And indeed "username" ? Suppose Alice is asking about Indian and Bob replies that it sounds good. A passive attacker sees TCP/IP packets between Alice's IP address and Signal's and between Bob's IP address and Signal's. They get no other information from this beyond that Alice and Bob use Signal (and perhaps not even that if Signal shares IP addresses with other services) The Sealed Sender feature makes no difference in that layer If an attacker has control of Signal's servers (or perhaps Signal's server admins are secretly bad guys) ordinarily they would be able to see the sender and recipient of every message. With Sealed Sender, the servers don't know the Sender any more, only that the Sender seems to be someone permitted to send messages to this recipient. You could try to correlate IP addresses to Signal users, but you have absolutely no guarantee that they're correlated, much less that there's a nice 1:1 correspondence. In a mundane example, Alice proposes Indian food then leaves her office, her phone disconnects from WiFi and goes to a 3G network. The reply from Bob is picked up by Alice using a completely different IP address, because she isn't in the office any more.