←back to thread

988 points keyboardJones | 8 comments | | HN request time: 0s | source | bottom
Show context
elvisloops ◴[] No.45170770[source]
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.

replies(6): >>45170803 #>>45170831 #>>45170946 #>>45172659 #>>45176363 #>>45176500 #
Marsymars ◴[] No.45170831[source]
> 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.

replies(1): >>45170880 #
elvisloops ◴[] No.45170880[source]
There's a big difference to me between storing it on device and someone else's servers.
replies(2): >>45170929 #>>45170950 #
Marsymars ◴[] No.45170950[source]
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.

replies(1): >>45171074 #
elvisloops ◴[] No.45171074[source]
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
replies(2): >>45171118 #>>45171172 #
1. evbogue ◴[] No.45171118[source]
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?
replies(2): >>45171478 #>>45171740 #
2. bilal4hmed ◴[] No.45171478[source]
I mean it says so right in the blog post

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

replies(1): >>45171889 #
3. brewdad ◴[] No.45171740[source]
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.
replies(1): >>45171858 #
4. evbogue ◴[] No.45171858[source]
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?
replies(1): >>45172273 #
5. evbogue ◴[] No.45171889[source]
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
6. krior ◴[] No.45172273{3}[source]
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.
replies(1): >>45172606 #
7. evbogue ◴[] No.45172606{4}[source]
yes, agreed, and isn't this feature re-encrypting all of the material without a ratchet or asymmetrical boxing?
replies(1): >>45175421 #
8. elvisloops ◴[] No.45175421{5}[source]
Yes, it undoes all of the security features of Signal's encryption protocol.