Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Signal Secure Backups

signal.org

Post reply on HN
Print view View original

21–30 of 460 posts

Re: Signal Secure Backups

#21

Post by chimeracoder »

georgeck wrote: post #15

It would be really useful to have more client-side control over media storage. That way, I could better manage storage growth without wiping entire threads. For example, being able to see all media across chats, sort by file size, and optionally group by conversation would make it much easier to clean things up.

> It would be really useful to have more client-side control over media storage. That way, I could better manage storage growth without wiping entire threads.

> For example, being able to see all media across chats, sort by file size, and optionally group by conversation would make it much easier to clean things up.

I have good news for you: this already exists.

On Android:

Settings >> Data and Storage >> Manage Storage >> Review Storage

This allows you to view all of your media, files, and audio across all chats, sorted by the amount of storage used. You can also delete those files individually without affecting the rest of the chat.

You can also do the same thing within a conversation.

Re: Signal Secure Backups

#22

Post by tkel »

rogerkirkness wrote: post #2

The main way I specialize messages at this point is basically 'Am I going to want this later'? If the answer is yes, I use email. If not I use Signal. It's interesting this was the most requested feature... it wouldn't be for me even though I love Signal.

It's important for Signal groups, because on a new device without a backup the groups you were in don't show up until someone sends a message in the group. Say if you were the only admin in an announcement-only group, no one else can send a message in the group, so that group is now lost to you.

Re: Signal Secure Backups

#24

Post by elvisloops »

chimeracoder wrote: post #10
elvisloops wrote: post #7

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 roundab…

> 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 th…

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

Re: Signal Secure Backups

#25

Post by fsflover »

elvisloops wrote: post #19
Marsymars wrote: post #13

Earlier quoted context omitted.

> 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'…

There's a big difference to me between storing it on device and someone else's servers.

Why does it matter if everything is encrypted?

Re: Signal Secure Backups

#26

Post by chimeracoder »

komali2 wrote: post #17

I'm confused, I've restored Signal from encrypted backups before. I did it like 4 months ago. What's this feature?

> I'm confused, I've restored Signal from encrypted backups before. I did it like 4 months ago. What's this feature?

Those backups are stored locally, are platform-specific (Android-only), and there is no feasible way to automate their transfer to any other device, which means that either you have to manually manage them regularly, or you risk losing your entire message history if your phone suddenly dies (or is stolen, or broken beyond repair, etc.).

This is a true automated, off-site backup feature.

Re: Signal Secure Backups

#27

Post by amluto »

elvisloops wrote: post #7

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 roundab…

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.

Re: Signal Secure Backups

#28

Post by Marsymars »

elvisloops wrote: post #19
Marsymars wrote: post #13

Earlier quoted context omitted.

> 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'…

There's a big difference to me between storing it on device and someone else's servers.

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.

Re: Signal Secure Backups

#29

Post by crystaln »

amluto wrote: post #8

Wow, maybe as a side effect users will be able to migrate between Android and iOS without losing their message history. Seriously, why is the migration protocol completely different on the two platforms?

This is mentioned as a future feature.
Post reply on HN