Does Joplin encrypt md files at rest (both locally and remotely), or only in transit?

The documentation is sort of unclear. I use a network SMBv3 share to hold my md files, and I would love them to be encrypted at rest (meaning both remotely and locally whether or not Joplin is even running).

I'm not sure I even need syncronization since it's a simple SMB network share, but the encryption option isn't even functional now, and I suspect it's because I haven't configured any sync. ...which makes me wonder if the encryption is for transit-only. ...although there's a "re-encrypt" option, so that makes me think maybe it's only encrypted on the remote server and NOT the local one.

If anyone can clarify, that would be great.

Take a look here :

And metadata is readable in MD files :
id:
parent_id:
created_time:
updated_time:

See more

is_conflict:
latitude:
longitude:
altitude:
author:
source_url:
is_todo:
todo_due:
todo_completed:
source:
source_application:
application_data:
order:
user_created_time:
user_updated_time:
encryption_applied:
markup_language:
is_shared:
type_:

An here :

I don't know what has been chosen (AES algorithm at 128, 192 or 256 bits) and if it's strong or weak.

1 Like

This doesn't really answer the question. I did a quick sync test, and it seems to encrypt the data on the remote, but the SALT is visible in the remote file... so it's not clear to me whether it's really securely stored.

But the test did also answer my question about LOCAL encryption - the "database.sqlite" file on the local system is clearly NOT encrypted as even opening it in a text file, I can read my notes in clear text.

Disappointing.

True, the database is not encrypted.

Are your new notes encrypted? My old notes (old meaning before I turned on encryption) can be read in plane text, but my new notes can't be read in plane text. Maybe that is what you are seeing?

On the remote storage device/service (eg Dropbox) they are encrypted (although the SALT is visible, so it's still brute-forceable), but on the local machine where I'm editing/accessing my notes from, everything is in clear text - the notes and even the encryption master password. It's all in the database.sqlite file which you can read with any text editor.

On my Windows box, I have used VeraCrypt encrypt a whole volume of files without issue (not currently however). Basically you open a VeraCrypt volume by logging in, then you get a new virtual drive that functions just like a USB key. Files get read, written, and Xcrypted on the fly. HTH

resource: https://www.veracrypt.fr/code/VeraCrypt/

That doesn't really solve the issue. If you have these notes open all the time (as I do), then it's functionally identical to disk encryption - providing encryption "at-rest". Aside from being a pretty heavy extra-step for users and only applicable to the non-mobile apps, it still keeps the database.sqlite in clear text while the Veracrypt container is mounted for any process to read.

Imagine if a password manager like LastPass kept passwords and note locally in clear text. It would be such a huge security gaff that no one would use it.

Even a password protected Word/Excel file provides encryption while in use.

Security isn't all-or-nothing. "well if they have access to the computer, then you're F'd anyway" - that's not how people who take security seriously approach security. Security is about creating a layered security model that provides (sometimes redundant) protection to thwart various attack vectors.

...sorry if this sounded preachy! I otherwise like the product.

1 Like

There is an SQLite extension which allows to maintain encrypted databases: https://www.sqlite.org/see/doc/trunk/www/readme.wiki

For JavaScript this library seems to support it: https://www.npmjs.com/package/sqlite-cipher

I am not a JavaScript developer and I don't know if the Joplin developers (especially @laurent) already considered this option and for some reason decided against it. But I know that other apps are using "SQLite Encryption Extension" in order to encrypt SQLite databases. The example shown on the sqlite-cypher website looks very straight forward, however. One just has to connect with the database providing a password and an encryption algorithm as additional arguments to the connect function. If it is really that easy then why not reconsider introducing local encryption, too?

1 Like

The main point of adding salt is to stop a table of pre-computed values from being a useful way to reverse a hash, and in this case there is no advantage to obfuscating them for storage, is there?

My understanding is that Joplin does not attempt to encrypt locally stored data, only the synchronized data (regardless of backend, whether local or cloud).

1 Like

@laurent I have the same issue and would like to encrypt my local sqlite database. I understand that you dont integrate this as a native feature. Therefore, I would just to know, if a joplin plugin would be able to handle this? O rather ask you before working myself into your plugin system since it will take a while to get familiar with it. I would really appreciate a reply.
Mainly I want you opinion on: Has your plugin architecture the ability to add a additional logic layer to the access of of the cal sqlite database. Since sqlite-cypher is already integrated in sqlitebrowser, my idea to write a plugin which takes into account that the local database might be encrypted. Currently Joplin would show this error, if the database is encrypted.

1 Like

A workaround might be to write my own local bash script which always encrypts the database when shutting my laptop down and taking out the decryption by an additional alias command which I connect to the start of joplin.

@jvg welcome to the forum.

There's also all the attachments in the resources folder.

Why not just use full disk encryption which will achieve what you are aiming for for everything on your system?

hi @dpoulton thanks for the welcoming! True, this would be a solution and the most secure way anyway. I might do this in the future. Still, I think this might be useful in many scenarios. Also, I think, comparing the desktop version with with the react native apps, its still missing some second security layer since on the apps now, there is also a second layer, where you have to reauthenticate when opening the app. (which makes sense I think) This would also apply if your disk is encrypted and you quickly leave your laptop to a friend. Of course, you could access a guest account but then you also have to set it up ect. ect. Therefore, I would also have this second kind of "login-layer" on the desktop version. Its just more convenient in the day to day usage without worrying to much if people can access your notes. Of course, if the laptop gets stolen, ony a full disk encryption saves you data but this is a rare case anyway.
Does this make sense?

But also i just relized, that in the scenario above, I could use other ways to implement it where only someone with linux admin knowledge could bypass the second login-layer.

Not currently and I've never heard of any plans to support this.

Thanks for the reply! My question was not if there is or will be a plugin for this, but rather, if the plugin architecture will let me add this kind of security layer or not since this logic has to be invoked before Joplin is fully initialized.

Sorry if i wasn't clear. I meant to say there's no support in Joplin for plugins adding security.

Ok, thanks for getting back to me! Have a great day!