3 ms·

I'm not sure I understand the feature. It protects the sender's identity from their servers, or from the recipient? What's the use case / threat model? I think

by geofft 8y ago

I'm not sure I understand the feature. It protects the sender's identity from their servers, or from the recipient? What's the use case / threat model? I think it prevents their servers from correlating my identity and my IP address etc., but since I want replies and I'm asking the server about replies, doesn't that operation tell the server what my identity is anyway? (There are some comments here talking about anonymous messages, but that doesn't sound right since the phone number is apparently kept in the encrypted, inner envelope, and also how would you route replies if you didn't have an identity of some sort for the sender?)

9034725985 8y ago
I think their servers. (This is my imagination and it might be completely wrong so please feel free to correct me) they mentioned spam problem which leads me to believe that if enabled, the sending client will encrypt the whole message using the recipient's public key and put all metadata other than recipient's identifier inside this bigger encrypted envelope. The receiver opens this envelope with its key and opens the smaller box inside which contains the sender's metadata. What we lose now with this is the server does not have much insight into who is sending messages (by design). This means if you allow sealed sender from everyone, someone could send you a lot of messages which you may not like.
tptacek 8y ago
It prevents their servers from easily tracking (and, importantly, logging) who sent which messages to whom.
- 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.
- eadmund 8y ago
  I don't think that's actually true. Reading their blog entry at https://signal.org/blog/sealed-sender/ https://signal.org/blog/sealed-sender/, I believe that they can still correlate IP addresses to phone numbers, and since they see which IP address sent a message and to which IP address it was delivered, they know who's talking to whom (or can know, and can be compelled to know, record & share). It's also odd that the tokens are 96 bits. Very odd, really.
megablast 8y ago
Why would you want to protect the identity from the recipient? Unless you wanted to enable spam.
ric2b 8y ago
It makes their database of undelivered messages even more useless. Yes, their servers can see your IP but if they discard it immediately you're safer if the NSA or another government agency reaches out to them.

by geofft 8y ago

9034725985 8y ago

I think their servers. (This is my imagination and it might be completely wrong so please feel free to correct me) they mentioned spam problem which leads me to believe that if enabled, the sending client will encrypt the whole message using the recipient's public key and put all metadata other than recipient's identifier inside this bigger encrypted envelope. The receiver opens this envelope with its key and opens the smaller box inside which contains the sender's metadata. What we lose now with this is the server does not have much insight into who is sending messages (by design). This means if you allow sealed sender from everyone, someone could send you a lot of messages which you may not like.

tptacek 8y ago

It prevents their servers from easily tracking (and, importantly, logging) who sent which messages to whom.

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.
eadmund 8y ago
I don't think that's actually true. Reading their blog entry at https://signal.org/blog/sealed-sender/ https://signal.org/blog/sealed-sender/, I believe that they can still correlate IP addresses to phone numbers, and since they see which IP address sent a message and to which IP address it was delivered, they know who's talking to whom (or can know, and can be compelled to know, record & share). It's also odd that the tokens are 96 bits. Very odd, really.

megablast 8y ago

Why would you want to protect the identity from the recipient? Unless you wanted to enable spam.

ric2b 8y ago

It makes their database of undelivered messages even more useless. Yes, their servers can see your IP but if they discard it immediately you're safer if the NSA or another government agency reaches out to them.