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.
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.
Can you explain the meme please because I didn't understand the hits I got when I just googled it.
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
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 think this meme has bumped the real SPQR back to the top.
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.
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?
And yes, that's what he scrapes off his arm right after being captured by slave traders.
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.
https://www.broadstreet.blog/p/the-democratic-institutions-o...
[1] NSA
You don't have to imagine, there's literally a NSA datacenter in Utah for doing just that.
This seems to me the most valid reason. Any other secret is useless after 30 years.
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
Headlines like these are the outliers to the trend that thus appear more credible to me personally: https://news.ycombinator.com/item?id=45238481
So, it's odd that the article summarized it that way.
Page 6 it's a quote
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.
The feature is opt in, so I really don't see the issue here.
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.
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...
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.
it's a lost cause except maaaybe provisioning drm keys but even then, as you say, analog hole
re: screen security isn't the same thing - that's what i mean, signal does use those very APIs but not for a half-assed snitching feature
[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...
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.
Given that, Apple can already decrypt messages of users, if so requested by law enforcement and intelligence agencies. No fancy quantum breaches needed.
“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.
(Yes, I am aware Sealed Sender is not perfect and still susceptible to statistical attacks.)
Which of the so-called Signal competitors have implemented something like this already today?
Addressing future threats is good, but priorities should be different.
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
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.
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.
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.
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.
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
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.
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.
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.
I don't want everyone who knows my number to be just able to reach me.
Whitelist instead of Blacklist!
In many countries your SIM card is tied to you, which is a huge deal-breaker.
It's crazy how heterogeneous rules are inside the EU.
> identification via a phone number.
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
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.
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.
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?)
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.
https://news.ycombinator.com/item?id=39444500 Keep your phone number private with Signal usernames (2024-02-20, 1422 points, 890 comments)
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...
> the security problem
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
You can also lock registration of your device.
What is your security concern here?
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.
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.
> Impersonation
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 E2EERegistration lock expires in seven days or less. [1]
[1]: https://support.signal.org/hc/en-us/articles/360007059792-Si...
> Registration Lock expires after 7 days *of inactivity*
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
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
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 thereIt's something you'd want to avoid if your life, liberty or well-being are at risk if you're de-anonymized.
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.
This problem is honestly minor compared to teaching users to have opsec practices suitable against such a threat.
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.
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.
(source: https://signal.org/blog/a-synchronized-start-for-linked-devi..., dated Jan. 2025)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.
Or a medium-sized (~50 employee) nonprofit, anyway.
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.
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 good approximation, nobody does that.
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
and it's a deliberate choice that they are defending for seceral years now, ever since they removed the submarine sound.
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.
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...)
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.
> when you can drop a maps link.
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?
That's a fast on-ramp to an extremely shitty experience moving forward.
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.
Also, XML was the wrong choice. Pissed me off as a dev, back when I was doing stuff with ejabberd.
Disclosure: my team and I are actively working on improving xmpp, but in a rather orthogonal direction to general XSF council route.
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.
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.
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 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!)
Doesn't the fact that nobody has built apps on it indicate the license (AGPL 3) is a real issue for its ecosystem?
> This repository is used by the Signal client apps (Android, iOS, and Desktop) as well as server-side. Use outside of Signal is unsupported.
Now if they could solve notifications not consistently appearing between iOS and android devices...
See NIST with the whole FIPS-142/3 debacle where they outright state that "non-certified" crypto is no better than plaintext.
Can users self-host servers
The protocol doesn't even guarantee everybody in the group sees the same message.
But apparently there is an XMPP extension that implements the Double Ratchet algorithm that Signal is based on:
bilal4hmed•4mo ago
jerknextdoor•4mo ago
> "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."
upofadown•4mo ago
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.
bilal4hmed•4mo ago
tptacek•4mo ago
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.
ls612•4mo ago
twiggers•4mo ago
ziofill•4mo ago
dist-epoch•4mo ago
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.
SAI_Peregrinus•4mo ago
cyberax•4mo ago
upofadown•4mo ago
cyberax•4mo ago
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.
SAI_Peregrinus•4mo ago
a022311•4mo ago
Sesse__•4mo ago
immibis•4mo ago
bilal4hmed•4mo ago
elvisloops•4mo ago
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.
jt2190•4mo ago
elvisloops•4mo ago
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.
immibis•4mo ago
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.
jfyi•4mo ago
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.
elvisloops•4mo ago
jfyi•4mo ago
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.
C4K3•4mo ago
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.
heavyset_go•4mo ago
Spooky23•4mo ago
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.
ragona•4mo ago
(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.)
elvisloops•4mo ago
ragona•4mo ago
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.
tptacek•4mo ago
ragona•4mo ago
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.
tptacek•4mo ago
elvisloops•4mo ago
tptacek•4mo ago
Ajedi32•4mo ago
(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.)
tptacek•4mo ago
SAI_Peregrinus•4mo ago
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.
tptacek•4mo ago
cma•4mo ago
varenc•4mo ago
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
abdullahkhalids•4mo ago
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.
elvisloops•4mo ago
jonathanstrange•4mo ago
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.
aborsy•4mo ago
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 :)