Images are not encrypted at rest on local device

After using Joplin with encryption for a long time, I was somewhat shocked to discover that image attachments are not encrypted at rest on the local device. If you go into the folder .config/joplin-desktop/resources, there are a lot of .png attachements that are unencrypted.

Though it is probably true that image attachments are encrypted on the sync target, any system administrator (or anyone that can access files in your account) can easily browse these images. This could be a huge security risk for some people.

So, at a minimum, I think that there needs to be strong warning in the documentation that this is the current behaviour when encryption is being used. Ideally, the attachments would be encrypted at rest. If there is a performance hit with encrypting images, then the user should decide whether these attachments should be encrypted or not.

3 Likes

This is currently unsupported. See:

If you require a security measure like this:

  • Use one of multiple different secure notebook apps that support this feature
  • Use full disk encryption, VeraCrypt, Cryptomator, etc.
  • Contract someone to make a private build for you
  • Develop it yourself

There is an FAQ entry.

It isn't only images, your data is stored in the sqlite database which can be opened. It does state that Joplin supports end-to-end encryption, not at rest encryption.

Thanks. I did look at the FAQ before posting, but I didn't read that entry because the title is a bit misleading. Instead of saying "Could there be a password to restrict access to Joplin?", I would probably say instead "Are my data encrypted?" (or, "Are my data encrypted at rest?" Or "Are my data encrypted when using end-to-end encryption?")

And thanks for pointing out that all notes are unencrypted as well at rest. I would never have guessed that this is how things were implemented. There's nothing wrong with doing it this way, as long as the end user is made aware of this when deciding to implement end-to-end encryption. So, at a minimum, I think that there needs to be strong warning in the documentation and within the application settings that this is the current behaviour when encryption is being used.

Edit: For those who are wondering why encryption at rest is not implement, I suggest that you read this post by the lead develop: Requesting encryption of local Joplin data (at rest encryption) - #28 by laurent

1 Like

Many applications don't encrypt their data at rest, yet there's no strong warning about it anywhere. Thunderbird for example deals with a lot sensitive data but they don't show any warning, why would they?

Also we document what E2EE is, and nowhere do we claim that it means data is encrypted at rest.

Thunderbird doesn't have an "end-to-end encryption" option like Joplin does.

I agree that you document what E2EE is. However, I am the kind of person that likes to read manuals and documentation. If I was confused about this, I am certain that other people are as well.

Would there be a willingness to accept a PR that improves the documentation so that this point is more clear? If the project thinks that this is important to do, I would be happy to contribute.

2 Likes

Hmm, I'm not against clearing confusion but we generally don't document what the app doesn't do, simply for practical reasons. It's hard enough to document what the app does and maintain and translate this, never mind doing the same for what it doesn't do.

WhatsApp or Signal for example are well known for using E2EE but they don't say anywhere that the local data is not encrypted. E2EE and encryption at rest are just two different things.

1 Like

You are right that E2EE and encryption at rest are two different things. But what percentage of people know this? And of those that do, what percentage will just assume that you are using a method similar to a password manager?

Would a strong warning prevent questions about encryption at rest? The password FAQ entry and related discussions don't seem to prevent questions. If users won't research before posting, docs are futile.

If they would research prior and someone is willing to maintain docs, practical reasons to document what the app doesn't encrypt include:

Creating a FAQ and Wiki entry people won't skip over (including myself) due to lacking:

  • Title beyond password locking, which is why I skipped the FAQ entry too
  • Specifying unencrypted data types, which the FAQ entry doesn't include
  • Mention of "encryption at rest" or similar, which the entire FAQ site doesn't include

Educating users in a place of authority on:

  • The difference between end-to-end encryption (E2EE) and encryption at rest
  • Curated Joplin team responses on the matter, so nobody has to repeat themselves
  • Picking apps that suit their needs without having to create an account and ask questions

Users assuming Joplin supports encryption at rest or passwords like competing private and secure (notebook) apps:

It seems that Google already gives good results for this?

1 Like

If you change you mind, and would like someone to help in improving the documentation, just contact me. I understand the time commitment that this task involves.

1 Like

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

Thanks, I appreciate. This is all an on-going discussion anyway, and we do take on board suggestions and criticisms but of course things sometimes move slowly.

I use Joplin on a company device and decided to use Joplin portable on an encrypted usb memory stick. From my point of view this is the safest way I can achieve using Joplin on that laptop. There is more info on that version here in the forum. Perhaps this is an option for others as well.

3 Likes

Encryption at rest and passwords continue to be discussed. And if you consider this a good result, the FAQ suggestions apply even more.

@MarkWieczorek Some questions for you that could help if docs are needed:

  • What resources besides the FAQ entry did you look at before posting?
  • Have you used other programs that encrypt at rest on your local device?
  • Did your search engine give you any result similar to what is pictured above?