Joplin: [Feature Request] End-to-end encryption

[brunomvsouza]

It's getting harder and harder to trust providers with our data, and a common solution nowadays is the use of end-to-end encryption since the providers will only be able to see in plain text the metadata needed for synchronization, with all other data readable only by it's owner.

[alexanderadam]

I think it's good to have a popper issue for this (although it was planned anyway). 👍

[laurent22]

Yes this is indeed planned, however if you have any suggestion regarding the implementation please let me know.

My current plan is:

• Notes are encrypted via a password (so that they can be decrypted in any device without having to move around a key file)
• Each encrypted note will include metadata about the cipher that was used and the type of key (so it will be hard-coded to "password" in this version, but this is to allow other key types to be supported later on)
• Every time user enters a password it is saved (temporarily?) to the local device so that it's not needed to ask for it for each note.
• While most of the content will be encrypted, the metadata required for syncing will still be visible - in particular the id, timestamp and the item type (whether it's note, notebook or tag).
• Attachments will also be encrypted.
• If user changes the password, the previously encrypted note will still use the old password. Maybe there could be way to batch decrypt/re-encrypt all the notes with the new password.
• At a low level, encryption will be on a per-note basis so encrypted notes can exist alongside non-encrypted ones, even with different ciphers or passwords. There will be an option to always use encryption.

[alexanderadam]

I like the idea of end to end encryption. Actually it's the only thing that is _the_ killer feature for me.
But I _think_ per note encryption _might_ introduce heavy complexity and/or increase the probability of bugs. You would have to ensure that these operations are atomic _1_). I guess it would be much easier if these notes would be encapsulated (ie within an SQLite database or some container in general) and you would just have to encrypt the containers and the diffs.
That way you also don't have to think which metadata might or might not be critical.

_1_) Imagine you synced and the net is gone while you were syncing a password change.

[laurent22]

Yes the reason encryption is per-note is because it makes it easier to keep things stateless - i.e. I don't need to leave some metadata on the sync target to tell whether the notes in there are encrypted or not. The synchroniser just download and handle each item individually.

Encrypting the whole thing wouldn't work either as synchronisation would be inefficient, it means there would be a big blob of encrypted data to transfer every time a note is changed (since encrypted data cannot be diffed).

I've got most of the backend and synchronisation working already in the encryption branch. There's also a draft spec there - https://github.com/laurent22/joplin/blob/encryption/README_spec.md

I'm trying to keep things flexible so that it can be tweaked in case I missed something. Any comment is welcome.

[alexanderadam]

I see. That's awesome! 👍

[kslstn]

Perhaps the open source implementation of Standard Notes offers a solution? https://standardnotes.org/help/3/how-does-standard-notes-secure-my-notes

In SN all notes are encrypted, without the need to enable it per note. So far I haven’t experienced syncing issues.

[laurent22]

End to end encryption is now available on desktop, terminal and Android (coming soon on iOS). For now I've marked the feature as beta although I'm reasonably confident that it's working as expected. There are unit tests to cover many corner cases both related to encryption and synchronisation and they are all passing.

I'm already using it to manage my own notes without any problem so far (I've got a cron script that backup everything at regular intervals to a git repository, so I can see what changes over time and it's all good so far).

I've put some documentation there: http://joplin.cozic.net/help/e2ee.html

and a more technical spec here: http://joplin.cozic.net/help/spec.html

If anyone could give it a try that would be great, any feedback is welcome. I think the process to enable E2EE could be improved but once it's enabled it works pretty much transparently.

[kslstn]

🧡🔒💛

[laurent22]

As I've been using this for about a month without issues I'm tempted to graduate the feature out of beta. I'm wondering is anyone using this at the moment? And if so is it working or have you noticed any issue?

[laurent22]

Will be officially released as part of 1.0.x