Signal Protocol and Post-Quantum Ratchets
(signal.org)531 points by pluto_modadic 15 hours ago
531 points by pluto_modadic 15 hours ago
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?
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.
Join the club of people who acknowledge that there's much more interesting history than that, and you'll suddenly forget all about Rome.
I love learning new history and I'm open to suggestions. Any less-trodden paths you'd recommend?
Or any community large enough to have people who have, y’know, visited Rome IRL?
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?
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.
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...
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.
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?
> if they don't have a good way of enumerating other Signal users?
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
Replace "user ID" with "email address". Pretty much the same thing. But spam is a huge problem with email.
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.
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 via a phone number.
> an authoritarian governments too may take ownership of a number at any moment.
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
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.
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.
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
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.
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...)
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.
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.
I'm absolutely okay with having none of that. I hope they focus on making a secure and usable messenger above all else.
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.
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'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?
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.
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.
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.)
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.
>> 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.
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."
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.
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.
Can users write their own clients
Can users self-host servers
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
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.
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.
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:
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.
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.
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?
Post-quantum ratchets - cool.
Now if they could solve notifications not consistently appearing between iOS and android devices...
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?
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.
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
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.
Is it true that Signal was funded by the CIA or is that disinformation to try to get people to mistrust it?
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.
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.
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.
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 :)