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.
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
android emulator (i think bluestacks still works), web snapchat client + BetterSnap extension (you can even save the original media file!), on graphene it seems to detect screenshots but not video recording (likely not intentional, there was an open issue to block screenshot detection but no devs were interested iirc)
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
Oh interesting. Yeah, I mean, iOS has the API so it seems silly that they don't do anything about it there, but I guess if you support a diverse userbase like they have to, then user education is impossible and a false sense of security would be a bad thing to give to uaers
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.
Giving people a 64-character key also feels uncharacteristically crude for Signal. It's not realistic to hand people 64 characters and tell them to “store this securely.” Most people will screenshot it, and those screenshots will end up in unencrypted cloud backups.
That's less of a problem when the backups are local, because access to the local backups implies access to the device, but if the backups are in the cloud with no forward secrecy, this seems like a huge security backslide for Signal.
I get your point but is a large set of dictionary words or 5-digit numbers (see the current backup passphrase) so much better? At the end of the day, recording entropy will always be cumbersome and there is no way around it.
> Most people will screenshot it, and those screenshots will end up in unencrypted cloud backups.
At least on Android apps can disable screenshots, though, which might be a simple way to deter people from doing that?
I think a large set of dictionary words are likely more user friendly. I think most people will have a lot more confidence on their ability to transcribe words to/from paper more accurately than a bunch of numbers - better built in error correction, etc.
The implementation feels uncharacteristically crude for Signal. Instead of seamless protections, you just get handed 64 characters you’re told to “store securely.” That’s not realistic: most people will screenshot it, and those screenshots will end up in unencrypted cloud backups.
Sure but the key is still in a separate location from the backup. Signal can't decrypt the backup and if Signal is hacked someone would still need to get your screenshot to decrypt the backup. Not perfect but far better than an unencrypted backup.
Signal is known for its cutting-edge cryptographic protocol, but this feature has the effect of throwing that out the window and replacing it with a single static key. If a device with this enabled goes through the whole advanced protocol to receive a message (double ratcheting etc), then turns around and uploads it back to Signal’s servers with a static key, isn't that a roundabout way of replacing all of signal's protocol and its forward secrecy with a static key that has no forward secrecy?
They’re calling it "opt-in," but it doesn't look like that's actually true? You can’t know whether someone you’re talking to -- who may not understand the implications -- has enabled it. In group chats, it looks like a single person turning it on eliminates signal protocol for everyone in the chat.
Based on this post, the only way to actually opt out of this is to force disappearing messages to be enabled for a time under 24 hours for every chat, which is pretty frustrating.
Signal already lags other messengers in reliability, speed, and features. The reason people use it is for its uncompromising security. Shipping something that weakens that foundation undermines the reason people use Signal.
> They’re calling it "opt-in," but it doesn't look like that's actually true? You can’t know whether someone you’re talking to -- who may not understand the implications -- has enabled it. In group chats, it looks like a single person turning it on eliminates signal protocol for everyone in the chat.
TBF Signal already supports automated key-protected backup (and has for years), it's just stored on-device, but there's no way to know what the other party is doing with that on-device backup.
Sure, but you already have no way of knowing which one the other parties in your chats are doing.
I already sync my Signal backups to the cloud, because that's the most practical and time/cost-effective way to have a 3-2-1 backup system for my chats.
There's a difference between someone in your chats acting adversarially and Signal supporting/encouraging adversarial behavior as part of the way the app works. If Signal published a change to the protocol that removed forward secrecy, we wouldn't consider it a non-event and say "well anyone could screenshot messages anyway," even though that may be true. They're calling this "secure backups," but in truth it appears to reduce security
I don't think it's appropriate to call someone you're talking to with disappearing messages turned off making a backup of the conversation so they have the (non-disappearing) message history if they drop their phone in a lake as "adversarial behavior".
If you don't want them to have a history only communicate via disappearing messages.
This post says disappearing messages are included in the backups. You have to enable disappearing messages with a timer of less than 24 hours to ensure that you can opt out.
Sure but the backup happens each day and then gets overwritten/deleted when the next days backup happens (which then deletes the disappearing messages that are expiring express the next backup). It just ensures you have access to any messages that you’re supposed to have access to according to the timers on said messages.
That's not how forward secrecy works. Ciphertext isn't "deleted" unless the key used to encrypt it is also deleted. That's the point of Signal's cutting edge protocol. This undoes all of that.
I'd also wonder where this shared encryption key for message "backups" is stored. If it's available on all of my devices, I suspect it would be available on other devices as well?
The article says it is generated on your device and they don't have a copy. Sounds like a public-private keypair where you are responsible for managing the private key.
got it. doesn't Signal already have on-device keys with a session ratchet? why not back those keys up so one can decrypt the entire history on any device?
afaik the key material is regenerated for every message. new keys can be derived for every subsequent message you send, but only until you get a reply, then a new key exchange takes place. And the key material for message m1 cannot derive keys for the messages that came before m1. If the old key material gets properly deleted then there is only a very small window of compromise. backing up those keys would defeat the purpose of the ratchet.
At the core of secure backups is a 64-character recovery key that is generated on your device. This key is yours and yours alone; it is never shared with Signal’s servers. Your recovery key is the only way to “unlock” your backup when you need to restore access to your messages. Losing it means losing access to your backup permanently, and Signal cannot help you recover it. You can generate a new key if you choose. We recommend storing this key securely (writing it down in a notebook or a secure password manager, for example).
i missed that paragraph, thanks for pointing it out. i wonder what algorithm they're using here, and if we could use third party tooling to decrypt these messages on a local computer? it might be a pathway to some cool experimental third-party Signal apps
> They’re calling it "opt-in," but it doesn't look like that's actually true? You can’t know whether someone you’re talking to -- who may not understand the implications -- has enabled it. In group chats, it looks like a single person turning it on eliminates signal protocol for everyone in the chat.
People already can export backups of the messages they receive, in plain text, and publish those on the Internet if they way.
Signal's threat model has never included "you are directly messaging an adversarial party and expect to retain control over redistribution of those messages".
> Signal's threat model has never included "you are directly messaging an adversarial party and expect to retain control over redistribution of those messages".
Well, no, that doesn't contradict what I said at all. That link isn't about treating the recipient of your messages as an adversarial actor. The recipient can still choose to enable it, if they want to provide Microsoft access to the messages they receive.
I think the difference is that this is all happening in the app as a supported flow. If simply enabling a toggle in Signal (likely without understanding the implications) is now considered "adversarial," then I think that's a problem
It seems plausible that the protocol could be designed such that the device doesn’t know the recovery key. The key serves three purposes: (a) identifying the backup when a user tries to restore it, (b) authenticating that user to the restore API, and (c) allowing the user to decrypt the backup.
(a) is much simpler if there is a fixed identifier of a user, but that identifier doesn’t need to be the entire key or even part of it — it could be some derived material.
(b) isn’t strictly required but I would be very uneasy about allowing anyone who stole a user’s device to download even the ciphertext of that user’s future chats. Also, there’s an obvious issue that even the ciphertext reveals something about the amount of activity from the user.
(c) requires that the restoring user hold something like a private key, that said key can be derived using the restore code, and that the user’s device does not know the private key.
One straightforward-ish solution would be for the user’s device to generate, once, a key pair, a user ID, and a backup API key. (The ID and API key could be generated server-side.). The restore key is (user ID, private key). The device retains (user ID, API key, public key). To upload backups, the device establishes a secure session, sends the user ID, proves knowledge of the API key, uploads a backup, and receives a new API key. The old API key is revoked.
This means:
1. The device does not retain the ability to download future backups.
2. A clone of a device (say id the device leaks its secrets somehow) cannot be used to upload new backups on an ongoing basis without being noticed because of the API key rotation.
>Signal is known for its cutting-edge cryptographic protocol, but this feature has the effect of throwing that out the window and replacing it with a single static key
The exfiltration of which is as easy as exfiltration of database on device. You're not running an IDS scanning 100% of your device LTE traffic in case that happens.
>isn't that a roundabout way of replacing all of signal's protocol and its forward secrecy with a static key that has no forward secrecy?
It's opt in. And again exfiltrating the backup key is as easy as exfiltrating your messages from your device.
>You can’t know whether someone you’re talking to -- who may not understand the implications -- has enabled it
You can't know if you're talking to an informant or if your contact is running Android that's receiving security updates or if it's a zero-day on wheels, either. Tech doesn't solve human problems.
It's not opt in: signal protocol for a group chat is eliminated if one person in the group chat turns this on, whether or not you do. Communicating with someone who acts adversarially is different from Signal itself adding features that are adversarial.
If you're in a group and someone is backing up the messages, it only affects your messages in that group. All of your other chats are still secure as long as you're not using the backup frature.
You (and Signal) can't control how the recipient handles your messages if you're not using disappearing. They could be copying and pasting your messages or taking screenshots. I don't see how the backup feature is any different.
You can't have forward secrecy for something you want to keep for an indefinite interval. How many Signal users actually achieve forward secrecy anyway? They tend to want to keep their old messages available to them.
They are owned by Twitter. It's basically a spyware approach - Twitter wants to be able to track users across apps, but there are no cookies or tracking pixels in the mobile app ecosystem.
Instead, they get developers to bundle this SDK into their apps, which subsequently reports back to Twitter, enabling Twitter to track users across the app ecosystem.
I think you're correct to be concerned about how they make money, because the answer is unfortunately by spying on your users.
I wonder why they decided to send codes over SMS that we have to manually type into a browser instead of a one-tap push notification to the Twitter app on the phone? Or Google Authenticator?
SMS is a great option since it supports people with feature phones. But, IMO, SMS should be a fallback, rather than the primary option, since it is network-reliant and subject to a number of attacks that app-based authentication is not subject to.
I'm not using SMS on any of my 2-step-auth services because I don't want to be locked into owning that phone number (and worry about roaming charges if I travel).
Google Authenticator or similar apps are my first choice.
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.