Messages in the Signal Desktop database are not encrypted at rest

[kyanha]

(ticket #549 was closed because it was interpreted as a support request, without addressing the fundamental issue.)

Every message that goes to Signal Desktop is essentially treated (on the desktop, where there's more of a chance of malware and illicit message access outside of Chrome) as having been exported to plain text.

There is no documentation of this lack of security for Desktop users, which prevents Signal users from ensuring that their tools meet the needs of their threat models based on documentation alone.

[liliakai]

Documentation lives on our support site, rather than github, so that is still an issue for support.

If you want to have a discussion, please take it to the mailing list, where there is already a long thread on this topic.

[alilleybrinker]

Has there been any change related to this, or does data remain unencrypted at rest in Signal Desktop?

[scottnonnenberg]

No change. The data is still stored, unencrypted, inside of IndexedDB. Perhaps you can describe what your ideal user experience would be? Some sort of passphrase to unlock the application, perhaps?

[alilleybrinker]

That would be ideal for me, yes. Encrypting the data in transit is great, but it seems problematic to leave it unencrypted at rest in a desktop environment where the broader state of system security is so low. At the very least, it seems like a footgun for the less security conscious who may assume a data is encrypted at rest.

[alilleybrinker]

One concern as well is whether all communications are decrypted on startup. Signal Desktop is presumably expected to run continuously, and if the contents are fully decrypted while it's running, then the encryption isn't really doing much. It may be worthwhile to investigate the partial decryption mechanism described by Agile Bits and implemented in 1Password. In Signal Desktop, this would likely mean doing just-in-time decryption of conversation history when a conversation is opened, and encrypting it again if the conversation is closed.

[scottnonnenberg]

Thank you for sharing your perspective on this. A couple thoughts:

1. It's absolutely true that desktop security is weaker than mobile security, at least as compared to the world of iOS. You're probably right that we could do some things on Desktop to take up the slack.
2. Requiring a passphrase to open the app is a little more involved than the average user would like. If we did it, we'd definitely need all the standard recovery options any rigorously encrypted system needs, which means users would need to store those sensitive keys somewhere.
3. It would be extremely costly to implement, given how far from that we are now.

I can't say that we'll be doing this soon, but I think we absolutely welcome help planning out potential solutions: UX, architectural changes to the system, etc.

[alilleybrinker]

I totally understand. Adding encryption for data at rest to an application that doesn't currently have it is a daunting task. I am happy to put some thought into how the UX might go, and what sort of changes may be needed in the system to accommodate such a change.

[patlecat]

I expect a real encryption of all data passed into the desktop app. And not just at rest. It should decrypted memory only and only when needed. In-Memory dbs are not rare these days but I do not know what the limitations are of a Chrome extension and no one has said anything about that here. I am still shocked that the desktop app was conceived from the start to be totally unsecured, Signal, out of all the IMs!

Data should be jailed and secured in the running app until released by the user.

There should be an option in the app to limit the max number of messages to be synchronized at startup (100 would be fine for me for ex) and then only load more IF the user scrolls up to find more.

The user should decide how many messages should be stored on the public server. This is problematic for chats involving more than 1 person ;) But if you lower that default number to say 100 and then only keep more IF the user explicitly wishes it (up to 1000 max)! This would then be a per-user storage only and keep all message of all chats he was involved in. It may sound like that would require more storage space but with a low default only very few people would actually go to the max.