Images are not encrypted at rest on local device

Development
12

Wouldn't a malicious system admin always have access to most things?

For Joplin to support at rest encryption, either 3 things would need to happen.

  1. you enter the master key by hand every time joplin loads, for the rest of your life.
    (Evil admin will key log you).

  2. the master key is stored unencrypted next to the data, or weakly salted, so it looks encrypted but is trivially broken. ( This is what password managers in web browsers often do, e.g, Firefox has a separate master key, so does Chrome)
    (Evil admin will take this file)

  3. the system key ring is used to store the master key securely so it can be used automatically. Except this is storing it into the system, of which your administrator controls, and can change.
    (Evil admin controls the OS keyring)

Add on other problems like your administrator can just change the Joplin executables to keylog your password.

If the attack is coming from the machine itself, there are no valid defences. The entire concept relies upon trust which you do not have.

Even full disk encryption doesn't work, the machine isn't yours, the admin has the key.

At best, a user controlled mechanism for encrypting $HOME with a key derivation system would be needed. And that comes back to, the admin will just change the operating system so once you unencrypt the data, they can access it. ( Whether directly or they're going to make the agent just leak the key).

Functionally when Joplin operates for synchronisation, it's doing the third. All data is encrypted BEFORE it's on the file host. It is never unencrypted on the file host itself, because the second it does that, it breaks the guarantee. But your local environment isn't a basic file host.

This sums up as "if the machine isn't yours, encryption won't help you locally".

2 Likes