So far the biggest weakness of Signal is identification via a phone number. It's not only hackers who can spoof the numbers, but an authoritarian governments too may take ownership of a number at any moment.
Addressing future threats is good, but priorities should be different.
This is different though. PP is saying that you require a phone number to sign up, and phone numbers are being used to match your account to your user name.
"Signal does not send your phone number to anyone unless you have enabled that others can see it and then you send them a message or make a call to them."
Neither of these are the issue, the issue is the required association of a phone number with a Signal account. You cannot register a Signal account without a phone number.
It's something you'd want to avoid if your life, liberty or well-being are at risk if you're de-anonymized.
Signal, like most services, block text verification services, free texting apps, etc.
e-SIM wise, depending on where you are, that might require identifying yourself, and depending on your threat model, having to purchase one in person or with payment info that can be traced back to you might be too risky. Same thing when it comes to using one in a device you own, or in a location that can help de-anonymize you.
In the end, Signal does this because they know the ban hammer would come down hard on them from the Justice Department and every state AG and legislature if Signal allowed bad actors to anonymously use their app and network to commit crimes.
The issue is that there are plenty of people who are not doing heinous things whose security and anonymity might be at risk because of the measure put in place to placate governments.
You're confusing privacy with security. Phone numbers are a privacy problem and NOT a security problem.
Think of it this way. There's a vault that's locked with secrets inside, but the door is transparent. This does not prevent privacy. But the vault provides security.
Signal is not a transparent door, but is opaque. You can't see inside the vault. But the phone number reveals that you have access to the vault. This is very different than a security problem. Anyone connecting the two can see that you have a vault (security)[0], but they cannot see inside (privacy) or even when you access it (privacy).
There is no security issue with phone numbers.
[0] or can see that at some point in time you had a vault or someone that previously had that number had a vault
If your number is seized then the new account holder has no chat history. i.e. the vault is cleared out. In that situation you will also be kicked out, clearly telling you that your account has been hijacked.
It does not matter if you lose control of the number, the new person will be able to register. The 7 days period is for you to get control of the number back or make sure all your contacts know about the issue.
am I reading it wrong? but on my phone if i activate reglock again it says that if pin fails the account is blocked for seven days. I asume that after 7 days one still needs the pin to register or am i wrong?
There's a balance they want to strike. You can't assume phone numbers are unique to a person across time. So they need to be able to expire when someone stops using a number.
But again, acting on the other side also gets a notification in the chat stating that the security number has changed. The new person doesn't have the signal chat history. So if you're talking about sensitive things then it's a strong indication you should reverify their identity. Not practical for every day users but that's also not a typical threat scenario
Seems like you missed reading the entire context above. The discussion was about a number being seized or taken over by someone else. So your reply on inactivity is irrelevant since the new owner of the number can just wait a mere week and use it with Signal.
If you have done the out-of-band safety number verification, then impersonation attempts will give you a warning that their safety number has changed. I know this because I got that error when my wife replaced her cell phone.
I believe (though I haven't verified it myself) that even if you haven't verified the numbers using an out-of-band exchange mechanism, you will get a warning if the safety number as observed by their server changes. I believe they would need to know your Signal PIN to restore from backup, which means that even if you've set that it will give an alert, presuming basic security competence from the people you are conversing with.
> If you have done the out-of-band safety number verification
I personally have never seen anyone do this, even when they’re supposed to do it right from the very beginning. So practically this is of very little value to most of the user base.
You get notifications if the safety number gets changed from a device change either way. But doing the in person validation helps ensure that particular safety number you received was actually their safety number and not a MitM on first contact.
Yes, but with a canary. Would you rather not have a canary? The other person also receives a warning that the verification number has changed. It's not like the existence of a phone number is what creates the ability to hijack an account. And again, you can do registration locking so that solves that problem.
You can also do verification of your contacts. Best done in person where you can check the keys.
> MITM attack
I don't think that means what you think it means. Who is in the middle? This is E2EE
The privacy loss is "phone number has registered a signal account"
It does not
- conclude the user has or even has a signal account
- who that person is talking to
- what that person is talking about
- when those texts or messages are sent or received
What can you infer here that becomes a security risk? I guess if signal is outlawed before you have installed or your number was ever associated with an account? But it still have plausible deniability there
Yup, in Poland, a mobile phone number (pre-paid or not, it doesn't matter) is tied to a PESEL number [1] at the time of purchase. The official justification, as usual, was combating crime, but the end result is a tighter grip on citizens' privacy by the government while spammers and others continue their business as usual.
If no one knows your user ID besides you and the people you share it with, why would spam be a big issue? If it's a random string, I don't know how anyone could get it, unless you share it publicly or with someone untrustworthy who shares it publicly. And even if it's a username users choose, as long as there's no directory it still shouldn't be a big problem.
That is - even if someone makes 1000 bot Signal accounts, what can they really do with that if they don't have a good way of enumerating other Signal users?
> if they don't have a good way of enumerating other Signal users?
You can always brute force.
Btw, if you don't accept message requests from spammers they have no indication of if you have an account or not. Try sending a message to a friend who you haven't added on signal. You can just see you sent the message but not if it was received or rejected or anything. Not until they click accept
If it's a sufficiently long random string, that shouldn't be possible, right? Admittedly not an amazing user experience to have to share a random string to your friends, but many Signal-like apps do this.
Great point that requiring a friend request beforehand kind of eliminates the issue too. I assume the Signal developers do have a good reason for thinking requiring phone numbers reduces abuse, but I'm having trouble understanding it.
> Admittedly not an amazing user experience to have to share a random string to your friends
And struggle to get adoption. If it's too long, it's hard to share but difficult to brute force even with massive parallelism. But you can always brute force, it is just about how effective brute force is. Entropy is a double edged sword.
It's also harder to then do contact discovery to find who's already in the network. Which is the basic principle of any social network (yes, I'm calling old school landline phones a social network too). It's a tradeoff, right?
And it's worth noting that usernames exist now and this is serving as a bridge. You can provide links and QR codes too. I think this is a fair system and allows my grandma to use signal while still providing a path forward to another paradigm.
This brings me to one of my critiques of signal. I wish they would recognize we all have multiple identities. My real name obviously isn't godelski. But I might want to link my contact here on HN but not reveal to those people that my actual name is "Joe Schmoe". We don't need unlimited identities but having 2 or 3 could really do a lot for privacy. Let me have a little more granularity over my privacy settings. Let me have some people contact me via godelski.## and some by joeschmoe.##. The former sees my name as "godelski" and the latter as "joe".
And to be clear, the phone number issue is privacy related, not security.
> not an amazing user experience to have to share a random string to your friends
It doesn't have to be that way, at least in theory.
They can nerf accounts without verified phone numbers to be unable to reach verified accounts. And delete idle unverified accounts sooner, to combat potential DOS.
People who believe their phone number will be used to deanonymize them, can just use an account they keep unverified, and exchange IDs via other channels. It's harder, but for these people it will be worth it.
The rest of us can verify our phone numbers, and enjoy the easy discovery. (The way it is now.)
Machine-created, unverified, spam accounts will have to brute-force address space way bigger than that of phone numbers, and still only be able to reach other spam accounts, or an occasional very privacy-sensitive user.
I have no idea whether the above is technically possible, though.
You can't brute force it if the ID is large enough. E.g. if it's a 256 bit ID, sending 10^18 brute force messages per second it would still take 10^41 years until you hit a real user (assuming 6 billion users).
"Can I contact you on signal? Just wait for a few minutes while I type this 64 character long hex string".
I know you can work around this with QRs, but that's poor UX, has many failure scenarios and takes a long time. In comparison, you can just tell someone your phone number, even without neither of you having a phone nearby - you just need a piece of paper and a pen.
Signal brought security and privacy for the masses, because it - correctly - prioritized ease of use over tech-nerd paranoia.
> but that's poor UX, has many failure scenarios and takes a long time.
And requires you to build your social graph from scratch. That alone is killer to the average person.
Is signal the right tool for those hyper concerned with both security and privacy? No. But is it the right tool for the average person to securely communicate and get some good privacy? Absolutely.
People forget the GPG days. GPG had a huge flaw back then: you can't send GPG encrypted emails if no one was going to read them. It didn't become viable until that part was hidden in the background.
Good luck brute force guessing an Ed25519 keys (32 bytes).
Honestly there are so many better options than phone numbers available. If you're already using QR-codes to transmit user ids, you might as well use something that is transferable and user generated.
You're reading the problem wrong. Yeah, even considering the birthday problem you're going to have a hard time finding a valid key.
But now we have a discovery problem. How do I find my current contacts? Do I need you rebuild my social graph from scratch? Good luck getting my friends with PhDs in computer science doing this, let alone my grandma.
Entropy is a double edged sword. IMO signal is doing a good job here. We can go drop phone numbers completely when enough people are using signal. But while the userbase is low it's probably worth the 3 spam messages I get a year. I get more than that in a week on my iPhone and more than that a month when I used Android. So I'll take the trade.
And I must stress, the phone number issue is about privacy, not security. At least with regards to signal
One can still use simpler contact information like a phone number, email or QR code to transfer a user id.
While I love what Signal has done, the compromises are significant. I use Secure Scuttlebutt, Cabal, Spritely Goblins, Tor, email and a variety of other P2P software on whatever device I like, but Signal requires a phone with Android or Apple, and requires that I lock my id to my phone number.
> the compromises are significant.
> I use Secure Scuttlebutt, Cabal, Spritely Goblins, Tor,
And which of those are you able to communicate with your grandma on?
Honestly, I don't care how secure or how private (phone numbers are a privacy issue, not a security issue) if I have no one to communicate with. You need to solve the mass adoption problem.
You know Signal is doing something right when even the constant doubters use it. Exactly because it's very accessible.
There are always compromises some of them are hard to make. Signal successfully makes private / secures the “normal” conversations that would otherwise be on some Facebook owned app. None of the alternatives manage to do that.
Once you get Signal messages from randos without fist contact. Like airbnb hosts with password codes or IT admins or lawyers… it makes clear that they are doin it right.
Honestly it's just shame the platforms won't allow them to be the “native” sms app like iMessage. That would be the most ideal and probably upset much of the police deparments.
It's always the same complaints and they are trivial. Phone numbers, onboarding is hard because capatcha (wtf?!), signal is pwned because they got money from a government grant, moxie did some weekend hacking to integrate a cryptocurrency and so it's all shit.
I've never understood these. Even the non conspiracy stuff is just... nothing. Like do what? That's a roadblock for you? Then you shouldn't be on HN or be using a phone in the first place. Best to get off the internet all together.
I just don't understand why there's so much passionate hate. It feels like bots and trolls running a disinformation campaign but I actually think it's real people
It's sad because the people who are doubting tradeoffs Signal deliberately made don't seem to realize that it's these tradeoffs that make Signal work. They also usually don't offer any good faith critique, answers or solutions.
Bots join group chats to scrape user lists to spam. It's also desirable for users to be able to find their contacts already on Signal with phone numbers.
Sort of. There are now immense warehouses filled with racks of used cell phones to generate spam. Limiting by phone number helps, but it's FAR from being an adequate cure.
You don't need phonenumbers to deal with spam, just set the "allow messages only from contacts/friends" and a way to add new contacts when needed (via username, email, or even a phone number). It used to work without issues with protocols like MSN messenger, aim, icq etc.
Identification of what? That you have a signal account?[0] I'll admit that that's not ideal but I'm unconvinced this is a big issue.
> an authoritarian governments too may take ownership of a number at any moment.
Suppose they did hijack the account. This would not give them the message history. You know that, right? It also kicks out the original owner, warning them they've been pwned.
Don't get me wrong, Signal has issues and we should be critical and hold them to high standards. BUT *they are only E2EE and low metadata Messenger that my grandma can use.* That's a big fucking deal. If we want secure communication to be common place we need to make sure it's usable. Sure, there's more secure and more private services, but none that my grandma could use.
I very much think signal should shift focus to privacy as they've got the security side pretty well handled (as this blog illustrates). But also these comments at the top of any signal thread feel a bit out of touch. Maybe I'm reading too much into it but there's a lot of people who confidently act like this compromises security or places harm on a user. The existence of a registered signal account means very little, especially as you note numbers can be spoofed. You need more than a number to hijack an account and hijacking only reveals messages moving forward while telling the compromised user they're compromised.
So can we focus on bigger issues? Can we critique while still recommending? I have no problem saying I have issues with signal and wish they did more while acknowledging that it is strongly my preferred means of contact and I try to convince others to talk to me that way. These things are not at odds. I've gone so far as donating to them several times because I use the service so much
Having run some family through the Signal onboarding process lately I'm actually kind of disappointed though: the CAPTCHA requirements are a big turn off, and it was relatively difficult to get them to see "look I'm on Signal!" In their existing contacts.
To wit: phone numbers have to stay. That's how I even get people to use it with me, and that's enormously valuable.
But also: there really needs to be a way I can use my own account to vouch for a new user and skip that CAPTCHA (maybe there is? What happens if I do an in app invite?)
Yeah the onboarding process isn't the best but... is CAPTCHA requirements really that big of a deal? Where on the internet can you go where you don't face these? Maybe my grandma can't handle that, but my already retired parents can (and that's a pretty low bar if you know them). For my grandma, yeah, I'll set it up. For my parents and anyone under 70 I think CAPATCHA is not too high of a bar.
I think your threshold is too high. How high off the floor is a CAPATCHA? Because it looks like a bar rolling on the ground to me. You can trip over it but it is almost trivial to get over.
If I invite someone to use Signal and I'm not physically in the room with them, then what should happen is I get the CAPTCHA challenge and they get the magic link which avoids it.
My points are positive now but the variance has been huge. I'm surprised how often a comment like mine swings or gets entirely downvoted without a reply. I do not know if it is zealots, bots, or people just feel like the issue is "so obvious" that it needs no addressing. But I'm not sure how that's different than the first item.
It is also crazy to see how on HN of all places there's still a lot of confusion between the difference of privacy and security. People are saying phone numbers are a security issue. That's flat out wrong. It is a privacy issue.
Most people take no notice of this stuff IMO. I see it regularly in WhatsApp groups when someone gets a new phone (presumably, or they are being impersonated!).
Right but thats my point: if you adversary is a nation-state, assuming any technical measure can casually protect users against targeted action is foolhardy.
Signal keeps cranking out brilliant crypto papers, but from a product perspective, it feels like they're throwing stuff at the wall to see what sticks. We've got post-quantum handshakes, stories and money transfer experiments, but still no SDK, no APIs, no bots. The official libsignal library is undocumented and incomplete. Large parts of functionality are still buried on clients. Don't get me started on "but they have published all protocol specs on their website, go on and roll your own library"! That's not how you run a product. It's borderline negligent for a platform used by millions.
Every other major messaging app exposes something to developers, but Signal is allergic to the idea. Makes me wonder if they even have a head of product because whatever they're doing now is a far cry from a coherent product strategy. Signal is basically a pile of hot cryptography duct-taped to a messenger that's more hostile than any product in Apple's walled garden. And that's from a day one user who's been advocating for them the whole way.
</rant> thanks to everyone involved in building the product <3
> Every other major messaging app exposes something to developers
Not iMessage, which is the largest messaging app in the US. Uniquely, it doesn't even have an android app, so android users have to pay $800 to buy a single-use device with an effectively worthless OS bundled on it just to be able to join group chats.
iMessage doesn't even have good crypto, the default settings include unencrypted iCloud backups of your iMessage data lol.
I'll take Signal, which works on my desktop linux machine and android phone, over iMessage any day of the week, but the US as a whole seems to have chosen differently
As far as I know, there isn’t an official API for cross-platform communication. However, the Messages framework allows developers to create sticker packs and interactive messages for iMessage. People in the group can interact with messages created by other apps, such as polls, location updates, and game integrations to name a few
Signal don't want you to build 3rd party clients and integrations, they are another fully centralised product meant to capture and lock users into what signal believes is better for them. That's the whole "we love opensource but we won't merge your PRs and might lock your account out of the network for using forked clients that got rid of features like crypto that you might not like". I'm still sour for all the bad faith placating "the ecosystem is moving" post by Moxie and the lame excuse for not supporting federation. And no, I'm not finding it hard to onboard family and friends onto secure XMPP clients and accounts.
XMPP was a well intended idea but a bad protocol. Sure federation is good, but they needed a proper standard instead of making everything an optional extension that C2S and S2S never agree on. Like getting the right auth and encryption is even messier than on email.
Also, XML was the wrong choice. Pissed me off as a dev, back when I was doing stuff with ejabberd.
That's the kind of "compelling in theory, irrelevant in practice" comment I would make if I had no/obsolete experience with XMPP. It just works, with a healthy and thriving ecosystem of compatible client/server implementations developed independently by many organisations (small and large) around the world. At the user-level, it's just plug and play. As a developer, you don't even have to see any XML (you can deserialize your stanzas into whatever higher-level/prettier construct the programming language/stack your product depends on)
The argument that xmpp problems stem from XML format is the silliest of all: from 15 years of working with xmpp, we had all kinds of problems, but none of them were caused by XML format.
On the contrary, xmpp is a very good protocol. The problem with it is that most of extensions are bad: half-baked, often contradict or duplicate other extensions, and sometimes solve only part of the problem that they intend to solve.
Disclosure: my team and I are actively working on improving xmpp, but in a rather orthogonal direction to general XSF council route.
> The problem with it is that most of extensions are bad: half-baked, often contradict or duplicate other extensions, and sometimes solve only part of the problem that they intend to solve.
I think that's in the organic nature of protocols catching-up to changing goals and priorities, as the state of the art and the user needs evolve. I think it's pretty-well acknowledged by the XSF (and to a further extent by modernxmpp.org) by curating a short-list of XEPs and behaviours to implement.
I'm glad you aren't finding it hard. I can't even get people to move from Whatsapp and Messenger over to Signal. Only computer geeks seem to care or bother, so that's who is on my Signal list.
That's why I skip the Signal intermediate stage plain and simple: once Signal inevitably enshittifies (a property of centralised services), the people you painfully brought there will no longer kindly listen to you when, lesson learned, you will try to pull them into federated services.
For anyone else (i.e. the majority, which already has 2-5-10 messaging services on their device depending on how you count), quicksy.im does a decent job at emulating the onboarding experience of phone-based social graphs (WhatsApp & al.) and substantially lowers the barrier to being reachable over XMPP.
Counter argument: When the sole reason for existence for Signal is private/secure messaging, it makes sense to resist opening up to third party development.
That's a big can of worms that invariably will impact their ability to deliver on their main mission - private IM. Eg of problems: Who gets dev access, how do you vet plugins/aps from deceiving users, would users understand the risks, when an app gets compromised how to fight malicious campaign to discourage using Signal etc. etc.
Is this an important feature? I know WhatsApp and iMessage have some kind of API for businesses, but as a regular user, I've never interacted with a legit business using it. Only been harassed by bots a few times.
My one serious problem with Signal is that it silently goes out of date then stops sending notifications, so I miss messages entirely. Kind of its one job.
Maybe maybe not. I think it is a useful feature for power users. The question is if targeting power users will help mass appeal. I'd argue with an app like Signal, yes it would. The power users are effectively their evangelists. APIs could enable a lot of features that people are asking for like location sharing, bots (e.g. on your IOT devices), and so on. The concern is more that introducing those things creates security risks but I think that's okay. Put a "developer mode" type switch like in Android.
But there are also other things I'd like to see.
For mass appeal I'd like to see them integrating Signal Stickers[0] into the app so people can search stickers. This has been a surprisingly common complaint among people I've converted over.
For both groups I'd love to see something like this feature request[1] I like that it could serve as the backbone of a mesh network and AirDrop is a incredibly popular. Would be super cool if you could hold a copy of the APK on your phone and drop it over to others to install that way. I imagine even a rudimentary mesh network could really reduce server loads. My GF and I often sync pictures to each other this way. No reason that needs to go over the network when we're sitting 5 feet from one another.
For power users I'd love to see a nuking capability. Bidirectional. I want to know that if I am at a protest or something and get picked up by the Gestapo that either I or a trusted friend can wipe my phone. It's not a cure all, but it greatly reduces the chances of "incriminating" evidence being found on my device. But such a feature seems quite unpopular on their forums (I am very much not a fan of their forums and the community there...)
> APIs could enable a lot of features that people are asking for like location sharing
Please, no. You don't need that as a feature when you can drop a maps link.
> it could serve as the backbone of a mesh network
????? What?
> For power users I'd love to see a nuking capability. Bidirectional. I want to know that if I am at a protest or something and get picked up by the Gestapo that either I or a trusted friend can wipe my phone.
If you are at a protest with your phone, you are very likely leaking enough signals intelligence to identify, analyze, and monitor you and the entire group you are/were in contact with.
To me? All of these requests sound like things that would make the app the exact opposite of what I am looking for. Right now it is damn near perfect.
This does not update over time. So it has some serious limitations. The feature is actually quite helpful when meeting up with others, especially on longer road trips. It's a good way to allow the other person to know when to expect me as well as them know if I'm safe or have had hiccups. Means I am not using my phone while driving.
> ????? What?
For that link the user was talking about sending multimedia directly between devices, like "Airdrop". Why stop at pictures and videos? Why not texts? If these are short range then why send over the servers? It saves Signal server costs as well as provides some extra privacy and security for users as their messages cannot be gobbled up over the network (you'd have to be physically in range). Capture and decrypt later (the motivation Post-Quantum resistance, as discussed in the Signal blog post) can't be done if you don't capture, right?
There is real desire to still be able to communicate at times when networks are down. Be that a natural disaster, a crowded/congested area, or a government shutdown. Means of passing digital media during such events is still critical. It's not like we pass each other physical notes anymore. Plus, behind a secure protocol that's a bonus.
> If you are at a protest with your phone
Yeah sure, but reducing signals and information leakage is better than not reducing, right? Privacy and security are not binary things, they are continuums.
> To me?
Why?
Do these things stop you from using the app the way you currently use it?
I feel you. The "stories" feature especially felt like "throwing stuff at the wall to see what sticks." Given that they're a nonprofit founded by an anarchist, I assume their goals are just different from the typical product-focused company? Which I'm fine with, the app does what it's supposed to do. It would be lovely to have an SDK though.
Can anyone comment on where this puts Signal now in relation to iMessage with PQ3[1]? As an aside, can anyone comment on earlier (fast/rushed/sound?) attempts at quantum-resistant encrypted messaging in Cyph[2] and Simplex[3] in comparison?
My read is that Signal now ratchets with ML-KEM in a similar way to iMessages's PQ3, with key delivery being one of the main differentiating features.
Everyone is worried about the fact that ML-KEM keys are so chonky, so PQ3 sends them out only occasionally while Signal chunks them up and sends them in pieces along with all normal messages. Signal's argument is that a huge re-keying message could be detected and blocked, and chunking them is both safer and smoother on bandwidth. Erasure coding will likely wind up costing a bit more overall bandwidth, but each message will be more consistently sized. Given the wide range of Signal's deployment posture, that is probably a wise tradeoff to make. I would expect that Apple has a bit more control over their networks and are in a better position to deal with adversaries attempting to actively block their re-key updates.
Is iMessage even relevant since the vast majority of Apple users have iCloud backups turned on without E2E? E2E backups are opt-in because Apple can't help you recover your data if you turn it on.
Given that, Apple can already decrypt messages of users, if so requested by law enforcement and intelligence agencies. No fancy quantum breaches needed.
Im feeling pretty dumb even after reading the tldr. Can anyone who is well versed in this explain how this is better or safer? I read about the time, will it now be slower to send messages?
In the standard practical analysis of quantum threats to cryptography, your adversary is "harvesting and then decrypting". Everybody agrees that no adversary can perform quantum cryptography today, but we agree (to agree) that they'll plausibly be able to at some point in the future. If you assume Signal is carrying messages that have to be kept secret many years into the future, you have to assume your adversary is just stockpiling Signal ciphertexts in a warehouse somewhere waiting so that 15 or 20 years from now they can decrypt them.
That's why you want PQ key agreement today: to protect against a future capability targeting a record of the past. (It's also why you don't care as much about PQ signatures, because we agree no adversary can time travel back and MITM, say, a TLS signature verification).
To understand the importance of a PQ ratchet, add one more capability to the adversary. In addition to holding on to ciphertexts for 15-20 years, assume they will eventually compromise a device, or find an implementation-specific flaw in cryptography code that they can exploit to extract key material. This is a very realistic threat model; in fact, it's of much more practical importance than the collapse of an entire cryptographic primitive.
You defend against that threat model with "forward secrecy" and "post-compromise security". You continually update your key, so the compromise of any one key doesn't allow an attacker to retrospectively decrypt, or to encrypt future messages.
For those defenses to hold against a "harvest and decrypt" attacker, the "ratchet" mechanism you use to keep re-keying your session also needs to be PQ secure. If it isn't, attackers will target the ratchet instead of the messages, and your system will lose its forward and post-compromise secrecy.
I think this used to be true. Now one problem is that a Signal message goes through this whole forward secrecy protocol, but the receiving device has some probability of uploading it to the cloud with a static key that never changes.
You don't have to enable the Signal backups feature, but you have no way of knowing whether the recipient of your messages has. One person in a group chat with that enabled will undo all of the forward secrecy you're describing.
The static symmetric key is fundamentally different from an ephemeral asymmetric key. We've no indication that symmetric encryption is vulnerable to "store now, decrypt later" attacks when used with a sufficiently long key, which Signal has. Non-post-quantum asymmertic cryptography is vulnerable to "store now, decrypt later" attacks, which is why forward secrecy is needed.
The backups feature doesn't open up any new vulnerability that didn't inherently exist in sending messages to someone else you might not fully trust. One person in a group chat can also take pictures of their phone's screen & upload your messages to the public.
Images can be modified, won't these essentially be signed as verifiably coming from the sender, or is cryptographic proof of that thrown away in what they store?
This is no different than if recipient of the secure message shares the message in plaintext. The problem is a discipline problem not a technology one, and the solution is the same in both cases.
There's a difference between what Signal does in the app and a manual action a user performs outside of the app. It is not realistic to expect that people will see a feature Signal has built for them in the app and understand the underlying implications to "post compromise security" and "forward secrecy" that it may have.
The expectation is that what happens inside Signal is secure, and the features Signal provides are secure. If the idea is that nobody is going to enable this feature, then why build it? If the idea is that many people are going to enable this feature, then this entire cryptographic protocol is meaningless.
These things can still be used as evidence. The process used by the police of a rogue country (or any other adversary) isn't a cryptographer's highly technical wet dream or nightmare. They simply look at the screen of your phone saying you sent or received a message, and as far as the adversary is concerned, that proves you sent or received it. Even if you didn't. (Actually, they use Cellebrite and just trust whatever the Cellebrite analyzer outputs, which is basically what your screen would have said)
I've yet to see a protocol that lets you convincingly insert fake messages into both sides of your own chat history, especially in a way that isn't detectable by say, sqlite rowid order, but that would be an interesting idea for where to take this sort of thing.
Those are the breaks though when catering to a large audience with wildly differing threat models. Do you throw away users that are looking for a vague sense of security so they run off somewhere else less secure because you lack some feature?
If you are just looking for "secure(TM)[X]", you are making a mistake somewhere anyway.
If your life or livelihood depends on it, you learn what the impact of every choice is and you painstakingly keep to your opsec.
Somewhere between the two user action becomes a necessity. You need to judge where that point is for you and take responsibility for it because nobody else can guarantee it.
At the very least they should have excluded any chats with disappearing messages enabled from being included in backups.
With disappearing messages off it was already reasonable to assume that a compromise of a counterparty's phone would result in exposure of all previous messages, so enabling backups wouldn't expose you to new risk.
That would cater to those who want to keep their chat history forever without exposing those with disappearing messages enabled to new risk.
The history of Signal has been to provide the security properties we're talking about without users having to think about it or understand. To suddenly remove forward secrecy is a very big change, and it isn't one that they seem to have acknowledged or documented. Like this blog post: they are making an announcement that they have a "post-quantum ratchet," when they have effectively removed the ratchet. It's theater.
I think you missed the point entirely. You can't have security without thinking about it. You can have vague sense of security, which is the theater you are talking about.
Show me a company anywhere that can provide security without user thought and deliberate action. It's a fantasy to believe anything you don't have to think about isn't theater. Hell, if you aren't thinking about it, you're one of the actors in that theater.
But practically, it probably has more risk as people bypassing employer or legal controls think it’s “secure”. So they have conversations that they wouldn’t have.
The security problem that a messaging app like Signal solves is NOT: Allow a person to secure their communication against eavesdroppers.
It solves the problem: How can a group of people (two or more people) securely communicate with each other.
The group has to mutually decide their risk profile, and then decide which features of the application to use. And each person in the group has to decide whether they can trust others in the group to follow the agreed upon opsec. Signal cannot solve these social problems.
Historically as long as everything remained "in the app," it was secure. It's an easy assumption to make and communicate to others. Now it's more complicated: there are things that people can unwittingly do "in the app" that make it less secure.
AFAIK, it has the same security as before. Perfect forward secrecy means that if someone starts recording encrypted messages in transit and two years later obtains an encryption key, they cannot use that key to decrypt the messages they recorded earlier (because of re-keying).
On the other hand, if an adversary captures one of the group participants' phone and breaks device security, and the chat was recorded on that device, then they can access all recorded chats. By the same token, no cryptography can protect against a malicious group participant who records messages.
In the same scenario, cloud backups seem to merely imply that the same adversary can obtain the cloud backup key and therefore decipher the cloud backups if they get their hands on it. They won't need that, however, since the group chat history is already stored on the device. If no chats were recorded on the device at all the situation would be different.
You also have no way of knowing when someone you're chatting with screenshots your messages and uploads them to Imgur.
I jest, and Signal's support for backups do really increase exposure to this risk, but just trying to say its a matter of degree not a fundamentally new change. People that have been using sigtop[0] to backup their Signal messages to plaintext also create the same exposure risk.
I don't think that's quite right. PQ attacks focus on the "trapdoor" functions in asymmetric cryptography, _not_ the symmetric encryption that happens after key negotiation. The current concern is that a future attacker could unwrap the symmetric key, not directly attack the symmetric encryption that is used for something like backups.
(Note: I didn't actually dig into the backup implementation, but my guess is that it's more of a KDF -> symmetric design, rather than the sorts of asymmetric negotiation you'd find in multi-party messaging.)
If the app takes your disappearing message, encrypts it with a static key that never changes and is never deleted, and uploads it to the cloud, then the message is never truly "disappearing." A "post compromise" event will allow the attacker to decrypt that ciphertext at any point in the future. All of this ratcheting is undone by backups.
Disappearing messages were never a real thing in the first place. You can have a gentleman's agreement that the person you send your message to will delete it after reading it, there's no way to guarantee anything beyond that.
(Fair point though that probably "disappearing" messages shouldn't be included in backups since that obviously prevents them from being deleted. Idk if Signal implements that or not.)
What type of static key? If it's just a big symmetric key that isn't derived from an asymmetric handshake of some type then no, that's not our current understanding of the PQ threat model.
Part of the premise of FS/PCS is that "shit happens" to compromise keys even if the underlying cryptography is strong, so if you want a coherent end-to-end FS/PCS story, the claim would be that you need to be ratcheting everywhere.
Definitely, but when we're running around sprinkling PQ algorithms all over the place, it's on top of the asymmetric bits, not replacing the "boring" stuff like your symmetrically encrypted backups. Shit certainly does happen, especially where key management is involved, but I'm not sure I agree that offering an encrypted backup feature is necessarily undoing the FS/PCS story.
edit: Well, let me argue with myself for a moment. I don't think offering an encrypted backup feature undoes the PQ story. But FS/PCS is weakened, sure, since we're talking about all types of shit happening, not just currently known (or strongly theorized) attacks.
Yes, if Signal has effectively removed ratcheting and forward secrecy from the logical "encryption protocol" by encrypting all messages (even disappearing messages) with a single static key that never changes for your lifetime and sending them to the cloud, then all this talk about "post-quantum ratchets" is theater. There are no ratchets.
I'm slightly confused about the PCS part. If I've understood correctly the new key is derived from the old key + some kind or message header. If the attacker has access to a key and messages encrypted with it, can't they read the shared secret used for key exchange and use their existing key to generate the new one? Or is this only possible with ECDH and not KEM?
The new one is randomly chosen (with the randomness coming from both parties, and then combined using ECDH and/or KEM). So you cannot predict it from previous key material, pretty much by definition.
What is the state of PQ symmetric crypto? My layman's understanding is that 128 bit AES is known to be broken by a quantum computer and that 256 AES may be OK but that isn't certain? Is this an additional vector for the "harvest and wait" strategy in the future?
> My layman's understanding is that 128 bit AES is known to be broken by a quantum computer
Weakened, not broken. Quantum computers turns 128 bit AES into 64 bit equivalent. Which will still be extremely difficult for quantum computers due to the large computer size/number of steps required.
And it's 64-bit equivalent in a way that's inherently impossible to parallelize, so 2^64 sequential quantum operations. Those operations are much, much slower than classical ones.
They still take the same amount of time to run it. You don't get a result by running for 1/n of the steps, so adding more QCs lets you attack more keys at once but doesn't let you attack any given key any faster.
Well, you get sqrt(n / N) as a result. It works like any other parallel computation.
E.g. if you have 256 quantum computers, then each one of them needs to search only 60 bits of the key space to crack a 128-bit key (each one of them will only need to search 2^120 keys).
It's not really going to make much difference with near-future quantum computers. Especially since Grover's algorithm _has_ to complete all the 2^60 steps to produce a reliable result, you can't just run a quantum computer for a while, stop it, and then restart it.
>> Forward secrecy is somewhat overrated in end to end encrypted messaging. Most people do not want a truly off the record experience but instead keep their old messages around indefinitely. As long as those old messages exist and are accessible to the user they will be just as accessible to any attacker that gets access to the secret key material.
On a more serious note, if a quantum computer can break a key, a task requiring exponential complexity with key length on a classical computer, then breaking N keys is only a negligible additional cost in comparison.
So it kind of feels like it’s overrated in this case to be honest :)
Their existing post quantum encryption didn't do post compromise security (PCS) against quantum attackers. This new one does.
I am excited to finally know what they mean by PCS after reading this article. It means that the session keys from their key agreement scheme (n ratchet) are generated new so an attacker doesn't get them again after a fairly specific sort of compromise. So from that I get that the off the record (OTR) protocol also has PCS. Which is a bit disappointing, I thought that they had come up with some new concept.
This key agreement doesn't happen that often. So a user isn't going to notice any slowness even if it was significantly slower.
> "What does this mean for you as a Signal user? First, when it comes to your experience using the app, nothing changes. Second, because of how we’re rolling this out and mixing it in with our existing encryption, eventually all of your conversations will move to this new protocol without you needing to take any action. Third, and most importantly, this protects your communications both now and in the event that cryptographically relevant quantum computers eventually become a reality, and it allows us to maintain our existing security guarantees of forward secrecy and post-compromise security as we proactively prepare for that new world."
I can't believe that they named their protocol SPQR. It's the Latin abbreviation for Senatus Populusque Romanus. https://en.wikipedia.org/wiki/SPQR
Love it :)
Lol. You would only see this comment on Hacker News. Reminds me of an old comic I read on how mathematicians memorize their locker numbers. "1975? Oh that's easy. It's just the square root of 3,900,625!"
Ever since I've heard of the meme that "modern men can't spend 24 hours without thinking of the Roman Empire", I haven't been able to escape it, even on days where my only contact with the outside world is HN.
I guess it's like a curse, once you've heard about it you're doomed.
And for anyone finding out about it just now, alea jacta est
It's only a certain type of man that they are talking about. We are not that type of men I guess. Can't say I know anyone what that problem to be honest. And yes, I have heard that saying before. Didn't work then and doesn't work now.
It's extremely easy if you're immersed in Southern European culture.
Moru -> Flag of Sardinia, whose Wikipedia page incidentally I was reading yesterday (the Four Moors, "is cuatru morus") -> Sardinian language -> grammatically still the closest language to Latin -> the everlasting glory of the Roman Empire
For me it's not so much what's interesting as what affects my day to day. I love Chinese history but I'm unlikely to come across anything today with origins in Chinese law, or traverse the path of a Chinese road, or use an interesting word with a Chinese etymology and an associated story from old China.
For national history, Chinese is probably my favorite by far.
May I suggest you do a domain-specific history dive, such as the history of computing, the history of science or some other subject you may enjoy more. That's the real good stuff.
It's so funny to see this be a worldwide phenomenon. As someone who grew up playing in the ruins of Roman temples & villas and was obsessed with it as a child, it almost feels like people are talking about "some other Rome".
I grew up in a school system which taught us about "our ancestors, the Gauls"...
Which is fun if you're an Asterix fan, but one day you end up asking yourself - wait, we're in an ex-French colony here, but how much Gaul blood does anyone have in this place really?
For this particular one, you could easily see that comment on any community with a sufficient number of Asterix fans. Banners and standards with "SPQR" written somewhere were common enough that they should produce a Pavlovian reaction.
I am struggling to believe that the Roman Empire reference for this acronym is "so obvious". I do know about the meme: in fact, what struck me so hard about this is how, for a protocol where you'd almost expect it to be hard for them to avoid the acronym "SPQR" (as, even if it were not Sparse, it is made by Signal; I could even see them having started with Signal and decided to remove their brand from the acronym), there are not one but two top-level posts on Hacker News where "speaker" seems to have wooshed over their head and somehow this extremely niche acronym from the Roman Empire is clearly the reason why this is called SPQR. Is the tech community on Hacker News really this stereotypical?
If you've learned even a little about the history of Rome then you'll quickly bump into SPQR, Mary Beard's recent popular, and very good book on the Romans it titled "SPQR", in the city of Rome you'll see SPQR used all over, in films when Romans are depicted, SPQR is always there. While not everyone will have a background where it's familiar, it's also not at all obscure. If you're not familiar with the Romans you won't know, but lots of people like to learn about the ancient past since it's really interesting to some types.
I dunno, SPQR is fairly obvious for anyone who covered Rome in elementary or middle school history.
Beyond that, if you’re from the part of the world where asterix comics were popular (mostly thr francosphere, but also europe more broadly), it really stands out.
That’s all to say nothing of people who’ve got formal higher education in history or even the classics.
I struggle to see how this could be a conspiracy in any form, but maybe you can make it more clear for me? As I see it, it would make perfect sense for a democracy driving app to focus on “Senate and People”, the fact that is sound like "speaker" simply makes it more brilliant.
Wow, this is one of the most well written cryptography articles I've ever seen.
I consider myself a fairly experienced software engineer with a moderate amount of professional experience in private sector encryption, so I'm not completely out of my element, but many articles along this vein have my eyes glazing over halfway through the breakdown.
This one was actually easy for me to follow the entire time for once, despite explaining something I'm not familiar with.
Signal is lacking a crucial safety feature. To cover some background, it is necessary to set "Who can see my number" and "Who can find me by number" both to "Nobody", as this lowers the chances of spam messages and attempted hacks. Once these are set, the only way for someone to start a conversation with you is if they know your Signal username or QR link, both of which you can set in your Profile. The issue is that your link can be saved unsafely by your Contacts, and can be used multiple times, also by others, leaking it to hackers who can then send you unsolicited messages to compromise your device. The safety feature that would be good to have is to allow someone to contact me only via a one-time use link that cannot be reused by anyone.
This sounds like an excellent feature request that would shore up their anti-abuse endeavors more than them "lacking a very basic crucial safety feature".
Which of the so-called Signal competitors have implemented something like this already today?
This is a good time to remind everyone the technically sound choice of hybrid crypto is discouraged by NSA. I wish they didn't. PQ is a major overhaul to crypto systems. Setting aside the risk of yet-to-be-discovered algorithmic vulnerabilities, there is a huge risk of implementation mistakes leading to compromise. Mature classical crypto should be used as a backstop by deploying PQ in hybrid mode along classical crypto.
Isn't the point of hybrid crypto due to the possibility that this fancy new quantum resistant algorithms have a fatal flaw? If so, I could understand why NSA has that stance (if you don't trust the crypto its useless), but realistically it's a good idea.
That's not how we approach security. We don't think in terms of 'Trust' in algorithm. We think in terms of risk management. It's not uncommon for new algorithms and approaches to have algorithmic or implementation flaws. That is a risk. One of the mitigations we often consider is adding another layer of defense.
The (very weak) Caesar cipher was used in ancient Rome though and cryptography in general way before. It could be a silent nod to how far our achievements have gone and that encryption is a basic human desire since millennia.
I’m still not sure how do you even compromise a key without also compromising message history. The keys are stored on-device, along with associated history. If attacker has access to the keys, they also have access to all the previous messages stored on the same device. Unless you’re using auto-delete with short period on all your messaging, which I would think is not common, it would seem that you gain nothing by ratcheting.
I would really like to see some modern comparisons of the Signal protocol to Matrix, MLS, etc. since it's hard to keep up with everything but it seems like things are still moving.
“Signal Protocol” is a somewhat fuzzy description of whatever Signal does at a given point in time. Historically, this meant Double Ratchet, which is O(N) with the number of devices in a conversation. This uses elliptic curve cryptography to exchange keys (X25519); it was then extended to be PQ via PQXDH by adding Kyber512 to the initial key exchange, and has now also been extended to be PQ for subsequent ratcheting by mixing in the SQPR ratchet. Signal itself is obviously centralised; 3rd party implementations are forbidden; the implementation is AGPL+CLA. It has good metadata protection thanks to hiding group membership from the sender and “sealed sender” to hide the sender from the server too.
Matrix is an open standard communication protocol. It supports pluggable E2EE, although the only protocol in production right now is Olm+Megolm. Olm is an implementation of the Double Ratchet, and Megolm is a per-sender ratchet used to share keys with the group. The current implementation of Olm from the Matrix Fdn is an Apache-licensed project called vodozemac. This sprouted experimental PQXDH support in Jan 2024 (https://github.com/matrix-org/vodozemac/pull/120). Matrix is decentralised; anyone can run a server; multiple heterogeneous implementations are heavily encouraged. More metadata is exposed to the server than Signal - for instance the server can see the group membership, and key-value data is not encrypted (although we’re working on that right now: https://element.io/blog/hiding-room-metadata-from-servers/). Also, group membership is controlled by the server; clients warn when if unexpected users/devices are added, but the protocol does not forbid it. We’re also working on fixing that, but it is a huge change.
Finally, MLS (RFC 9420) is effectively a key exchange and group membership protocol. You can use it to add E2EE to messaging systems as an alternative to the Double Ratchet, while also using it to control group membership. By default it uses classical elliptic curve encryption, but there are proposals to make it PQ. It’s more performant than the double ratchet in that calculating new ratchets is O(log N). However, joining groups is still O(N). It’s much less mature than the Double Ratchet, more complicated, but benefits from significant cryptanalysis and formal verification thanks to being an IETF standard. It also seems to get significant hype just by being an IETF standard. It requires a centralised component to sequence MLS group operations, so to use it in systems like Matrix you have to extend it to be decentralised (see arewemlsyet.com). It doesn’t hide metadata from the server. It also doesn’t provide cryptographic deniability (unlike the double ratchet). It is not that widely deployed yet, although Google apparently uses it for RCS (presumably thanks to it being IETF and avoids any possible IPR questions over the double ratchet), which means it should be huge. Discord and Webex also use it for VoIP conferences.
Its interesting to imagine that somebody [1] is already now capturing encrypted internet traffic and storing it all long-term, to then hypothetically in 40-50 years or something decrypt it and draw value from that information. I suppose to blackmail future politicians, learn military secrets, whatever.
> Its interesting to imagine that somebody [1] is already now capturing encrypted internet traffic and storing it all long-term, to then hypothetically in 40-50 years or something decrypt it and draw value from that information. I suppose to blackmail future politicians, learn military secrets, whatever.
You don't have to imagine, there's literally a NSA datacenter in Utah for doing just that.
As someone not in the field it's hard to distinguish the "quantum startup raised x billions, claims quantum computing x years away" from "fusion startup raised x billions, claims fusion power x years away" headlines every few months for the past 10+ years.
Thanks for the link. I skimmed through the report that the article is based on. It tracks rising activity in quantum computing R&D in several areas. But at least in the executive summary, I didn't see anything about commercial applications one way or the other. It doesn't seem to make any predictions?
So, it's odd that the article summarized it that way.
> Overall, quantum processing units (QPUs) are making impressive progress in performance, but they remain far from meeting the requirements for running large-scale commercial applications such as chemical simulations or cryptanalysis.
That's what I don't get - these folks must be more bullish than me on practical quantum computing. If you assume 20-30 years; there's no important military secrets left (what was China building in the late 90s?!) and how many politicians are in politics for that long?
This is actually disturbing, as the article suggests that all previous messages sent using Signal are decryptable with quantum computers. If there are people with, for example, selfhosted mailservers sending PGP encrypted emails to each other, then, while they have to worry about them not leaking out from the server either by someone hacking to it or someone sniffing the traffic with the encrypted messages beforehand, they know for sure that their messages are safe.
Meanwhile Signal users have been sending messages onto signal servers for years now, as far as I know they aren't sent directly through some p2p protocol. I don't know what their policy is about storing messages, and I believe that they have a lot of other countermeasures, but it still points to the problem with Signals centralized nature.
As far as they say, messages are deleted once delivered, or retained up to 45 days if not:
Devices are always retrieving messages from their mailbox when they are
online, and as soon as the device confirms they’ve gotten a message, it is
deleted from the Signal servers.
If a device has been offline for a while, it may have a lot of messages
waiting in its mailbox when it returns. Today, Signal will hold a message in
a device’s mailbox for up to 45 days, giving an idle device a chance to wake
up and fetch it.
It is possible for them to say that they deleted the messages without actually deleting them though. One has to trust a pretty big company in order to not worry about the messages actually not being stored anywhere.
I'm not aware of all techniques that Signal uses to somehow make the message anonymous even when if the encryption would have been broken, but sealed sender seems to be one of them:
So at least there's that. Unless the encrypted sealed sender messages aren't somehow being fingerprinted by the IP address of client and the timestamps of connections. Signal probably also says that they don't log these, but with self hosted mailserver I wouldn't have to trust them on that too.
Huh, it's true. I thought an organization that needs $50M yearly to function[1] would employ more people. Still, I think it's fair to call them "pretty big" looking on how much media exposure they get or their operating costs. Perhaps a bit misleading from my part with the "company" part, as I'm not english-native, every type of firm,company,foundation in my head translates to a "company", sorry about that, will be more clear next time :)
No worries, I don't think "company" is even technically wrong. But I do think given the nonprofit structure (and Moxie Marlinspike's track record), that there are fewer incentives for Signal to lie about its privacy guarantees than a messaging app backed by a commercially-driven big company.
Using PGP over self-hosted email servers won't help you against a post-quantum adversary. While people have discussed post-quantum extensions to PGP, it doesn't exist yet. Similarly, while post-quantum TLS _does_ exist, it was only just implemented in OpenSSL; I doubt Postfix supports it yet.
So you're in an even worse post-quantum situation with email, even if you end up with TLS-encrypted PGP-encrypted messages, you're still not post-quantum secure.
My point is that to this date everyone was not post-quantum secure, and only the people whom had their messages stored on their servers only can be sure that someone won't read their contents.
Also PGP emails were just an idea that seemed the most basic for me to illustrate an example of selfhosted encrypted messaging. Probably they lack more security features than just post-quantum, compared to the other messengers anyway :)
In the scenario with mailservers with PGP encrypted messages I did intend the messages to be encrypted client side, perhaps it was not clear enough. When I selfhost my own server (and my trusted friend selfhosts his), I can be completely sure that the encrypted messages will not be dumped either through storage or while relaying them. If sent PGP end-to-end encrypted messages through, say, gmail, then I'm not 100% sure that gmail won't store these messages somewhere and decrypt them whenever quantum computing becomes available for them.
Maybe my reading comprehension is failing me, but what does this mean for existing messages? I guess nothing of the have already been 'siphoned' to a 3rd party. As it couldn't retroactively apply to data not under Signals control of course..but what about existing messages already within their control?
Strange that they are posting about the "signal ratchet" when they just removed it by launching cloud backups that use a static key? Since those cloud backups include disappearing messages, that feature completely undoes all of the forward secrecy in this protocol.
Signal can't protect you against the other party you are communicating with. They can backup the conversation, or screenshot it, or take a photo of the screen with another camera. They could also retell in their words what you sent.
You know (with pretty high certainty) that your conversational partner is using Signal. The security level of Signal affects your estimation of the security level of your partner.
Yes, but you don't need a complicated ratcheting protocol if you've eliminated forward secrecy in other ways. This post is about "post compromise security," but there is already no post-compromise security after the cloud backups feature
Do you also think it's "strange" that they're introducing that (optional!) feature while also storing all the messages on your device? The cloud backup is strictly more secure than that on-device database. Their blog post on the subject also explicitly says it won't include disappearing messages that disappear within 24 hours.
It's not optional because you don't know whether the people you are communicating with have it enabled. One person in a group chat with the feature enabled undoes the forward secrecy for everyone in the group chat.
A cloud backup eliminates any forward secrecy. It used to be that in Signal, when you have a message on your device and it is deleted (or a disappearing message disappears), then it is truly gone and can never be recovered. Now with backups, since the key that was used to encrypt it to the cloud remains on your device, it can be recovered even after the message is deleted or disappears.
The only way to "truly" opt-out is to, as you say, set a disappearing message timer for <24 hours.
Yeah, and all of that's already true right now because messages are stored on those users' devices already. You'll be heartbroken to hear that those users can also take a screenshot of your disappearing messages and send it to anyone. There are fundamental limitations to what a messaging app can protect you from.
While the analog hole will always exist, and you can't make it actually impossible, Snapchat's quite good at that screenshot thing. Both platforms have APIs to prevent, or at least notify on the use of screenshot. It's weird that signal doesn't use any of them.
i know of ~3 currently working methods to take screenshots on snapchat
it isn't "weird that signal doesn't use any of them" because it does [1] use both, just not for giving a false sense of security to your correspondents
this is the same argument as saying "you shouldn't have remote delete requests". Yes, people can screenshot or export. That doesn't mean you shouldn't have a nicety that generally works pre-compromise or pre-evil. Locks just keep honest people honest.
I want signal to act as a transport bus. In particular, I want to give certain contacts permission to ask my phone for its location, so I can give my wife that ability without sharing it with Google.
Signal has solved the identity part, now encourage others to build apps on it.
(2fa via Signal would be better than SMS, too, though I know this may be controversial!)
I'm not seeing how you could draw that conclusion. The more likely explanation is that they are telling people not to build apps around it (and I assume thus the apis aren't well designed for adoption by other apps).
> This repository is used by the Signal client apps (Android, iOS, and Desktop)
as well as server-side. Use outside of Signal is unsupported.
So far the biggest weakness of Signal is identification via a phone number. It's not only hackers who can spoof the numbers, but an authoritarian governments too may take ownership of a number at any moment.
Addressing future threats is good, but priorities should be different.
In case anyone is not aware:
https://news.ycombinator.com/item?id=39444500 Keep your phone number private with Signal usernames (2024-02-20, 1422 points, 890 comments)
This is different though. PP is saying that you require a phone number to sign up, and phone numbers are being used to match your account to your user name.
"As a new default, your phone number will no longer be visible to everyone in Signal."
https://support.signal.org/hc/en-us/articles/6712070553754-P...
"Signal does not send your phone number to anyone unless you have enabled that others can see it and then you send them a message or make a call to them."
https://support.signal.org/hc/en-us/articles/360007061452-Do...
Neither of these are the issue, the issue is the required association of a phone number with a Signal account. You cannot register a Signal account without a phone number.
It's something you'd want to avoid if your life, liberty or well-being are at risk if you're de-anonymized.
Realistically could use an e-sim or text verification service to sign up.
Signal, like most services, block text verification services, free texting apps, etc.
e-SIM wise, depending on where you are, that might require identifying yourself, and depending on your threat model, having to purchase one in person or with payment info that can be traced back to you might be too risky. Same thing when it comes to using one in a device you own, or in a location that can help de-anonymize you.
In the end, Signal does this because they know the ban hammer would come down hard on them from the Justice Department and every state AG and legislature if Signal allowed bad actors to anonymously use their app and network to commit crimes.
The issue is that there are plenty of people who are not doing heinous things whose security and anonymity might be at risk because of the measure put in place to placate governments.
[dead]
Google Voice worked for me a few years ago
This doesn't address the security problem
Think of it this way. There's a vault that's locked with secrets inside, but the door is transparent. This does not prevent privacy. But the vault provides security.
Signal is not a transparent door, but is opaque. You can't see inside the vault. But the phone number reveals that you have access to the vault. This is very different than a security problem. Anyone connecting the two can see that you have a vault (security)[0], but they cannot see inside (privacy) or even when you access it (privacy).
There is no security issue with phone numbers.
[0] or can see that at some point in time you had a vault or someone that previously had that number had a vault
Is there not a security problem if your phone number is seized? I don't need excuses about the likelihood of the threat model.
If your number is seized then the new account holder has no chat history. i.e. the vault is cleared out. In that situation you will also be kicked out, clearly telling you that your account has been hijacked.
You can also lock registration of your device.
What is your security concern here?
> You can also lock registration of your device
Registration lock expires in seven days or less. [1]
[1]: https://support.signal.org/hc/en-us/articles/360007059792-Si...
Please actually read
I don't know why you dropped "of inactivity" and changed it to "or less".If you use signal once a week you're fine. Maybe it should be longer but that's a different argument and there's no reason to be disingenuous about it
It does not matter if you lose control of the number, the new person will be able to register. The 7 days period is for you to get control of the number back or make sure all your contacts know about the issue.
am I reading it wrong? but on my phone if i activate reglock again it says that if pin fails the account is blocked for seven days. I asume that after 7 days one still needs the pin to register or am i wrong?
You'll get the opportunity to change the pin.
There's a balance they want to strike. You can't assume phone numbers are unique to a person across time. So they need to be able to expire when someone stops using a number.
But again, acting on the other side also gets a notification in the chat stating that the security number has changed. The new person doesn't have the signal chat history. So if you're talking about sensitive things then it's a strong indication you should reverify their identity. Not practical for every day users but that's also not a typical threat scenario
Seems like you missed reading the entire context above. The discussion was about a number being seized or taken over by someone else. So your reply on inactivity is irrelevant since the new owner of the number can just wait a mere week and use it with Signal.
Impersonation, MITM attack
If you have done the out-of-band safety number verification, then impersonation attempts will give you a warning that their safety number has changed. I know this because I got that error when my wife replaced her cell phone.
I believe (though I haven't verified it myself) that even if you haven't verified the numbers using an out-of-band exchange mechanism, you will get a warning if the safety number as observed by their server changes. I believe they would need to know your Signal PIN to restore from backup, which means that even if you've set that it will give an alert, presuming basic security competence from the people you are conversing with.
> If you have done the out-of-band safety number verification
I personally have never seen anyone do this, even when they’re supposed to do it right from the very beginning. So practically this is of very little value to most of the user base.
You get notifications if the safety number gets changed from a device change either way. But doing the in person validation helps ensure that particular safety number you received was actually their safety number and not a MitM on first contact.
You can also do verification of your contacts. Best done in person where you can check the keys.
I don't think that means what you think it means. Who is in the middle? This is E2EEfor this reason there is the signal pin. they need pin and phonenumber to hijack the account. afaik
A lack of privacy is a security problem for messaging. A lack of privacy predisposes some people to rubber hose cryptanalysis by the authorities.
The privacy loss is "phone number has registered a signal account"
It does not
What can you infer here that becomes a security risk? I guess if signal is outlawed before you have installed or your number was ever associated with an account? But it still have plausible deniability thereThis entire post does not follow
Agreed as far as governments tracking Signal sign-ups. For a long time though user names were not even supported between Signal users.
Many other secure IM software managed to work without phone numbers and they are also metadata resistant. Signal should start doing things that way.
In many countries your SIM card is tied to you, which is a huge deal-breaker.
Yup, in Poland, a mobile phone number (pre-paid or not, it doesn't matter) is tied to a PESEL number [1] at the time of purchase. The official justification, as usual, was combating crime, but the end result is a tighter grip on citizens' privacy by the government while spammers and others continue their business as usual.
[1] https://en.wikipedia.org/wiki/PESEL
Same or similar in Germany. Almost impossible to get a SIM card without showing up somewhere with your id. Or I don't know how to.
Just step into a random supermarket in a neighbouring countr and buy a SIM in cash at the register.
It's crazy how heterogeneous rules are inside the EU.
Its a difficult problem because you, ideally, want to curb spam. Requiring phone numbers is a somewhat easy and somewhat reliable way to do that.
If no one knows your user ID besides you and the people you share it with, why would spam be a big issue? If it's a random string, I don't know how anyone could get it, unless you share it publicly or with someone untrustworthy who shares it publicly. And even if it's a username users choose, as long as there's no directory it still shouldn't be a big problem.
That is - even if someone makes 1000 bot Signal accounts, what can they really do with that if they don't have a good way of enumerating other Signal users?
Replace "user ID" with "email address". Pretty much the same thing. But spam is a huge problem with email.
But people use their emails for more than just talking to people. You don't need an IM account to, say, register on a website.
Btw, if you don't accept message requests from spammers they have no indication of if you have an account or not. Try sending a message to a friend who you haven't added on signal. You can just see you sent the message but not if it was received or rejected or anything. Not until they click accept
If it's a sufficiently long random string, that shouldn't be possible, right? Admittedly not an amazing user experience to have to share a random string to your friends, but many Signal-like apps do this.
Great point that requiring a friend request beforehand kind of eliminates the issue too. I assume the Signal developers do have a good reason for thinking requiring phone numbers reduces abuse, but I'm having trouble understanding it.
It's also harder to then do contact discovery to find who's already in the network. Which is the basic principle of any social network (yes, I'm calling old school landline phones a social network too). It's a tradeoff, right?
And it's worth noting that usernames exist now and this is serving as a bridge. You can provide links and QR codes too. I think this is a fair system and allows my grandma to use signal while still providing a path forward to another paradigm.
This brings me to one of my critiques of signal. I wish they would recognize we all have multiple identities. My real name obviously isn't godelski. But I might want to link my contact here on HN but not reveal to those people that my actual name is "Joe Schmoe". We don't need unlimited identities but having 2 or 3 could really do a lot for privacy. Let me have a little more granularity over my privacy settings. Let me have some people contact me via godelski.## and some by joeschmoe.##. The former sees my name as "godelski" and the latter as "joe".
And to be clear, the phone number issue is privacy related, not security.
> not an amazing user experience to have to share a random string to your friends
It doesn't have to be that way, at least in theory.
They can nerf accounts without verified phone numbers to be unable to reach verified accounts. And delete idle unverified accounts sooner, to combat potential DOS.
People who believe their phone number will be used to deanonymize them, can just use an account they keep unverified, and exchange IDs via other channels. It's harder, but for these people it will be worth it.
The rest of us can verify our phone numbers, and enjoy the easy discovery. (The way it is now.)
Machine-created, unverified, spam accounts will have to brute-force address space way bigger than that of phone numbers, and still only be able to reach other spam accounts, or an occasional very privacy-sensitive user.
I have no idea whether the above is technically possible, though.
You can't brute force it if the ID is large enough. E.g. if it's a 256 bit ID, sending 10^18 brute force messages per second it would still take 10^41 years until you hit a real user (assuming 6 billion users).
"Can I contact you on signal? Just wait for a few minutes while I type this 64 character long hex string".
I know you can work around this with QRs, but that's poor UX, has many failure scenarios and takes a long time. In comparison, you can just tell someone your phone number, even without neither of you having a phone nearby - you just need a piece of paper and a pen.
Signal brought security and privacy for the masses, because it - correctly - prioritized ease of use over tech-nerd paranoia.
Is signal the right tool for those hyper concerned with both security and privacy? No. But is it the right tool for the average person to securely communicate and get some good privacy? Absolutely.
People forget the GPG days. GPG had a huge flaw back then: you can't send GPG encrypted emails if no one was going to read them. It didn't become viable until that part was hidden in the background.
It's even easier than that since you already have the phone numbers in your contact list, they will just show up as soon as you sign up.
Good luck brute force guessing an Ed25519 keys (32 bytes).
Honestly there are so many better options than phone numbers available. If you're already using QR-codes to transmit user ids, you might as well use something that is transferable and user generated.
You're reading the problem wrong. Yeah, even considering the birthday problem you're going to have a hard time finding a valid key.
But now we have a discovery problem. How do I find my current contacts? Do I need you rebuild my social graph from scratch? Good luck getting my friends with PhDs in computer science doing this, let alone my grandma.
Entropy is a double edged sword. IMO signal is doing a good job here. We can go drop phone numbers completely when enough people are using signal. But while the userbase is low it's probably worth the 3 spam messages I get a year. I get more than that in a week on my iPhone and more than that a month when I used Android. So I'll take the trade.
And I must stress, the phone number issue is about privacy, not security. At least with regards to signal
One can still use simpler contact information like a phone number, email or QR code to transfer a user id.
While I love what Signal has done, the compromises are significant. I use Secure Scuttlebutt, Cabal, Spritely Goblins, Tor, email and a variety of other P2P software on whatever device I like, but Signal requires a phone with Android or Apple, and requires that I lock my id to my phone number.
Honestly, I don't care how secure or how private (phone numbers are a privacy issue, not a security issue) if I have no one to communicate with. You need to solve the mass adoption problem.
You know Signal is doing something right when even the constant doubters use it. Exactly because it's very accessible.
There are always compromises some of them are hard to make. Signal successfully makes private / secures the “normal” conversations that would otherwise be on some Facebook owned app. None of the alternatives manage to do that.
Once you get Signal messages from randos without fist contact. Like airbnb hosts with password codes or IT admins or lawyers… it makes clear that they are doin it right.
Honestly it's just shame the platforms won't allow them to be the “native” sms app like iMessage. That would be the most ideal and probably upset much of the police deparments.
It's always the same complaints and they are trivial. Phone numbers, onboarding is hard because capatcha (wtf?!), signal is pwned because they got money from a government grant, moxie did some weekend hacking to integrate a cryptocurrency and so it's all shit.
I've never understood these. Even the non conspiracy stuff is just... nothing. Like do what? That's a roadblock for you? Then you shouldn't be on HN or be using a phone in the first place. Best to get off the internet all together.
I just don't understand why there's so much passionate hate. It feels like bots and trolls running a disinformation campaign but I actually think it's real people
Perfect is the enemy of good.
It's sad because the people who are doubting tradeoffs Signal deliberately made don't seem to realize that it's these tradeoffs that make Signal work. They also usually don't offer any good faith critique, answers or solutions.
Bots join group chats to scrape user lists to spam. It's also desirable for users to be able to find their contacts already on Signal with phone numbers.
In signal you can change your username any time.
Sort of. There are now immense warehouses filled with racks of used cell phones to generate spam. Limiting by phone number helps, but it's FAR from being an adequate cure.
Yeah, if the telegram and whatsapp spam I get is any reading, limiting by phone number is not sufficient.
You don't need phonenumbers to deal with spam, just set the "allow messages only from contacts/friends" and a way to add new contacts when needed (via username, email, or even a phone number). It used to work without issues with protocols like MSN messenger, aim, icq etc.
This, exactly this.
I don't want everyone who knows my number to be just able to reach me.
Whitelist instead of Blacklist!
Whitelisting solves spam. Phone numbers should be obsolete by now.
You can set a password in Signal, preventing movement of your account in case of SIM hijacking. Feature is called "Registration lock".
Don't get me wrong, Signal has issues and we should be critical and hold them to high standards. BUT *they are only E2EE and low metadata Messenger that my grandma can use.* That's a big fucking deal. If we want secure communication to be common place we need to make sure it's usable. Sure, there's more secure and more private services, but none that my grandma could use.
I very much think signal should shift focus to privacy as they've got the security side pretty well handled (as this blog illustrates). But also these comments at the top of any signal thread feel a bit out of touch. Maybe I'm reading too much into it but there's a lot of people who confidently act like this compromises security or places harm on a user. The existence of a registered signal account means very little, especially as you note numbers can be spoofed. You need more than a number to hijack an account and hijacking only reveals messages moving forward while telling the compromised user they're compromised.
So can we focus on bigger issues? Can we critique while still recommending? I have no problem saying I have issues with signal and wish they did more while acknowledging that it is strongly my preferred means of contact and I try to convince others to talk to me that way. These things are not at odds. I've gone so far as donating to them several times because I use the service so much
[0] https://signal.org/bigbrother/
Having run some family through the Signal onboarding process lately I'm actually kind of disappointed though: the CAPTCHA requirements are a big turn off, and it was relatively difficult to get them to see "look I'm on Signal!" In their existing contacts.
To wit: phone numbers have to stay. That's how I even get people to use it with me, and that's enormously valuable.
But also: there really needs to be a way I can use my own account to vouch for a new user and skip that CAPTCHA (maybe there is? What happens if I do an in app invite?)
Yeah the onboarding process isn't the best but... is CAPTCHA requirements really that big of a deal? Where on the internet can you go where you don't face these? Maybe my grandma can't handle that, but my already retired parents can (and that's a pretty low bar if you know them). For my grandma, yeah, I'll set it up. For my parents and anyone under 70 I think CAPATCHA is not too high of a bar.
I think your threshold is too high. How high off the floor is a CAPATCHA? Because it looks like a bar rolling on the ground to me. You can trip over it but it is almost trivial to get over.
If I invite someone to use Signal and I'm not physically in the room with them, then what should happen is I get the CAPTCHA challenge and they get the magic link which avoids it.
Except Captcha is to make it harder for spammers, if they just have to do Captcha once and then invite more accounts it kinda defeats the purpose.
Imagine being someone who would downvote this without a comment.
Is it:
"I disagree but am not literate enough to state why"
Or is it:
"This person is right, but I don't want people to know it (insert motive here), so I will try to make their comment invisible"
Either way they're cowards, and you are correct. Signal is the best intersection of genuine security and ease-of-use I've seen.
My points are positive now but the variance has been huge. I'm surprised how often a comment like mine swings or gets entirely downvoted without a reply. I do not know if it is zealots, bots, or people just feel like the issue is "so obvious" that it needs no addressing. But I'm not sure how that's different than the first item.
It is also crazy to see how on HN of all places there's still a lot of confusion between the difference of privacy and security. People are saying phone numbers are a security issue. That's flat out wrong. It is a privacy issue.
They can take ownership of the number but not the keys on the device, which would show up as safety codes changing.
This problem is honestly minor compared to teaching users to have opsec practices suitable against such a threat.
Most people take no notice of this stuff IMO. I see it regularly in WhatsApp groups when someone gets a new phone (presumably, or they are being impersonated!).
Right but thats my point: if you adversary is a nation-state, assuming any technical measure can casually protect users against targeted action is foolhardy.
Check molly, FOSS Implementation of signal protocol
https://molly.im/
That's a fork of signal.
Also annoying: You cannot use the same Signal account from 2 different phones (with different SIM).
It's pathetic, isn't it?
Signal keeps cranking out brilliant crypto papers, but from a product perspective, it feels like they're throwing stuff at the wall to see what sticks. We've got post-quantum handshakes, stories and money transfer experiments, but still no SDK, no APIs, no bots. The official libsignal library is undocumented and incomplete. Large parts of functionality are still buried on clients. Don't get me started on "but they have published all protocol specs on their website, go on and roll your own library"! That's not how you run a product. It's borderline negligent for a platform used by millions.
Every other major messaging app exposes something to developers, but Signal is allergic to the idea. Makes me wonder if they even have a head of product because whatever they're doing now is a far cry from a coherent product strategy. Signal is basically a pile of hot cryptography duct-taped to a messenger that's more hostile than any product in Apple's walled garden. And that's from a day one user who's been advocating for them the whole way.
</rant> thanks to everyone involved in building the product <3
> Every other major messaging app exposes something to developers
Not iMessage, which is the largest messaging app in the US. Uniquely, it doesn't even have an android app, so android users have to pay $800 to buy a single-use device with an effectively worthless OS bundled on it just to be able to join group chats.
iMessage doesn't even have good crypto, the default settings include unencrypted iCloud backups of your iMessage data lol.
I'll take Signal, which works on my desktop linux machine and android phone, over iMessage any day of the week, but the US as a whole seems to have chosen differently
As far as I know, there isn’t an official API for cross-platform communication. However, the Messages framework allows developers to create sticker packs and interactive messages for iMessage. People in the group can interact with messages created by other apps, such as polls, location updates, and game integrations to name a few
Signal don't want you to build 3rd party clients and integrations, they are another fully centralised product meant to capture and lock users into what signal believes is better for them. That's the whole "we love opensource but we won't merge your PRs and might lock your account out of the network for using forked clients that got rid of features like crypto that you might not like". I'm still sour for all the bad faith placating "the ecosystem is moving" post by Moxie and the lame excuse for not supporting federation. And no, I'm not finding it hard to onboard family and friends onto secure XMPP clients and accounts.
XMPP was a well intended idea but a bad protocol. Sure federation is good, but they needed a proper standard instead of making everything an optional extension that C2S and S2S never agree on. Like getting the right auth and encryption is even messier than on email.
Also, XML was the wrong choice. Pissed me off as a dev, back when I was doing stuff with ejabberd.
That's the kind of "compelling in theory, irrelevant in practice" comment I would make if I had no/obsolete experience with XMPP. It just works, with a healthy and thriving ecosystem of compatible client/server implementations developed independently by many organisations (small and large) around the world. At the user-level, it's just plug and play. As a developer, you don't even have to see any XML (you can deserialize your stanzas into whatever higher-level/prettier construct the programming language/stack your product depends on)
The argument that xmpp problems stem from XML format is the silliest of all: from 15 years of working with xmpp, we had all kinds of problems, but none of them were caused by XML format.
XML isn't the root of any problems, it's just one extra annoyance
No, it isn't. Source: I work with it every day.
I picked XML for Jabber in 1998, and at that time I think it was the best choice :)
Hi Jeremie, you made the world a better place, thanks for Jabber!
On the contrary, xmpp is a very good protocol. The problem with it is that most of extensions are bad: half-baked, often contradict or duplicate other extensions, and sometimes solve only part of the problem that they intend to solve.
Disclosure: my team and I are actively working on improving xmpp, but in a rather orthogonal direction to general XSF council route.
> The problem with it is that most of extensions are bad: half-baked, often contradict or duplicate other extensions, and sometimes solve only part of the problem that they intend to solve.
I think that's in the organic nature of protocols catching-up to changing goals and priorities, as the state of the art and the user needs evolve. I think it's pretty-well acknowledged by the XSF (and to a further extent by modernxmpp.org) by curating a short-list of XEPs and behaviours to implement.
I'm glad you aren't finding it hard. I can't even get people to move from Whatsapp and Messenger over to Signal. Only computer geeks seem to care or bother, so that's who is on my Signal list.
That's why I skip the Signal intermediate stage plain and simple: once Signal inevitably enshittifies (a property of centralised services), the people you painfully brought there will no longer kindly listen to you when, lesson learned, you will try to pull them into federated services.
For anyone else (i.e. the majority, which already has 2-5-10 messaging services on their device depending on how you count), quicksy.im does a decent job at emulating the onboarding experience of phone-based social graphs (WhatsApp & al.) and substantially lowers the barrier to being reachable over XMPP.
Counter argument: When the sole reason for existence for Signal is private/secure messaging, it makes sense to resist opening up to third party development.
That's a big can of worms that invariably will impact their ability to deliver on their main mission - private IM. Eg of problems: Who gets dev access, how do you vet plugins/aps from deceiving users, would users understand the risks, when an app gets compromised how to fight malicious campaign to discourage using Signal etc. etc.
Is this an important feature? I know WhatsApp and iMessage have some kind of API for businesses, but as a regular user, I've never interacted with a legit business using it. Only been harassed by bots a few times.
My one serious problem with Signal is that it silently goes out of date then stops sending notifications, so I miss messages entirely. Kind of its one job.
Maybe maybe not. I think it is a useful feature for power users. The question is if targeting power users will help mass appeal. I'd argue with an app like Signal, yes it would. The power users are effectively their evangelists. APIs could enable a lot of features that people are asking for like location sharing, bots (e.g. on your IOT devices), and so on. The concern is more that introducing those things creates security risks but I think that's okay. Put a "developer mode" type switch like in Android.
But there are also other things I'd like to see.
For mass appeal I'd like to see them integrating Signal Stickers[0] into the app so people can search stickers. This has been a surprisingly common complaint among people I've converted over.
For both groups I'd love to see something like this feature request[1] I like that it could serve as the backbone of a mesh network and AirDrop is a incredibly popular. Would be super cool if you could hold a copy of the APK on your phone and drop it over to others to install that way. I imagine even a rudimentary mesh network could really reduce server loads. My GF and I often sync pictures to each other this way. No reason that needs to go over the network when we're sitting 5 feet from one another.
For power users I'd love to see a nuking capability. Bidirectional. I want to know that if I am at a protest or something and get picked up by the Gestapo that either I or a trusted friend can wipe my phone. It's not a cure all, but it greatly reduces the chances of "incriminating" evidence being found on my device. But such a feature seems quite unpopular on their forums (I am very much not a fan of their forums and the community there...)
[0] https://signalstickers.org/
[1] https://community.signalusers.org/t/signal-airdrop
> APIs could enable a lot of features that people are asking for like location sharing
Please, no. You don't need that as a feature when you can drop a maps link.
> it could serve as the backbone of a mesh network
????? What?
> For power users I'd love to see a nuking capability. Bidirectional. I want to know that if I am at a protest or something and get picked up by the Gestapo that either I or a trusted friend can wipe my phone.
If you are at a protest with your phone, you are very likely leaking enough signals intelligence to identify, analyze, and monitor you and the entire group you are/were in contact with.
To me? All of these requests sound like things that would make the app the exact opposite of what I am looking for. Right now it is damn near perfect.
There is real desire to still be able to communicate at times when networks are down. Be that a natural disaster, a crowded/congested area, or a government shutdown. Means of passing digital media during such events is still critical. It's not like we pass each other physical notes anymore. Plus, behind a secure protocol that's a bonus.
Yeah sure, but reducing signals and information leakage is better than not reducing, right? Privacy and security are not binary things, they are continuums. Why?Do these things stop you from using the app the way you currently use it?
If that's what you want, please just fork it.
I feel you. The "stories" feature especially felt like "throwing stuff at the wall to see what sticks." Given that they're a nonprofit founded by an anarchist, I assume their goals are just different from the typical product-focused company? Which I'm fine with, the app does what it's supposed to do. It would be lovely to have an SDK though.
No API and Bots is a feature for me
Yeah if I wanted that stuff I'd go to XMPP or matrix.
I'm absolutely okay with having none of that. I hope they focus on making a secure and usable messenger above all else.
The last thing I want in this product at this point is (more) bots.
That's a fast on-ramp to an extremely shitty experience moving forward.
let alone this that drives me nuts: they are playing the ringing sound for the caller without the callee's phone actually ringing.
and it's a deliberate choice that they are defending for seceral years now, ever since they removed the submarine sound.
I did not know this but now that you mentioned it, it will forever bug me. I did notice that it plays very early when you make a call.
if you look at the screen, it first prints "connecting", and then "ringing".
I'm surprised a semi-auditable Signal for Enterprise or Government hasn't surfaced. Every chat is mandatorily a group chat including the company.
TeleMessage is a prominent, infamous such product: https://micahflee.com/tm-sgnl-the-obscure-unofficial-signal-...
Can anyone comment on where this puts Signal now in relation to iMessage with PQ3[1]? As an aside, can anyone comment on earlier (fast/rushed/sound?) attempts at quantum-resistant encrypted messaging in Cyph[2] and Simplex[3] in comparison?
[1] https://security.apple.com/blog/imessage-pq3/ [2] https://www.cyph.com/castle [3] https://simplex.chat/blog/20240314-simplex-chat-v5-6-quantum...
My read is that Signal now ratchets with ML-KEM in a similar way to iMessages's PQ3, with key delivery being one of the main differentiating features.
Everyone is worried about the fact that ML-KEM keys are so chonky, so PQ3 sends them out only occasionally while Signal chunks them up and sends them in pieces along with all normal messages. Signal's argument is that a huge re-keying message could be detected and blocked, and chunking them is both safer and smoother on bandwidth. Erasure coding will likely wind up costing a bit more overall bandwidth, but each message will be more consistently sized. Given the wide range of Signal's deployment posture, that is probably a wise tradeoff to make. I would expect that Apple has a bit more control over their networks and are in a better position to deal with adversaries attempting to actively block their re-key updates.
Is iMessage even relevant since the vast majority of Apple users have iCloud backups turned on without E2E? E2E backups are opt-in because Apple can't help you recover your data if you turn it on.
Given that, Apple can already decrypt messages of users, if so requested by law enforcement and intelligence agencies. No fancy quantum breaches needed.
Im feeling pretty dumb even after reading the tldr. Can anyone who is well versed in this explain how this is better or safer? I read about the time, will it now be slower to send messages?
Sure.
In the standard practical analysis of quantum threats to cryptography, your adversary is "harvesting and then decrypting". Everybody agrees that no adversary can perform quantum cryptography today, but we agree (to agree) that they'll plausibly be able to at some point in the future. If you assume Signal is carrying messages that have to be kept secret many years into the future, you have to assume your adversary is just stockpiling Signal ciphertexts in a warehouse somewhere waiting so that 15 or 20 years from now they can decrypt them.
That's why you want PQ key agreement today: to protect against a future capability targeting a record of the past. (It's also why you don't care as much about PQ signatures, because we agree no adversary can time travel back and MITM, say, a TLS signature verification).
To understand the importance of a PQ ratchet, add one more capability to the adversary. In addition to holding on to ciphertexts for 15-20 years, assume they will eventually compromise a device, or find an implementation-specific flaw in cryptography code that they can exploit to extract key material. This is a very realistic threat model; in fact, it's of much more practical importance than the collapse of an entire cryptographic primitive.
You defend against that threat model with "forward secrecy" and "post-compromise security". You continually update your key, so the compromise of any one key doesn't allow an attacker to retrospectively decrypt, or to encrypt future messages.
For those defenses to hold against a "harvest and decrypt" attacker, the "ratchet" mechanism you use to keep re-keying your session also needs to be PQ secure. If it isn't, attackers will target the ratchet instead of the messages, and your system will lose its forward and post-compromise secrecy.
I think this used to be true. Now one problem is that a Signal message goes through this whole forward secrecy protocol, but the receiving device has some probability of uploading it to the cloud with a static key that never changes.
You don't have to enable the Signal backups feature, but you have no way of knowing whether the recipient of your messages has. One person in a group chat with that enabled will undo all of the forward secrecy you're describing.
The static symmetric key is fundamentally different from an ephemeral asymmetric key. We've no indication that symmetric encryption is vulnerable to "store now, decrypt later" attacks when used with a sufficiently long key, which Signal has. Non-post-quantum asymmertic cryptography is vulnerable to "store now, decrypt later" attacks, which is why forward secrecy is needed.
The backups feature doesn't open up any new vulnerability that didn't inherently exist in sending messages to someone else you might not fully trust. One person in a group chat can also take pictures of their phone's screen & upload your messages to the public.
I think they're making a point that is broader than PQ and a more general complaint about Signal's direction.
Images can be modified, won't these essentially be signed as verifiably coming from the sender, or is cryptographic proof of that thrown away in what they store?
This is no different than if recipient of the secure message shares the message in plaintext. The problem is a discipline problem not a technology one, and the solution is the same in both cases.
There's a difference between what Signal does in the app and a manual action a user performs outside of the app. It is not realistic to expect that people will see a feature Signal has built for them in the app and understand the underlying implications to "post compromise security" and "forward secrecy" that it may have.
The expectation is that what happens inside Signal is secure, and the features Signal provides are secure. If the idea is that nobody is going to enable this feature, then why build it? If the idea is that many people are going to enable this feature, then this entire cryptographic protocol is meaningless.
These things can still be used as evidence. The process used by the police of a rogue country (or any other adversary) isn't a cryptographer's highly technical wet dream or nightmare. They simply look at the screen of your phone saying you sent or received a message, and as far as the adversary is concerned, that proves you sent or received it. Even if you didn't. (Actually, they use Cellebrite and just trust whatever the Cellebrite analyzer outputs, which is basically what your screen would have said)
I've yet to see a protocol that lets you convincingly insert fake messages into both sides of your own chat history, especially in a way that isn't detectable by say, sqlite rowid order, but that would be an interesting idea for where to take this sort of thing.
Those are the breaks though when catering to a large audience with wildly differing threat models. Do you throw away users that are looking for a vague sense of security so they run off somewhere else less secure because you lack some feature?
If you are just looking for "secure(TM)[X]", you are making a mistake somewhere anyway.
If your life or livelihood depends on it, you learn what the impact of every choice is and you painstakingly keep to your opsec.
Somewhere between the two user action becomes a necessity. You need to judge where that point is for you and take responsibility for it because nobody else can guarantee it.
At the very least they should have excluded any chats with disappearing messages enabled from being included in backups.
With disappearing messages off it was already reasonable to assume that a compromise of a counterparty's phone would result in exposure of all previous messages, so enabling backups wouldn't expose you to new risk.
That would cater to those who want to keep their chat history forever without exposing those with disappearing messages enabled to new risk.
The history of Signal has been to provide the security properties we're talking about without users having to think about it or understand. To suddenly remove forward secrecy is a very big change, and it isn't one that they seem to have acknowledged or documented. Like this blog post: they are making an announcement that they have a "post-quantum ratchet," when they have effectively removed the ratchet. It's theater.
I think you missed the point entirely. You can't have security without thinking about it. You can have vague sense of security, which is the theater you are talking about.
Show me a company anywhere that can provide security without user thought and deliberate action. It's a fantasy to believe anything you don't have to think about isn't theater. Hell, if you aren't thinking about it, you're one of the actors in that theater.
I think you’re right.
But practically, it probably has more risk as people bypassing employer or legal controls think it’s “secure”. So they have conversations that they wouldn’t have.
It's a technological one when the feature is offered to laymen for their convenience.
The security problem that a messaging app like Signal solves is NOT: Allow a person to secure their communication against eavesdroppers.
It solves the problem: How can a group of people (two or more people) securely communicate with each other.
The group has to mutually decide their risk profile, and then decide which features of the application to use. And each person in the group has to decide whether they can trust others in the group to follow the agreed upon opsec. Signal cannot solve these social problems.
Historically as long as everything remained "in the app," it was secure. It's an easy assumption to make and communicate to others. Now it's more complicated: there are things that people can unwittingly do "in the app" that make it less secure.
AFAIK, it has the same security as before. Perfect forward secrecy means that if someone starts recording encrypted messages in transit and two years later obtains an encryption key, they cannot use that key to decrypt the messages they recorded earlier (because of re-keying).
On the other hand, if an adversary captures one of the group participants' phone and breaks device security, and the chat was recorded on that device, then they can access all recorded chats. By the same token, no cryptography can protect against a malicious group participant who records messages.
In the same scenario, cloud backups seem to merely imply that the same adversary can obtain the cloud backup key and therefore decipher the cloud backups if they get their hands on it. They won't need that, however, since the group chat history is already stored on the device. If no chats were recorded on the device at all the situation would be different.
You also have no way of knowing when someone you're chatting with screenshots your messages and uploads them to Imgur.
I jest, and Signal's support for backups do really increase exposure to this risk, but just trying to say its a matter of degree not a fundamentally new change. People that have been using sigtop[0] to backup their Signal messages to plaintext also create the same exposure risk.
[0] https://github.com/tbvdm/sigtop
I don't think that's quite right. PQ attacks focus on the "trapdoor" functions in asymmetric cryptography, _not_ the symmetric encryption that happens after key negotiation. The current concern is that a future attacker could unwrap the symmetric key, not directly attack the symmetric encryption that is used for something like backups.
(Note: I didn't actually dig into the backup implementation, but my guess is that it's more of a KDF -> symmetric design, rather than the sorts of asymmetric negotiation you'd find in multi-party messaging.)
If the app takes your disappearing message, encrypts it with a static key that never changes and is never deleted, and uploads it to the cloud, then the message is never truly "disappearing." A "post compromise" event will allow the attacker to decrypt that ciphertext at any point in the future. All of this ratcheting is undone by backups.
Disappearing messages were never a real thing in the first place. You can have a gentleman's agreement that the person you send your message to will delete it after reading it, there's no way to guarantee anything beyond that.
(Fair point though that probably "disappearing" messages shouldn't be included in backups since that obviously prevents them from being deleted. Idk if Signal implements that or not.)
Disappearing messages are an opsec feature for trusted counterparties, not a cryptographic feature. They are very much a real thing.
> encrypts it with a static key
What type of static key? If it's just a big symmetric key that isn't derived from an asymmetric handshake of some type then no, that's not our current understanding of the PQ threat model.
Part of the premise of FS/PCS is that "shit happens" to compromise keys even if the underlying cryptography is strong, so if you want a coherent end-to-end FS/PCS story, the claim would be that you need to be ratcheting everywhere.
Definitely, but when we're running around sprinkling PQ algorithms all over the place, it's on top of the asymmetric bits, not replacing the "boring" stuff like your symmetrically encrypted backups. Shit certainly does happen, especially where key management is involved, but I'm not sure I agree that offering an encrypted backup feature is necessarily undoing the FS/PCS story.
edit: Well, let me argue with myself for a moment. I don't think offering an encrypted backup feature undoes the PQ story. But FS/PCS is weakened, sure, since we're talking about all types of shit happening, not just currently known (or strongly theorized) attacks.
I think they point they're making doesn't have much to do with PQ.
Yes, if Signal has effectively removed ratcheting and forward secrecy from the logical "encryption protocol" by encrypting all messages (even disappearing messages) with a single static key that never changes for your lifetime and sending them to the cloud, then all this talk about "post-quantum ratchets" is theater. There are no ratchets.
I think it's a valid point but also that it assumes a lot about the threat model that can be disputed, so your "theater" point is not well taken.
I'm slightly confused about the PCS part. If I've understood correctly the new key is derived from the old key + some kind or message header. If the attacker has access to a key and messages encrypted with it, can't they read the shared secret used for key exchange and use their existing key to generate the new one? Or is this only possible with ECDH and not KEM?
The new one is randomly chosen (with the randomness coming from both parties, and then combined using ECDH and/or KEM). So you cannot predict it from previous key material, pretty much by definition.
They also don't know the random elements used in previous headers, since they're thrown away a few rounds after the message was decrypted.
What is the state of PQ symmetric crypto? My layman's understanding is that 128 bit AES is known to be broken by a quantum computer and that 256 AES may be OK but that isn't certain? Is this an additional vector for the "harvest and wait" strategy in the future?
128-bit AES is fine. To run Grover’s algorithm against it you’d need to cover the moon with qubits.
which algorithm are you referring to?
> My layman's understanding is that 128 bit AES is known to be broken by a quantum computer
Weakened, not broken. Quantum computers turns 128 bit AES into 64 bit equivalent. Which will still be extremely difficult for quantum computers due to the large computer size/number of steps required.
And it's 64-bit equivalent in a way that's inherently impossible to parallelize, so 2^64 sequential quantum operations. Those operations are much, much slower than classical ones.
You can trivially parallelize Grover's search by assigning each quantum computer it's own search space.
They still take the same amount of time to run it. You don't get a result by running for 1/n of the steps, so adding more QCs lets you attack more keys at once but doesn't let you attack any given key any faster.
Yes, but then you give up the advantage that Grover's gives you in the first place. The advantage is sqrt(n). You are reducing n by parallelizing.
Well, you get sqrt(n / N) as a result. It works like any other parallel computation.
E.g. if you have 256 quantum computers, then each one of them needs to search only 60 bits of the key space to crack a 128-bit key (each one of them will only need to search 2^120 keys).
It's not really going to make much difference with near-future quantum computers. Especially since Grover's algorithm _has_ to complete all the 2^60 steps to produce a reliable result, you can't just run a quantum computer for a while, stop it, and then restart it.
ah ok, thank you. Starting to make sense now
>> Forward secrecy is somewhat overrated in end to end encrypted messaging. Most people do not want a truly off the record experience but instead keep their old messages around indefinitely. As long as those old messages exist and are accessible to the user they will be just as accessible to any attacker that gets access to the secret key material.
On a more serious note, if a quantum computer can break a key, a task requiring exponential complexity with key length on a classical computer, then breaking N keys is only a negligible additional cost in comparison.
So it kind of feels like it’s overrated in this case to be honest :)
Their existing post quantum encryption didn't do post compromise security (PCS) against quantum attackers. This new one does.
I am excited to finally know what they mean by PCS after reading this article. It means that the session keys from their key agreement scheme (n ratchet) are generated new so an attacker doesn't get them again after a fairly specific sort of compromise. So from that I get that the off the record (OTR) protocol also has PCS. Which is a bit disappointing, I thought that they had come up with some new concept.
This key agreement doesn't happen that often. So a user isn't going to notice any slowness even if it was significantly slower.
thank you for the explanation
From the article:
> "What does this mean for you as a Signal user? First, when it comes to your experience using the app, nothing changes. Second, because of how we’re rolling this out and mixing it in with our existing encryption, eventually all of your conversations will move to this new protocol without you needing to take any action. Third, and most importantly, this protects your communications both now and in the event that cryptographically relevant quantum computers eventually become a reality, and it allows us to maintain our existing security guarantees of forward secrecy and post-compromise security as we proactively prepare for that new world."
[dead]
I can't believe that they named their protocol SPQR. It's the Latin abbreviation for Senatus Populusque Romanus. https://en.wikipedia.org/wiki/SPQR Love it :)
Yes, very clever. I am familiar with SPQR as a common tattoo on Roman legionnaires from the (excellent) BBC miniseries "Rome". https://en.wikipedia.org/wiki/Rome_(TV_series)
Is that what Maximus tried to carve off in Gladiator?
Good timing. My local cinema just ran Gladiator a couple nights ago and I popped by, it still rocks.
And yes, that's what he scrapes off his arm right after being captured by slave traders.
There’s something very Ozymandian about their invoking SPQR for a future-proof protocol
Didn't that empire last over a thousand years? Why is it ozymandian? More than we can say for the current one
Don’t forget the Byzantine Empire was the continuation of the Roman Empire.
I’m not sure if they still SPQR’d though.
Update: it appears to have fallen out of favour by 300
https://www.reddit.com/r/AskHistorians/comments/1jdrpz/did_t...
From a comment from a 12 year old Reddit post, 12 years being 0.5% of the span of the Roman Empire.
Pre-dictatorship, the Roman Republic was one of history's longest-lasting democracies:
https://www.broadstreet.blog/p/the-democratic-institutions-o...
TIL Ozymandian. Great word. Love it. Thanks!
Lol. You would only see this comment on Hacker News. Reminds me of an old comic I read on how mathematicians memorize their locker numbers. "1975? Oh that's easy. It's just the square root of 3,900,625!"
Ever since I've heard of the meme that "modern men can't spend 24 hours without thinking of the Roman Empire", I haven't been able to escape it, even on days where my only contact with the outside world is HN.
I guess it's like a curse, once you've heard about it you're doomed.
And for anyone finding out about it just now, alea jacta est
There used to be some SF Italian restaurant that showed first if you Googled "SPQR." Their SEO was stronger than Rome. I don't even live near there.
I think this meme has bumped the real SPQR back to the top.
I need an faq or something then, to figure out what's wrong with me for never thinking of the Roman Empire. Except now then.
It's only a certain type of man that they are talking about. We are not that type of men I guess. Can't say I know anyone what that problem to be honest. And yes, I have heard that saying before. Didn't work then and doesn't work now.
It's extremely easy if you're immersed in Southern European culture.
Moru -> Flag of Sardinia, whose Wikipedia page incidentally I was reading yesterday (the Four Moors, "is cuatru morus") -> Sardinian language -> grammatically still the closest language to Latin -> the everlasting glory of the Roman Empire
---
Reminds me of the fantastic, unreleased Monty Python sketch about memory association: https://youtu.be/KnpY46lOTX4?si=3Yb17jvGp-1vn6de&t=2058
Also, Monty Python -> The Life of Brian -> the everlasting glory of the Roman Empire
I just lost the game
ugh
Join the club of people who acknowledge that there's much more interesting history than that, and you'll suddenly forget all about Rome.
For me it's not so much what's interesting as what affects my day to day. I love Chinese history but I'm unlikely to come across anything today with origins in Chinese law, or traverse the path of a Chinese road, or use an interesting word with a Chinese etymology and an associated story from old China.
I love learning new history and I'm open to suggestions. Any less-trodden paths you'd recommend?
For national history, Chinese is probably my favorite by far.
May I suggest you do a domain-specific history dive, such as the history of computing, the history of science or some other subject you may enjoy more. That's the real good stuff.
It's so funny to see this be a worldwide phenomenon. As someone who grew up playing in the ruins of Roman temples & villas and was obsessed with it as a child, it almost feels like people are talking about "some other Rome".
I grew up in a school system which taught us about "our ancestors, the Gauls"...
Which is fun if you're an Asterix fan, but one day you end up asking yourself - wait, we're in an ex-French colony here, but how much Gaul blood does anyone have in this place really?
Thank you for reminding me, this is so fun to have bobbing around in the back of your mind! :D
For this particular one, you could easily see that comment on any community with a sufficient number of Asterix fans. Banners and standards with "SPQR" written somewhere were common enough that they should produce a Pavlovian reaction.
Or any community large enough to have people who have, y’know, visited Rome IRL?
I was delighted to see manhole covers with SPQR on them in Rome.
Visiting Rome IRL? That requires money... :')
spqr is a well-known phrase
It's something collectively known as INRI or CCCP.
[dead]
COOL
Or, maybe, it just sounds like "speaker", because they are a chat app? ;P... not everything has to be framed as a Roman conspiracy.
It’s not a conspiracy, it’s a pop culture reference. Very unlikely it’s unintentional, given that Thinking About Roman Empire was a fairly notable meme of ‘23/‘24 (https://knowyourmeme.com/memes/how-often-do-you-think-about-...).
Could be not a primary cause for the naming - only authors can tell - but I doubt they missed the reference entirely. It’s just way too obvious.
I am struggling to believe that the Roman Empire reference for this acronym is "so obvious". I do know about the meme: in fact, what struck me so hard about this is how, for a protocol where you'd almost expect it to be hard for them to avoid the acronym "SPQR" (as, even if it were not Sparse, it is made by Signal; I could even see them having started with Signal and decided to remove their brand from the acronym), there are not one but two top-level posts on Hacker News where "speaker" seems to have wooshed over their head and somehow this extremely niche acronym from the Roman Empire is clearly the reason why this is called SPQR. Is the tech community on Hacker News really this stereotypical?
If you've learned even a little about the history of Rome then you'll quickly bump into SPQR, Mary Beard's recent popular, and very good book on the Romans it titled "SPQR", in the city of Rome you'll see SPQR used all over, in films when Romans are depicted, SPQR is always there. While not everyone will have a background where it's familiar, it's also not at all obscure. If you're not familiar with the Romans you won't know, but lots of people like to learn about the ancient past since it's really interesting to some types.
Just piling on to say it's super obvious to me, and I didn't even know of this meme before.
I dunno, SPQR is fairly obvious for anyone who covered Rome in elementary or middle school history.
Beyond that, if you’re from the part of the world where asterix comics were popular (mostly thr francosphere, but also europe more broadly), it really stands out.
That’s all to say nothing of people who’ve got formal higher education in history or even the classics.
I'm in the opposite position: known about SPQR for decades but never heard of this meme and clearly missed it.
Can you explain the meme please because I didn't understand the hits I got when I just googled it.
Caesar cipher anyone? Romans knew (bad) cryptography.
I struggle to see how this could be a conspiracy in any form, but maybe you can make it more clear for me? As I see it, it would make perfect sense for a democracy driving app to focus on “Senate and People”, the fact that is sound like "speaker" simply makes it more brilliant.
Strength and Honor
Scotch and soda
Before, and way before.
Wow, this is one of the most well written cryptography articles I've ever seen.
I consider myself a fairly experienced software engineer with a moderate amount of professional experience in private sector encryption, so I'm not completely out of my element, but many articles along this vein have my eyes glazing over halfway through the breakdown.
This one was actually easy for me to follow the entire time for once, despite explaining something I'm not familiar with.
Signal is lacking a crucial safety feature. To cover some background, it is necessary to set "Who can see my number" and "Who can find me by number" both to "Nobody", as this lowers the chances of spam messages and attempted hacks. Once these are set, the only way for someone to start a conversation with you is if they know your Signal username or QR link, both of which you can set in your Profile. The issue is that your link can be saved unsafely by your Contacts, and can be used multiple times, also by others, leaking it to hackers who can then send you unsolicited messages to compromise your device. The safety feature that would be good to have is to allow someone to contact me only via a one-time use link that cannot be reused by anyone.
This sounds like an excellent feature request that would shore up their anti-abuse endeavors more than them "lacking a very basic crucial safety feature".
Which of the so-called Signal competitors have implemented something like this already today?
This is really impressive, especially the way they've used formal verification. Great work.
This is a good time to remind everyone the technically sound choice of hybrid crypto is discouraged by NSA. I wish they didn't. PQ is a major overhaul to crypto systems. Setting aside the risk of yet-to-be-discovered algorithmic vulnerabilities, there is a huge risk of implementation mistakes leading to compromise. Mature classical crypto should be used as a backstop by deploying PQ in hybrid mode along classical crypto.
Isn't the point of hybrid crypto due to the possibility that this fancy new quantum resistant algorithms have a fatal flaw? If so, I could understand why NSA has that stance (if you don't trust the crypto its useless), but realistically it's a good idea.
That's not how we approach security. We don't think in terms of 'Trust' in algorithm. We think in terms of risk management. It's not uncommon for new algorithms and approaches to have algorithmic or implementation flaws. That is a risk. One of the mitigations we often consider is adding another layer of defense.
Whose is "we", because for example, the DoD doesn't agree with you. It's very much either crypto is "trusted" or useless.
See NIST with the whole FIPS-142/3 debacle where they outright state that "non-certified" crypto is no better than plaintext.
Source for the NSA's stance?
CNSA 2.0 FAQ: https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI...
Sparse Post-Quantum Ratchet, or SPQR. Someone at Signal is a Roman history enjoyer.
How often do you think about the Roman Empire?
Not very. But the Roman Republic…
Or Asterix
Or, just maybe, they are merely an enjoyer of chat apps (SPQR -> "speaker").
The (very weak) Caesar cipher was used in ancient Rome though and cryptography in general way before. It could be a silent nod to how far our achievements have gone and that encryption is a basic human desire since millennia.
Or maybe this SPQR is weak too /s
I’m still not sure how do you even compromise a key without also compromising message history. The keys are stored on-device, along with associated history. If attacker has access to the keys, they also have access to all the previous messages stored on the same device. Unless you’re using auto-delete with short period on all your messaging, which I would think is not common, it would seem that you gain nothing by ratcheting.
Sono pazzi, questi Romani
Die spinnen, die Römer!
I would really like to see some modern comparisons of the Signal protocol to Matrix, MLS, etc. since it's hard to keep up with everything but it seems like things are still moving.
At high level, and off the top of my head:
“Signal Protocol” is a somewhat fuzzy description of whatever Signal does at a given point in time. Historically, this meant Double Ratchet, which is O(N) with the number of devices in a conversation. This uses elliptic curve cryptography to exchange keys (X25519); it was then extended to be PQ via PQXDH by adding Kyber512 to the initial key exchange, and has now also been extended to be PQ for subsequent ratcheting by mixing in the SQPR ratchet. Signal itself is obviously centralised; 3rd party implementations are forbidden; the implementation is AGPL+CLA. It has good metadata protection thanks to hiding group membership from the sender and “sealed sender” to hide the sender from the server too.
Matrix is an open standard communication protocol. It supports pluggable E2EE, although the only protocol in production right now is Olm+Megolm. Olm is an implementation of the Double Ratchet, and Megolm is a per-sender ratchet used to share keys with the group. The current implementation of Olm from the Matrix Fdn is an Apache-licensed project called vodozemac. This sprouted experimental PQXDH support in Jan 2024 (https://github.com/matrix-org/vodozemac/pull/120). Matrix is decentralised; anyone can run a server; multiple heterogeneous implementations are heavily encouraged. More metadata is exposed to the server than Signal - for instance the server can see the group membership, and key-value data is not encrypted (although we’re working on that right now: https://element.io/blog/hiding-room-metadata-from-servers/). Also, group membership is controlled by the server; clients warn when if unexpected users/devices are added, but the protocol does not forbid it. We’re also working on fixing that, but it is a huge change.
Finally, MLS (RFC 9420) is effectively a key exchange and group membership protocol. You can use it to add E2EE to messaging systems as an alternative to the Double Ratchet, while also using it to control group membership. By default it uses classical elliptic curve encryption, but there are proposals to make it PQ. It’s more performant than the double ratchet in that calculating new ratchets is O(log N). However, joining groups is still O(N). It’s much less mature than the Double Ratchet, more complicated, but benefits from significant cryptanalysis and formal verification thanks to being an IETF standard. It also seems to get significant hype just by being an IETF standard. It requires a centralised component to sequence MLS group operations, so to use it in systems like Matrix you have to extend it to be decentralised (see arewemlsyet.com). It doesn’t hide metadata from the server. It also doesn’t provide cryptographic deniability (unlike the double ratchet). It is not that widely deployed yet, although Google apparently uses it for RCS (presumably thanks to it being IETF and avoids any possible IPR questions over the double ratchet), which means it should be huge. Discord and Webex also use it for VoIP conferences.
Hey thanks, that's very helpful.
Its interesting to imagine that somebody [1] is already now capturing encrypted internet traffic and storing it all long-term, to then hypothetically in 40-50 years or something decrypt it and draw value from that information. I suppose to blackmail future politicians, learn military secrets, whatever.
[1] NSA
> Its interesting to imagine that somebody [1] is already now capturing encrypted internet traffic and storing it all long-term, to then hypothetically in 40-50 years or something decrypt it and draw value from that information. I suppose to blackmail future politicians, learn military secrets, whatever.
You don't have to imagine, there's literally a NSA datacenter in Utah for doing just that.
https://en.wikipedia.org/wiki/Utah_Data_Center
That's exactly what I was thinking about too, but I was to lazy to find the link, thanks ;)
It's hard to tell as someone not in the field, but quantum computing seems to be moving faster than that? I'm not sure I believe two years, but:
Harvard physicists working to develop game-changing tech demonstrate 3,000 quantum-bit system capable of continuous operation
https://news.harvard.edu/gazette/story/2025/09/clearing-sign...
PsiQuantum Raises $1 Billion, Says Its Computer Will Be Ready in Two Years
https://archive.is/AEuan
As someone not in the field it's hard to distinguish the "quantum startup raised x billions, claims quantum computing x years away" from "fusion startup raised x billions, claims fusion power x years away" headlines every few months for the past 10+ years.
Headlines like these are the outliers to the trend that thus appear more credible to me personally: https://news.ycombinator.com/item?id=45238481
Thanks for the link. I skimmed through the report that the article is based on. It tracks rising activity in quantum computing R&D in several areas. But at least in the executive summary, I didn't see anything about commercial applications one way or the other. It doesn't seem to make any predictions?
So, it's odd that the article summarized it that way.
> Overall, quantum processing units (QPUs) are making impressive progress in performance, but they remain far from meeting the requirements for running large-scale commercial applications such as chemical simulations or cryptanalysis.
Page 6 it's a quote
That's what I don't get - these folks must be more bullish than me on practical quantum computing. If you assume 20-30 years; there's no important military secrets left (what was China building in the late 90s?!) and how many politicians are in politics for that long?
> to blackmail future politicians
This seems to me the most valid reason. Any other secret is useless after 30 years.
This is actually disturbing, as the article suggests that all previous messages sent using Signal are decryptable with quantum computers. If there are people with, for example, selfhosted mailservers sending PGP encrypted emails to each other, then, while they have to worry about them not leaking out from the server either by someone hacking to it or someone sniffing the traffic with the encrypted messages beforehand, they know for sure that their messages are safe.
Meanwhile Signal users have been sending messages onto signal servers for years now, as far as I know they aren't sent directly through some p2p protocol. I don't know what their policy is about storing messages, and I believe that they have a lot of other countermeasures, but it still points to the problem with Signals centralized nature.
As far as they say, messages are deleted once delivered, or retained up to 45 days if not:
(source: https://signal.org/blog/a-synchronized-start-for-linked-devi..., dated Jan. 2025)It is possible for them to say that they deleted the messages without actually deleting them though. One has to trust a pretty big company in order to not worry about the messages actually not being stored anywhere.
I'm not aware of all techniques that Signal uses to somehow make the message anonymous even when if the encryption would have been broken, but sealed sender seems to be one of them:
https://signal.org/blog/sealed-sender/
So at least there's that. Unless the encrypted sealed sender messages aren't somehow being fingerprinted by the IP address of client and the timestamps of connections. Signal probably also says that they don't log these, but with self hosted mailserver I wouldn't have to trust them on that too.
> One has to trust a pretty big company...
Or a medium-sized (~50 employee) nonprofit, anyway.
Huh, it's true. I thought an organization that needs $50M yearly to function[1] would employ more people. Still, I think it's fair to call them "pretty big" looking on how much media exposure they get or their operating costs. Perhaps a bit misleading from my part with the "company" part, as I'm not english-native, every type of firm,company,foundation in my head translates to a "company", sorry about that, will be more clear next time :)
[1] https://www.wired.com/story/signal-operating-costs/
No worries, I don't think "company" is even technically wrong. But I do think given the nonprofit structure (and Moxie Marlinspike's track record), that there are fewer incentives for Signal to lie about its privacy guarantees than a messaging app backed by a commercially-driven big company.
Using PGP over self-hosted email servers won't help you against a post-quantum adversary. While people have discussed post-quantum extensions to PGP, it doesn't exist yet. Similarly, while post-quantum TLS _does_ exist, it was only just implemented in OpenSSL; I doubt Postfix supports it yet.
So you're in an even worse post-quantum situation with email, even if you end up with TLS-encrypted PGP-encrypted messages, you're still not post-quantum secure.
My point is that to this date everyone was not post-quantum secure, and only the people whom had their messages stored on their servers only can be sure that someone won't read their contents.
Also PGP emails were just an idea that seemed the most basic for me to illustrate an example of selfhosted encrypted messaging. Probably they lack more security features than just post-quantum, compared to the other messengers anyway :)
> If there are people with, for example, selfhosted mailservers sending PGP encrypted emails to each other
In good approximation, nobody does that.
Yeah, that's true. If they did though, then I think that they'd be more secure than with Signal, at least in this certain aspect of message storage.
Why do you need the mailserver to be self hosted? just pgp encrypt client side
In the scenario with mailservers with PGP encrypted messages I did intend the messages to be encrypted client side, perhaps it was not clear enough. When I selfhost my own server (and my trusted friend selfhosts his), I can be completely sure that the encrypted messages will not be dumped either through storage or while relaying them. If sent PGP end-to-end encrypted messages through, say, gmail, then I'm not 100% sure that gmail won't store these messages somewhere and decrypt them whenever quantum computing becomes available for them.
Can users write their own clients
Can users self-host servers
Ironically I can't access the web page, browser marks it as 'Not Secure'.
Post-quantum ratchets - cool.
Now if they could solve notifications not consistently appearing between iOS and android devices...
Fantastic news! Awesome that the Signal team was able to deliver another first-class security feature.
At first, I thought the article was published on an April Fools day...
I think they could use better moderation features.
What does that even mean.
user posts inappropriate thing in group chat. group admins cannot delete it for everyone.
There's no moderation because signal groups aren't 1:n they're 1:1.
The protocol doesn't even guarantee everybody in the group sees the same message.
people can see reactions :p they can also see when a mod adds or demotes a member
I thought signal used some form of XMPP?
No, it has always used its own protocol.
But apparently there is an XMPP extension that implements the Double Ratchet algorithm that Signal is based on:
https://en.wikipedia.org/wiki/OMEMO
Maybe my reading comprehension is failing me, but what does this mean for existing messages? I guess nothing of the have already been 'siphoned' to a 3rd party. As it couldn't retroactively apply to data not under Signals control of course..but what about existing messages already within their control?
[dead]
[flagged]
Is it true that Signal was funded by the CIA or is that disinformation to try to get people to mistrust it?
Well, for some reason they're not worried about metadata. And the agencies mostly collect metadata...
This is not true, though? https://signal.org/blog/sealed-sender/
(Yes, I am aware Sealed Sender is not perfect and still susceptible to statistical attacks.)
Strange that they are posting about the "signal ratchet" when they just removed it by launching cloud backups that use a static key? Since those cloud backups include disappearing messages, that feature completely undoes all of the forward secrecy in this protocol.
Signal can't protect you against the other party you are communicating with. They can backup the conversation, or screenshot it, or take a photo of the screen with another camera. They could also retell in their words what you sent.
You know (with pretty high certainty) that your conversational partner is using Signal. The security level of Signal affects your estimation of the security level of your partner.
That backup system presumably uses symmetric encryption, which is not nearly as vulnerable to quantum-accelerated attacks.
Yes, but you don't need a complicated ratcheting protocol if you've eliminated forward secrecy in other ways. This post is about "post compromise security," but there is already no post-compromise security after the cloud backups feature
Do you also think it's "strange" that they're introducing that (optional!) feature while also storing all the messages on your device? The cloud backup is strictly more secure than that on-device database. Their blog post on the subject also explicitly says it won't include disappearing messages that disappear within 24 hours.
It's not optional because you don't know whether the people you are communicating with have it enabled. One person in a group chat with the feature enabled undoes the forward secrecy for everyone in the group chat.
A cloud backup eliminates any forward secrecy. It used to be that in Signal, when you have a message on your device and it is deleted (or a disappearing message disappears), then it is truly gone and can never be recovered. Now with backups, since the key that was used to encrypt it to the cloud remains on your device, it can be recovered even after the message is deleted or disappears.
The only way to "truly" opt-out is to, as you say, set a disappearing message timer for <24 hours.
Yeah, and all of that's already true right now because messages are stored on those users' devices already. You'll be heartbroken to hear that those users can also take a screenshot of your disappearing messages and send it to anyone. There are fundamental limitations to what a messaging app can protect you from.
While the analog hole will always exist, and you can't make it actually impossible, Snapchat's quite good at that screenshot thing. Both platforms have APIs to prevent, or at least notify on the use of screenshot. It's weird that signal doesn't use any of them.
i know of ~3 currently working methods to take screenshots on snapchat
it isn't "weird that signal doesn't use any of them" because it does [1] use both, just not for giving a false sense of security to your correspondents
[1] https://support.signal.org/hc/en-us/articles/360043469312-Sc...
What are they, other than the analog hole?
Screen security so that I can't see the app on my phone in preview during app switching isn't the same thing as stopping screenshots.
this is the same argument as saying "you shouldn't have remote delete requests". Yes, people can screenshot or export. That doesn't mean you shouldn't have a nicety that generally works pre-compromise or pre-evil. Locks just keep honest people honest.
>but there is already no post-compromise security after the cloud backups feature
The feature is opt in, so I really don't see the issue here.
Does this mean we're any closer to getting editable messages?
10 edits in 24 hours. Been that way for ages.
Signal already has editable messages
We're about minus five months away.
I remember editing messages a couple of years ago. Am I missing something?
It's been 2 years https://signal.org/blog/new-features-fall-2023/
Oh wow, time flies.
Update your app please
I want signal to act as a transport bus. In particular, I want to give certain contacts permission to ask my phone for its location, so I can give my wife that ability without sharing it with Google.
Signal has solved the identity part, now encourage others to build apps on it.
(2fa via Signal would be better than SMS, too, though I know this may be controversial!)
> Signal has solved the identity part, now encourage others to build apps on it.
Doesn't the fact that nobody has built apps on it indicate the license (AGPL 3) is a real issue for its ecosystem?
I'm not seeing how you could draw that conclusion. The more likely explanation is that they are telling people not to build apps around it (and I assume thus the apis aren't well designed for adoption by other apps).
> This repository is used by the Signal client apps (Android, iOS, and Desktop) as well as server-side. Use outside of Signal is unsupported.
https://github.com/signalapp/libsignal
Isn't the lack of an SDK the problem, not the LICENSE?