I don’t think that the code in the codebase is actually doing the right thing. Signal has inherited a design flaw from the phone network and email: they conflate an identity with a capability. Knowing my phone number should not automatically give you the right to call me.
The thing I want from Signal is the ability to create single-use capabilities that authorise another party to perform key exchange. That lets me generate tokens that I can hand to people (ideally by showing them a QR code from the UI) that let them call me from their Signal account but don’t let them (or whatever social networking malware they’ve grated access to their address book) pass on the ability to call me. Similarly, I want to be able to give a company a token that lets them call me but doesn’t let them share that ability with third parties.
This would also significantly reduce spam. If I have someone’s phone number in my address book and they have mine in theirs, you can grant access automatically, but for anyone else you need to be authorised to send me messages. Spam fighting is the main reason that they claim they keep the server code secret but necessary because of a fundamental design flaw in the protocol.
Unfortunately, Signal wants to add new kinds of identifiers but keep conflating them with capabilities, rather than fixing the problem.
Adding new identifiers will be useful in group chats (currently, I can’t join a group chat without sharing my phone number with everyone there), letting me have a per-group identifier, but that doesn’t help much if one malicious person in the group can leak that identifier and then any spammer can use it to contact me. If they built a capability mechanism then I could authorise members of the group to send me group messages but not authorise anyone else to contact that identity and, if I wanted to have a private chat with a group member, explicitly authorise that one person to send me private messages.
Most of the infrastructure for doing this was already added for sealed senders but I haven’t seen any sign that anyone is working on it.
There are legitimate usability and UX problems with federated and/or decentralised chat platforms. As well as more technical cryptographic hurdles compared to a centralised solution.
However I agree wholeheartedly with your point - there are just problems that need to be solved before any decentralised messaging system is accessible and seamless enough for “normal” users.
Also, if memory serves correct I don’t believe Moxie works with Signal any longer. I think he’s left.
Yes, Moxie wrote at length about the challenges of federation. The main one being the difficulty of coordinating changes and improvements.
In addition to UX, if Signal were widely federated, it might be 100x harder to add PQC like they just did, if it involved convincing every Signal server admin to upgrade.
Rightly or wrongly, federated systems are more ossified, and in the case of something like Signal, that presents future security risks.
In addition to UX, if Signal were widely federated, it might be 100x harder to add PQC like they just did
The change primarily (or even only) affects end-to-end components, meaning the server infrastructure is minimally (or not at all) affected. 100x harder it definitely is not.
federated systems are more ossified
But that is for ideological reasons, not technological ones. Federated systems often emphasise compatibility - that isn’t a technical requirement though. If you are in control of the primary server as well as the main client, you can force changes anyway. It raises the bar for deployments in that federation but that’s a good thing.
I dunno, email is the ultimate federated communication platform, and we still don’t have widespread encrypted email (without relying on a central provider). So maybe it’s not harder because of the server software, but it sure seems a lot harder to me.
I get what you’re saying, but federated systems have much larger consequences than just the server infrastructure. Perhaps I should have said “centralized” instead, since the relevant issue is that Signal is solely responsible for all server and client code. They don’t need to do the slow business of coordination, which we’ve seen from older systems like email/IRC/Jabber, tend to take a long time to get upgraded to the point that improvements can be relied upon.
In another part of lobste.rs right now, Mastodon is being scorched for not acceding to each and every demand put to it by other members of the fediverse. If Mastodon was dominant enough to unilaterally enforce, say, E2EE on ActivityPub, is that decentralized? Would that be a popular move?
My understanding was that he was stepping down as CEO but still very involved with the project. I may be totally wrong on this.
The centralization of Signal and the refusal of any alternative client connecting to the central signal server is a strong decision by Moxie, for a lot of technical reasons I think I understand (I simply disagree with the fact that those technical decisions should take precedence over the moral consequences of them). But, at least, Moxie has a real, strong and opiniated ethic.
I hope that whoever comes next will keep it that way. It is so easy to be lured by the blinking lights when to start to have millions of users. That’s why we should always consider Signal as a temporary solution. It is doomed from the start, by design. In one or ten years, it will be morally bankrupt.
The opposite could be said from the Fediverse. While the official Mastodon project have already showed sign of being “bought”, Mastodon is not needed to keep the fediverse going. It could be (and is already) forked. Or completely different clients can be used (Pleroma is one of the most popular).
I really want to use Signal, and recommend it to my friends and families, but I’m also sick of waiting for them to offer end-to-end encrypted backups on iPhone (it’s apparently possible on Android).
Not going to happen without in-browser code verification, which needs quite a lot of coordination between standardisation bodies and browser vendors. WhatsApp’s approach is not enough.
any program that has network access can listen on ports, so if any malicious code gets localhost:1234 before signal does, it gets all the cookies even if it can’t access your files
The only thing they’d need is to add a “secure mode” to Service Workers, which would prevent all bypasses. The difficulty is of course preventing the abuse of it for persistent client-side takeovers on compromised websites; I don’t know if a permission dialog would be good enough since people don’t actually read what they say.
Meh. One of the promises of a centralized service (instead of federated like email) is that Signal was going to be able to roll out network wide changes without crossing their fingers everyone follows suit. I understand they will need some transition phases themselves, but something doesn’t smell right here. Maybe it is just the article. It sets the stage for the PQC protocol to be only semi-trusted until proven, but then instead of encoding with both as a precaution for now it suggests a lowest-common-denominator approach will be used.
This is a fairly common technique with PQC. One of the last round of the NIST competition was knocked out because it was vulnerable to a classical attack. PQC algorithms are all built around bits of mathematics that haven’t been attacked by cryptographers before. They rely on assumptions that particular things are in a certain complexity class. Mathematicians may have worked on showing that that are, but sometimes those proofs hold for the general case but not for a large and subset that’s useful to an attacker. As such, there’s a non-trivial chance that any new PQC algorithm may be broken in the next few years.
You mitigate that risk by doing a classical encryption and then a PQ encryption step (or possibly the other way around). For an attacker to extract plaintext, they need to break both. If the PQ algorithm is broken, that’s sad, but the protocol is broken only by a quantum attacker and so is in no worse place than it was already. If a quantum computer comes along, the first step of the attack is easier but as long as the PQ algorithm holds up everything is fine. You’re protected now if the PQ algorithm has flaws and in the future if it doesn’t.
At some point, the PQ algorithms will be sufficiently mature that you can eliminate the classical wrapping step.
I understand the concept of using both to hedge your bets and using two encryption wrappers. My point was not about the unproven nature of PQC algorithms, it was about the centralized vs. federated debate. This is my beef from the article:
When one or more of the parties are using older versions, conversations will be encrypted with X3DH.
We were pitched the idea that Signal had to be a centralized service and couldn’t be federated because they needed unilateral control to force updates to the protocol. Now it terns out their centralized service still has to downgrade it’s cryptography to the lowest common denominator.
??? Where are you getting this from? From the article:
“Instead, we are augmenting our existing cryptosystems such that an attacker must break both systems in order to compute the keys protecting people’s communications.”
That doesn’t sound like a lowest-common-denominator approach to me.
When all parties in a discussion have new versions of Signal installed, PQXDH will be used. When one or more of the parties are using older versions, conversations will be encrypted with X3DH.
In other words a downgrade attack is for any party (or intercepted communications of any party) to claim to be an old client. I’m sure there are mitigations in place for that too, but the fact that they still have to fallback to only using the “legacy” method invalidates not PQC necessarily but the central reason we were pitched why a federated network would not work for Signal.
I don’t think falling back to the legacy method for now invalidates Signal’s reasoning. It seems more like a gradual upgrade path since the problem isn’t here yet.
Conversely, imagine it’s revealed today that the NSA can already break pre-quantum encryption.
Signal could unilaterally force their servers to ignore old clients, and push out a change so that newer clients refused to talk to older ones.
With federation, there would be weeks or months of either insecure chats, or connection failures, while everyone upgraded their servers and clients. If the issue weren’t severe, the upgrade process might never complete at all, which is what we’ve seen with suggested improvements to things like email/IRC/Jabber.
What if Signal got a post-phonenumber makeover. ;]
I’d very much like that. Apparently it’s already in the codebase they just need to turn it on. Sick of waiting for this to be honest.
I don’t think that the code in the codebase is actually doing the right thing. Signal has inherited a design flaw from the phone network and email: they conflate an identity with a capability. Knowing my phone number should not automatically give you the right to call me.
The thing I want from Signal is the ability to create single-use capabilities that authorise another party to perform key exchange. That lets me generate tokens that I can hand to people (ideally by showing them a QR code from the UI) that let them call me from their Signal account but don’t let them (or whatever social networking malware they’ve grated access to their address book) pass on the ability to call me. Similarly, I want to be able to give a company a token that lets them call me but doesn’t let them share that ability with third parties.
This would also significantly reduce spam. If I have someone’s phone number in my address book and they have mine in theirs, you can grant access automatically, but for anyone else you need to be authorised to send me messages. Spam fighting is the main reason that they claim they keep the server code secret but necessary because of a fundamental design flaw in the protocol.
Unfortunately, Signal wants to add new kinds of identifiers but keep conflating them with capabilities, rather than fixing the problem.
Adding new identifiers will be useful in group chats (currently, I can’t join a group chat without sharing my phone number with everyone there), letting me have a per-group identifier, but that doesn’t help much if one malicious person in the group can leak that identifier and then any spammer can use it to contact me. If they built a capability mechanism then I could authorise members of the group to send me group messages but not authorise anyone else to contact that identity and, if I wanted to have a private chat with a group member, explicitly authorise that one person to send me private messages.
Most of the infrastructure for doing this was already added for sealed senders but I haven’t seen any sign that anyone is working on it.
Recently encountered something that works exactly like that btw: https://simplex.chat
Super interesting I’d heard of simplex but never looked into it much. their white paper is so far an interesting read
What it illustrates is that we simply can’t rely on a centralized service.
I strongly believe that Moxie is doing all he can with good faith. That Signal is “good”.
But any centralized authority, even if benevolent, cannot be a long term solution. Even if it is “easier”.
There are legitimate usability and UX problems with federated and/or decentralised chat platforms. As well as more technical cryptographic hurdles compared to a centralised solution. However I agree wholeheartedly with your point - there are just problems that need to be solved before any decentralised messaging system is accessible and seamless enough for “normal” users.
Also, if memory serves correct I don’t believe Moxie works with Signal any longer. I think he’s left.
Yes, Moxie wrote at length about the challenges of federation. The main one being the difficulty of coordinating changes and improvements.
In addition to UX, if Signal were widely federated, it might be 100x harder to add PQC like they just did, if it involved convincing every Signal server admin to upgrade.
Rightly or wrongly, federated systems are more ossified, and in the case of something like Signal, that presents future security risks.
The change primarily (or even only) affects end-to-end components, meaning the server infrastructure is minimally (or not at all) affected. 100x harder it definitely is not.
But that is for ideological reasons, not technological ones. Federated systems often emphasise compatibility - that isn’t a technical requirement though. If you are in control of the primary server as well as the main client, you can force changes anyway. It raises the bar for deployments in that federation but that’s a good thing.
I dunno, email is the ultimate federated communication platform, and we still don’t have widespread encrypted email (without relying on a central provider). So maybe it’s not harder because of the server software, but it sure seems a lot harder to me.
What federated systems have E2EE enabled? I’m genuinely curious, because AFAIK systems like Matrix and Mastodon don’t. But I may be wrong.
matrix and xmpp support e2ee.
I could swear there was an article on here just recently about how E2EE in Matrix adds a ton of complexity.
Thanks for replying. I don’t get why people get their panties in a twist over Signal when these alternatives exist.
Matrix is pretty awful from a normal user‘s pov - slow, inconsistent, buggy. I think that’s why signal is much more widely used
I get what you’re saying, but federated systems have much larger consequences than just the server infrastructure. Perhaps I should have said “centralized” instead, since the relevant issue is that Signal is solely responsible for all server and client code. They don’t need to do the slow business of coordination, which we’ve seen from older systems like email/IRC/Jabber, tend to take a long time to get upgraded to the point that improvements can be relied upon.
In another part of lobste.rs right now, Mastodon is being scorched for not acceding to each and every demand put to it by other members of the fediverse. If Mastodon was dominant enough to unilaterally enforce, say, E2EE on ActivityPub, is that decentralized? Would that be a popular move?
Moxie is no longer CEO of Signal, by the way: https://www.theverge.com/2022/1/10/22876891/signal-ceo-steps-down-moxie-marlinspike-encryption-cryptocurrency
My understanding was that he was stepping down as CEO but still very involved with the project. I may be totally wrong on this.
The centralization of Signal and the refusal of any alternative client connecting to the central signal server is a strong decision by Moxie, for a lot of technical reasons I think I understand (I simply disagree with the fact that those technical decisions should take precedence over the moral consequences of them). But, at least, Moxie has a real, strong and opiniated ethic.
I hope that whoever comes next will keep it that way. It is so easy to be lured by the blinking lights when to start to have millions of users. That’s why we should always consider Signal as a temporary solution. It is doomed from the start, by design. In one or ten years, it will be morally bankrupt.
The opposite could be said from the Fediverse. While the official Mastodon project have already showed sign of being “bought”, Mastodon is not needed to keep the fediverse going. It could be (and is already) forked. Or completely different clients can be used (Pleroma is one of the most popular).
Whenever I hear this I think of how Whisperfish is a thing and how I should look at https://molly.im/
Those fork were, at first, really criticized. If I remember correctly, they were even briefly blocked.
Due to the social pressure, Signal is now mostly ignoring them but they are really not welcome.
I really want to use Signal, and recommend it to my friends and families, but I’m also sick of waiting for them to offer end-to-end encrypted backups on iPhone (it’s apparently possible on Android).
I’d like a browser client.
Not going to happen without in-browser code verification, which needs quite a lot of coordination between standardisation bodies and browser vendors. WhatsApp’s approach is not enough.
Running a local server that had a browser interface would be no problem.
any program that has network access can listen on ports, so if any malicious code gets
localhost:1234before signal does, it gets all the cookies even if it can’t access your filesIsn’t this more of a concern of the security of a machine? Wouldn’t key loggers and others be more of a concern?
[Comment removed by author]
The only thing they’d need is to add a “secure mode” to Service Workers, which would prevent all bypasses. The difficulty is of course preventing the abuse of it for persistent client-side takeovers on compromised websites; I don’t know if a permission dialog would be good enough since people don’t actually read what they say.
what if they could be signed and could store data to be readable only by workers signed with the same key?
Me too. My browser is at least decently accessible to me, the Signal desktop client is not.
Meh. One of the promises of a centralized service (instead of federated like email) is that Signal was going to be able to roll out network wide changes without crossing their fingers everyone follows suit. I understand they will need some transition phases themselves, but something doesn’t smell right here. Maybe it is just the article. It sets the stage for the PQC protocol to be only semi-trusted until proven, but then instead of encoding with both as a precaution for now it suggests a lowest-common-denominator approach will be used.
This is a fairly common technique with PQC. One of the last round of the NIST competition was knocked out because it was vulnerable to a classical attack. PQC algorithms are all built around bits of mathematics that haven’t been attacked by cryptographers before. They rely on assumptions that particular things are in a certain complexity class. Mathematicians may have worked on showing that that are, but sometimes those proofs hold for the general case but not for a large and subset that’s useful to an attacker. As such, there’s a non-trivial chance that any new PQC algorithm may be broken in the next few years.
You mitigate that risk by doing a classical encryption and then a PQ encryption step (or possibly the other way around). For an attacker to extract plaintext, they need to break both. If the PQ algorithm is broken, that’s sad, but the protocol is broken only by a quantum attacker and so is in no worse place than it was already. If a quantum computer comes along, the first step of the attack is easier but as long as the PQ algorithm holds up everything is fine. You’re protected now if the PQ algorithm has flaws and in the future if it doesn’t.
At some point, the PQ algorithms will be sufficiently mature that you can eliminate the classical wrapping step.
I understand the concept of using both to hedge your bets and using two encryption wrappers. My point was not about the unproven nature of PQC algorithms, it was about the centralized vs. federated debate. This is my beef from the article:
We were pitched the idea that Signal had to be a centralized service and couldn’t be federated because they needed unilateral control to force updates to the protocol. Now it terns out their centralized service still has to downgrade it’s cryptography to the lowest common denominator.
Temporarily. Once most clients are upgraded, it’ll switch to mandatory X3DH.
??? Where are you getting this from? From the article:
That doesn’t sound like a lowest-common-denominator approach to me.
Also from the article:
In other words a downgrade attack is for any party (or intercepted communications of any party) to claim to be an old client. I’m sure there are mitigations in place for that too, but the fact that they still have to fallback to only using the “legacy” method invalidates not PQC necessarily but the central reason we were pitched why a federated network would not work for Signal.
I don’t think falling back to the legacy method for now invalidates Signal’s reasoning. It seems more like a gradual upgrade path since the problem isn’t here yet.
Conversely, imagine it’s revealed today that the NSA can already break pre-quantum encryption.
Signal could unilaterally force their servers to ignore old clients, and push out a change so that newer clients refused to talk to older ones.
With federation, there would be weeks or months of either insecure chats, or connection failures, while everyone upgraded their servers and clients. If the issue weren’t severe, the upgrade process might never complete at all, which is what we’ve seen with suggested improvements to things like email/IRC/Jabber.