5 ms·

I can't believe Signal is doing this. Signal is known for its cutting-edge cryptographic protocol, but this feature has the effect of throwing that out the win

I can't believe Signal is doing this. 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.

chimeracoder 1y ago
> 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".
- elvisloops 1y ago
  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
- 3np 1y ago
  > Signal's threat model has never included "you are directly messaging an adversarial party and expect to retain control over redistribution of those messages". On the contrary. https://signal.org/blog/signal-doesnt-recall/?pubDate=20250809 https://signal.org/blog/signal-doesnt-recall/?pubDate=202508...
  - x0x0 1y ago
    Huh? That is very explicitly about preventing the migration of your signal messages into Windows Recall. Not the threat model you discuss.
  - chimeracoder 1y ago
    > On the contrary 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.
Marsymars 1y ago
> 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.
- elvisloops 1y ago
  There's a big difference to me between storing it on device and someone else's servers.
  - fsflover 1y ago
    Why does it matter if everything is encrypted?
    - fsflover 1y ago
      Why am I downvoted? It seems actually encrypted, https://news.ycombinator.com/item?id=45171740 https://news.ycombinator.com/item?id=45171740
  - Marsymars 1y ago
    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.
    - elvisloops 1y ago
      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
amluto 1y ago
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.
maqp 1y ago
>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.
- elvisloops 1y ago
  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.
fastest963 1y ago
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.
upofadown 1y ago
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.

chimeracoder 1y ago

> 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".

elvisloops 1y ago
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
3np 1y ago
> Signal's threat model has never included "you are directly messaging an adversarial party and expect to retain control over redistribution of those messages". On the contrary. https://signal.org/blog/signal-doesnt-recall/?pubDate=20250809 https://signal.org/blog/signal-doesnt-recall/?pubDate=202508...
- x0x0 1y ago
  Huh? That is very explicitly about preventing the migration of your signal messages into Windows Recall. Not the threat model you discuss.
- chimeracoder 1y ago
  > On the contrary 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.

Marsymars 1y ago

> 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.

elvisloops 1y ago
There's a big difference to me between storing it on device and someone else's servers.
- fsflover 1y ago
  Why does it matter if everything is encrypted?
  - fsflover 1y ago
    Why am I downvoted? It seems actually encrypted, https://news.ycombinator.com/item?id=45171740 https://news.ycombinator.com/item?id=45171740
- Marsymars 1y ago
  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.
  - elvisloops 1y ago
    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

amluto 1y ago

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.

maqp 1y ago

>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.

elvisloops 1y ago
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.

fastest963 1y ago

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.

upofadown 1y ago

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.