It would be much simpler if Signal adopted something like RFC 9420 (Messaging Layer Security), but MLS doesn’t provide the metadata resistance that Signal prioritized.
I wonder what metadata resistance Signal offers that Wire, through its use of MLS, doesn’t?
The metadata resistance of signal is largely mythical anyway since the necessarily have the metadata via other channels and just pinky promise not to look or store it
You can derive it from necessity if you like. Signal server sees the message come in over a network connection from an app. The server must be able to deliver it to a target user. This is the metadata. That the message data on the wire doesn’t contain this metadata doesn’t prevent the server from knowing it, it must know it in order to function at all. Signal has never claimed otherwise they only claim that the server forgets right away. But of course that must be taken on trust
At best, that associates two IP addresses… not withstanding CGNAT, VPNs, MASQUE, and friends.
But it doesn’t associate them with accounts / contacts. That’s a stronger guarantee than Matrix or XMPP. It may also be a stronger guarantee than Wire?
But it doesn’t associate them with accounts / contacts.
That isn’t true. Signal messages need to be routed by account identifier, an IP address is not sufficient. And unless you have the “sealed sender” feature turned on, messages identify their senders.
There’s no mechanism for the Signal server to know the IP addresses of iOS clients because an iOS device only maintains one persistent connection to Apple for notifications. There’s no way a Signal client can keep track of the IP addresses of its contacts, because it isn’t a mesh network, it’s a star. Even for non-iOS devices, an IP address isn’t sufficient to identify a client because (for example) there are multiple clients in our house and our house has only one IP address.
So it is. As far as I can tell the official documentation for the feature is still this blog post https://signal.org/blog/sealed-sender/ which makes it sound like the feature is incomplete, but the last few paragraphs say they were (in 2018) rolling it out to everyone so I guess the preview was actually the main event.
I just checked in settings. There’s only “show when it’s used” and “allow for even unknown senders” preferences for me, which makes me conclude that it’s already enabled by default and can not be disabled.
Sealed sender is also not a good protection if Signal was to actually start keeping logs. There are two sources of metadata leakage with sealed sender:
You need to acquire a sender certificate before you can use sealed sender. If you do this from the same IP as you later use when sending a message, your IP and your identity can be linked.
When you send a message, the receiver sends a delivery notice back to you. This is a simple correlation, a sealed message to Person A on IP address X from IP address Y is immediately followed by a sealed message from IP address X to Person B on IP address Y.
Yes, and if you do have Sealed Sender turned on, the only metadata left on the server that’s needed for message delivery is a 96-bit “delivery token” derived from a “profile key” that conveniently rotates whenever you block an account.
My reading of the description of sealed sender is that the delivery token is used check that the sender is allowed to send to the recipient – it’s an anti-abuse mechanism. It is used when the server is deciding whether to accept a message, it isn’t used to decide where to deliver the message.
That is not my reading of the server code for either single or multi-recipient messages. And Signal iOS at least seems to use sealed sender by default, though it falls back to unsealed send if there’s an auth failure, which seems bad. (so the server can force the client to identify itself? … but I also can’t find anywhere that throws RequestMakerUDAuthError.udAuthFailure, so maybe it’s dead code…)
But I admit it’s a very casual reading of the code!
To say what sibling says in a different way, the connection the message is delivered to the server over must be authenticated. If it weren’t the server would not accept the message, due to spam reasons etc. so the server knows the account of the sender. And it needs to know the account of the receiver for delivery to be possible
That article specifically admits this is true. Signal doesn’t choose to write it down (assuming the published code is what they run) which means it cannot be recovered after the fact (if you trust the server to not have recorded this) of course any other operator could also not write this down and one could choose to trust that operator. It’s not specific to signal really.
I believe we agree that the server must know the recipient of a message. I believe we disagree about whether the server needs to know the sender of a message.
Erm, so what do you mean by authenticated?
That article notes the sender’s metadata is (e2e) encrypted. The server accepts and routes messages whose envelope includes a delivery token. And, similarly, that delivery token is shared via e2e encrypted sessions to all a recipient’s contacts.
It’s unclear to me how unknown senders / randos are handled, however. I haven’t read that deep into the code.
Sure, that’s fair.
But I was hoping your claim was more substantial than just this, since, as since child comment below says, almost all signal competitors suffer from this.
Not just almost all. It is fundamentally impossible for a communications system to operate if whoever does the routing doesn’t know sender and receiver identity at some point (and send/receive time, which is also metadata)
If you do onion routing you could make it so only one part knows sender and one part knows receiver, which is how the remailer network worked but that’s the only instance I’m aware of doing that. Everyone else has the metadata and it’s just various shades of promising not to write it down.
Aren’t there protocols for deniable drop offs on servers and similar? Those wouldn’t scale well, but AFAIK they work. So they are possible (just not practical).
There is SecureDrop, but as far as the technology is concerned it’s a web app accessed via Tor. The rest of the anonymity guarantees come from server-side opsec performed by the recipient org https://docs.securedrop.org/en/stable/what_is_securedrop.html
SimpleX is a chat system that does onion routing. Only two hops, and I am not vouching for anything about the app or its servers; just noting this feature.
No one claimed otherwise. The context is the claim expressed above that you get worse metadata resistance than Signal, which seems irrelevant given that Signal doesn’t really have it either.
Sorry. I hear this line of argument on Hacker News and Reddit a lot, only for the person to turn around and recommend XMPP or Matrix instead. I wanted to cut it off at the pass.
I only recently discovered that Wire, a messenger headquartered in Switzerland and developed in Germany, also was involved in the specification of the MLS standard. It’s great to see they finally consider it production ready and are rolling it out to their own users.
Together with the server as well as the clients being open source, and Wire working on support for federation, this seems like a promising competitor to Matrix as well as Signal. I hope both Matrix and Wire also end up supporting MIMI, an IETF RFC for messenger interoperability.
This reminded me about a throwaway paragraph in the Signal crypto review (previously):
I wonder what metadata resistance Signal offers that Wire, through its use of MLS, doesn’t?
The metadata resistance of signal is largely mythical anyway since the necessarily have the metadata via other channels and just pinky promise not to look or store it
A source for this claim would be appreciated.
You can derive it from necessity if you like. Signal server sees the message come in over a network connection from an app. The server must be able to deliver it to a target user. This is the metadata. That the message data on the wire doesn’t contain this metadata doesn’t prevent the server from knowing it, it must know it in order to function at all. Signal has never claimed otherwise they only claim that the server forgets right away. But of course that must be taken on trust
At best, that associates two IP addresses… not withstanding CGNAT, VPNs, MASQUE, and friends.
But it doesn’t associate them with accounts / contacts. That’s a stronger guarantee than Matrix or XMPP. It may also be a stronger guarantee than Wire?
That isn’t true. Signal messages need to be routed by account identifier, an IP address is not sufficient. And unless you have the “sealed sender” feature turned on, messages identify their senders.
There’s no mechanism for the Signal server to know the IP addresses of iOS clients because an iOS device only maintains one persistent connection to Apple for notifications. There’s no way a Signal client can keep track of the IP addresses of its contacts, because it isn’t a mesh network, it’s a star. Even for non-iOS devices, an IP address isn’t sufficient to identify a client because (for example) there are multiple clients in our house and our house has only one IP address.
Sealed sender is enabled by default, no?
So it is. As far as I can tell the official documentation for the feature is still this blog post https://signal.org/blog/sealed-sender/ which makes it sound like the feature is incomplete, but the last few paragraphs say they were (in 2018) rolling it out to everyone so I guess the preview was actually the main event.
I just checked in settings. There’s only “show when it’s used” and “allow for even unknown senders” preferences for me, which makes me conclude that it’s already enabled by default and can not be disabled.
Sealed sender is also not a good protection if Signal was to actually start keeping logs. There are two sources of metadata leakage with sealed sender:
You need to acquire a sender certificate before you can use sealed sender. If you do this from the same IP as you later use when sending a message, your IP and your identity can be linked.
When you send a message, the receiver sends a delivery notice back to you. This is a simple correlation, a sealed message to Person A on IP address X from IP address Y is immediately followed by a sealed message from IP address X to Person B on IP address Y.
Yes, and if you do have Sealed Sender turned on, the only metadata left on the server that’s needed for message delivery is a 96-bit “delivery token” derived from a “profile key” that conveniently rotates whenever you block an account.
My reading of the description of sealed sender is that the delivery token is used check that the sender is allowed to send to the recipient – it’s an anti-abuse mechanism. It is used when the server is deciding whether to accept a message, it isn’t used to decide where to deliver the message.
I was going off the above-linked blog post that dives into the Signal internals.
That is not my reading of the server code for either single or multi-recipient messages. And Signal iOS at least seems to use sealed sender by default, though it falls back to unsealed send if there’s an auth failure, which seems bad. (so the server can force the client to identify itself? … but I also can’t find anywhere that throws
RequestMakerUDAuthError.udAuthFailure, so maybe it’s dead code…)But I admit it’s a very casual reading of the code!
edit: found it!
To say what sibling says in a different way, the connection the message is delivered to the server over must be authenticated. If it weren’t the server would not accept the message, due to spam reasons etc. so the server knows the account of the sender. And it needs to know the account of the receiver for delivery to be possible
I strongly suspect you’ve misunderstood how Signal works. What do you think about https://soatok.blog/signal-crypto-review-2025-part-8/, specifically the addendum section?
That article specifically admits this is true. Signal doesn’t choose to write it down (assuming the published code is what they run) which means it cannot be recovered after the fact (if you trust the server to not have recorded this) of course any other operator could also not write this down and one could choose to trust that operator. It’s not specific to signal really.
I believe we agree that the server must know the recipient of a message. I believe we disagree about whether the server needs to know the sender of a message.
Erm, so what do you mean by authenticated?
That article notes the sender’s metadata is (e2e) encrypted. The server accepts and routes messages whose envelope includes a delivery token. And, similarly, that delivery token is shared via e2e encrypted sessions to all a recipient’s contacts.
It’s unclear to me how unknown senders / randos are handled, however. I haven’t read that deep into the code.
Sure, that’s fair.
But I was hoping your claim was more substantial than just this, since, as since child comment below says, almost all signal competitors suffer from this.
Not just almost all. It is fundamentally impossible for a communications system to operate if whoever does the routing doesn’t know sender and receiver identity at some point (and send/receive time, which is also metadata)
If you do onion routing you could make it so only one part knows sender and one part knows receiver, which is how the remailer network worked but that’s the only instance I’m aware of doing that. Everyone else has the metadata and it’s just various shades of promising not to write it down.
Aren’t there protocols for deniable drop offs on servers and similar? Those wouldn’t scale well, but AFAIK they work. So they are possible (just not practical).
There is SecureDrop, but as far as the technology is concerned it’s a web app accessed via Tor. The rest of the anonymity guarantees come from server-side opsec performed by the recipient org https://docs.securedrop.org/en/stable/what_is_securedrop.html
SimpleX is a chat system that does onion routing. Only two hops, and I am not vouching for anything about the app or its servers; just noting this feature.
They were also recently audited by Trail of Bits, so SimpleX is probably not clownshoes.
This level of metadata leakage (IP addresses) is also true of nearly every so-called Signal competitor too.
No one claimed otherwise. The context is the claim expressed above that you get worse metadata resistance than Signal, which seems irrelevant given that Signal doesn’t really have it either.
Sorry. I hear this line of argument on Hacker News and Reddit a lot, only for the person to turn around and recommend XMPP or Matrix instead. I wanted to cut it off at the pass.
[Comment removed by author]
Look at zkgroup for a deep dive into that question.
I only recently discovered that Wire, a messenger headquartered in Switzerland and developed in Germany, also was involved in the specification of the MLS standard. It’s great to see they finally consider it production ready and are rolling it out to their own users.
Together with the server as well as the clients being open source, and Wire working on support for federation, this seems like a promising competitor to Matrix as well as Signal. I hope both Matrix and Wire also end up supporting MIMI, an IETF RFC for messenger interoperability.
IETF has so many standards for messenger interop already. What makes the one no one has implemented (mimi) special?