To Encrypt At Rest Or Not To?
There has been a lot of (passionate) debates on Joplin’s forum about its SQLite 3 database showing everything in clear text.
And by everything, I literally mean “everything”. Including your master encryption password.
Now, my intention here isn’t to fuel another debate. Joplin passed several security audits. Long story short: if you want your computer to remain safe (as much as possible), encrypt your whole hard-drive.
This is indeed a best practice.
Instead of discussing whether or not Joplin should encrypt its database, I’ll share the additional layer of security I laid out on my Linux machines using tomb.
By the way, if you have no idea what I’m talking about (what the hell is Joplin?), I suggest you read my previous post: From Evernote To Joplin.
What’s Joplin End-To-End Encryption?
There may be some confusion between the notion of “at rest encryption” (referring to local data on your computer) and Joplin offering end-to-end encryption.
Let me explain.
Joplin saves all its data in a SQLite 3 database (plus some files) on your machine. As previously said, the database holds everything in clear text. Improving security locally (i.e. at rest) is what this post is about.
However, when you sync your notes through “the cloud” (whatever the method or provider), they can be sent encrypted (with your master password).
In this case, the sync process guarantees your notes can’t be intercepted in transit. This is what Joplin’s end-to-end encryption is about.
Encrypted Containers To The Rescue
The Workaround
The solution to our dilemma is actually rather straightforward:
- First create an encrypted container.
- Then move Joplin’s SQLite 3 database files into the container.
Obviously you need to open the container before you launch Joplin. Some may find it cumbersome. But hell, if (like me) you’re paranoid enough to come up with such a process, it’s a small price to pay (and we’ll see how tomb comes in handy).
VeraCrypt
So far I’ve been using VeraCrypt. VeraCrypt is a maintained secure fork of the “dead in mysterious ways” TrueCrypt.
An encrypted container is just a file. VeraCrypt can create, decrypt and mount such files in your directory tree somewhere like:
/media/veracrypt1
In a GNU/Linux like system, by default, Joplin’s database files are saved in your home directory at the location below:
~/.config/joplin-desktop/
Once you move joplin-desktop to the encrypted container, Joplin needs some pointers to find its database. Thus I created a desktop entry app launcher with the following Exec line:
Exec=/home/<your user name>/.joplin/Joplin.AppImage --profile /media/veracrypt1/joplin-desktopAs far as I’m concerned there is one caveat to this approach. Did you notice the 1 in veracrypt1 ? It means you always need to open the encrypted container in the same slot in VeraCrypt. Not a big deal but still worth mentioning.
This is how I’ve been using Joplin for a couple years without any problem.
My New Life With … Tomb
While life was ok I guess with VeraCrypt, I discovered tomb and fell in love with it (so to speak).
Tomb is “just” a “simple” zsh script. It is always available at your finger tips (Yes! I love the command line too).
It leverages secure proven standard GNU/Linux technologies (like LUKS – Cryptsetup – and GnuPG). No need for a 3rd party application like VeraCrypt (although I have nothing against VeraCrypt).
It’s a script (haven’t I said that already?)! Meaning you can always read it if you feel like it. It’s a free software. The code is available on github under GPL.
And then the “coup de grâce” … Tomb comes with some killer features!
Bind-Mount
Remember the tweak I used to let Joplin know where to find its data with a desktop entry? Tomb makes it unnecessary.
When you open a tomb (say joplin.tomb), the script mounts it to:
/media/joplin
However, with a very simple configuration, tomb can bind the mount point anywhere in your home directory like:
~/.config/joplin-desktop/
No need for a desktop entry anymore, all data are seamlessly available where Joplin expects them to by default.
Steganography
Tomb relies on GnuPG to generate the keys to encrypt its containers. So far so good. However, keeping both a container and its key together on your computer is obviously a bad practice. It’s like leaving the key to your house next to your door.
Well, indeed the keys themselves are password protected but still.
Now tomb can hide a key (which is basically a text file) in any jpeg image on your computer, thanks to steghide. This process is called steganography.
This makes the keys much less conspicuous and thus much harder to find for an ill-intended person. Also honestly its fun.
Post Open Hook
It’s something I haven’t put to good use yet. But tomb gives the option to execute a script after opening a tomb.
Lots Of Fun
Simply put I find tomb hilarious. It fully assumes the “theme” around its name and responds with fun messages to commands.
tomb (*) Tomb [joplin] closed: your bones will rest in peace.
Even tomb command names are “on theme” like dig, bury or exhume.
Conclusion
Well, if you only need to remember a few things:
- Joplin is a great note taking app. I actually cancelled my Evernote subscription a few years ago and have been using Joplin ever since. You should have a look.
- Tomb is a great way to secure Joplin’s data at rest.
Obviously tomb can be even much more useful. I only talked about one use case here, but I consider using tomb for other kinds of data:
- SSH configuration and keys (located in ~/.ssh)
- GnuPG configuration and keys (located in ~/.gnupg)
- May be even ~/Documents (hell why not?)
Storing information in encrypted containers is great if you want portability. It’s also great for backup purposes (like saving files in the cloud). Long story short we’ve only scratched the surface of the graveyard.
How would you consider using tomb?