|
| ▲ | joshjob42 7 days ago | parent | next [-] |
| 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. |
| |
| ▲ | elvisloops 7 days ago | parent [-] | | 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. | | |
| ▲ | joshjob42 7 days ago | parent [-] | | 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. | | |
| ▲ | elvisloops 6 days ago | parent [-] | | 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. |
|
|
|
|
| ▲ | evbogue 7 days ago | parent | prev [-] |
| 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? |
| |
| ▲ | brewdad 7 days ago | parent | next [-] | | 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. | | |
| ▲ | evbogue 7 days ago | parent [-] | | 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? | | |
| ▲ | krior 7 days ago | parent [-] | | 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. | | |
| ▲ | evbogue 7 days ago | parent [-] | | yes, agreed, and isn't this feature re-encrypting all of the material without a ratchet or asymmetrical boxing? | | |
| ▲ | elvisloops 6 days ago | parent [-] | | Yes, it undoes all of the security features of Signal's encryption protocol. |
|
|
|
| |
| ▲ | bilal4hmed 7 days ago | parent | prev [-] | | 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). | | |
| ▲ | evbogue 7 days ago | parent [-] | | 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 |
|
|
