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.
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.
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
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.
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?
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).