Better encryption algorithms

[m3thm4th]

Describe feature

Trilium encrypts protected notes with AES-CBC-128.
There is no reason for staying with AES-128 when AES-256 is more secure for minimal computation cost.

Speaking of which, it would be much better to switch to XChaCha20-Poly1305 with Argon2id, which is considered the best for security and it's also lighter and faster than AES on devices that don't have AES-NI instructions set, like smartphones, tablets, all Apple silicon devices, all Snapdragon devices and all ARM and RISC-V based devices and SBCs like the Raspberry Pi.

Additional Information

No response

[eliandoran]

I suppose the encryption algorithm used has remained the same from when the application was first created back in 2017, where it made sense for performance.

It's probably a good idea to move to something more secure. However, we have to be really careful not to endanger the data integrity of existing users. How do you suggest to migrate existing users' data?

Unlike a normal migration, this one touches the protected notes so the app needs access to the user's password.

[m3thm4th]

I suppose the encryption algorithm used has remained the same from when the application was first created back in 2017, where it made sense for performance.

I don't know what the thought process of the original dev was, XChaCha20 has been around for two decades, it's the most obvious choice, even Bitwarden switched to it.

How do you suggest to migrate existing users' data?

Two ways come to mind:

1. Ask the user to unencrypt and reencrypt the notes manually, so the new default will be applied
2. Add an option to reencrypt the database, the user is asked for the passphrase and is warned the process might take some time.

Of these no. 2 is more polished. Projects like wxSQLite3 are worth taking a look at.

Since this process requires a little bit of rework anyway, an even better option would be to change the way the database is handled in the first place.

My unfettered opinion: the security and privacy aspect should receive much more attention.

People are increasingly concerned with security and privacy, especially with application like these, that should be entrusted very personal and intimate data.

There are a lot of FOSS applications for PKM and advanced note taking, Beaver Notes, Logseq, Turtl, Joplin, NotesNook, Cryptee, AnyType, the majority of open source PKM software have made security and privacy their main focus.

Among these, Logseq is a telling example because many people do not understand the way it is supposed to work, they try it with the assumption that it's something like Trilium, but the workflow is different and you see a lot of people struggling to use it. Why don't they just pick another app? Because Logseq markets itself as "privacy-first and open-source", most people try to stick with it for this very reason, those who don't really care gravitate toward Obsidian and don't use the sync function if possible, because the "local-first" aspect of Obsidian is enough for them.

Those who don't care about FOSS will stay on Obsidian and Evernote anyway.

If you focus on making the infrastructure of Trilium secure and private, this project will attract a lot of people, it's already established, it's completely FOSS and self-hostable and it's a classic PKM software.

My suggestion is, reorganize the database structure if you have to, you can't afford blunders like issue #6993.
Encryption could be even enabled by default and then the user decides to use a passphrase or not, like Android phone work, they are all ancrypted, but not all users set up a PIN or password.

Build a solid foundation of security and privacy and people with migrate en masse.

[capi]

The most straight-forward solution would be to re-encrypt a note on the next edit to the new algorithm. Just make the algorithm part of the (unencrypted) meta-data of a note. Since the seed for the KDF would be the same for both algorithms, it would still work without having an automatic migration that might break something for existing users.

Since I'm self-hosting for myself, I actually don't use secure notes at all and honestly, the fact that the data is there in plaintext in the SQLite database is a big plus for me. I know a lot of people that prefer Obsidian over Trilium just because there the data is just simple plain readable MD files and not an SQLite database.

What I mean by that: locking myself out from my notes is actually more a concern to me than if they are encrypted or not. Encryption is handled on the layer below in my case (LUKS).

[werererer]

AES-256 is only needed if you care about post quantum cryptography. AES-128 isn't broken without quantum computers ¹. However with Quantum Computers Grover's Algorithm ² might reduce its strength to a level of AES-N/2. We don't have easily available quantum computers for the next few years at least ³.

However XChacha20-Poly1305 sounds nice, because it is faster on general hardware than AES and has some other advantages about simplicity where I lack information tbh. It also comes with post quantum safety ⁴, but as described above, its not an issue for a few years.

Also I do not believe that most users care about their security in product decision, and only realize the importance when it is too late. Most people have the same password everywhere. Therefore implementing a good solution will not lead to a hugh increase in users but rather in disaster avoidance.

Footnotes

1. https://crypto.stackexchange.com/questions/102671/is-aes-128-quantum-safe ↩

2. https://en.wikipedia.org/wiki/Grover%27s_algorithm ↩

3. https://www.nist.gov/cybersecurity/what-post-quantum-cryptography ↩

4. https://crypto.stackexchange.com/questions/79518/is-xchacha20-poly1305-quantum-resistant ↩

[werererer]

I still support implementing XChacha20-Poly1305. in approx 5 years billion dollar companies and countries could decrypt your AES128 encrypted data (p. 6) ¹, and having a secure plattform against states is practical for journalists.

This doesn't seem to be true, I can't attack AES128 further. (Because the paper is talking about RSA not AES.

Footnotes

1. https://csrc.nist.gov/files/pubs/ir/8105/final/docs/nistir_8105_draft.pdf ↩

[deajan]

From a pure implementation standpoint, I'd say create a DB backup, let trilium re-encrypt on the fly every note (with a nice modal asking user to reencrypt and showing a progress bar or such), and don't let the users handle decrpyt/ecrypt themselves or we'll endup with databases containing two encryption algorithms.

From a security point of view, indeed, we need post-quantum encryption algos, ChaCha20-Poly1305 has been widely tested and is fast enough on modern hardware.
There would still be a need to have a salt (ie argon2 ?) for the user password to decrypt the global or user based encryption key (perhaps wait until multi-user support has been merged).

It would also be nice to have a "encrypt all notes in database" option in order to be able to store notes on a server without having to trust hosting companies to not be nosy. This would indeed only encrypt notes content but not metadata, in order for the logic behind notes hierarchy to continue to work.
As seen with Bitwarden client, this will add some degree of slowness to clients, for those who'd enable the option.

[werererer]

To clarify and not give out the wrong information. I wanna rephrase a bit:

My understanding is that even in a post quantum world breaking AES-128 is highly unlikely even in the near future ¹². In PQC one may use AES-256 to restore same security back to AES-128. However AES-128 will still be billions of years of compute with the first quantum computers becoming available in the next few years.

The key reason to support Xchacha seems to be speed and a slight advantage of security. Speed on general hardware is better not worse ³, such as mobile phones. However speed is worse on computers with specialized AES optimized Chips¹. Most laptops and computers are AES optimized. E.g. Intel CPUs support AES-NI⁴.

Xchacha is more secure, may only be justified like this: it's simpler to use without creating an accidental side channel attack⁵¹, and having it simple to create correct implementations leads to less chance of these attacks. Thus its more secure.

Therefore in theory:

• Xchacha and AES-256 are PQC safe. AES-128 is not, because through Grover's algorithm its not hitting the target 128 secure but only 128/2 = 64.
• Xchacha has an advantage of speed on non specialized hardware including mobile phones
• AES has an advantage in speed on AES specialized hardware, that is most laptops and desktop computers

But in practice:

• Xchacha, AES-128 and AES-256 are PQC safe. Because AES-128 is still hard to break.
• Xchacha has an edge in security because of simplicity of implementation.

Footnotes

1. https://crypto.stackexchange.com/questions/101050/xchacha20-vs-aes-128-security-and-speed ↩ ↩² ↩³

2. https://crypto.stackexchange.com/questions/102671/is-aes-128-quantum-safe ↩

3. https://crypto.stackexchange.com/questions/34455/whats-the-appeal-of-using-chacha20-instead-of-aes?utm_source=chatgpt.com ↩

4. https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-encryption-standard-instructions-aes-ni.html?utm_source=chatgpt.com ↩

5. https://crypto.stackexchange.com/questions/111966/aes-vs-serpent-which-is-more-side-channel-resistent ↩

[m3thm4th]

I'm sorry @werererer but it looks like you want to show off your essays in which you contradict even yourself (AES128 is PQ unsafe but it's also PQ safe). This is not crypto.stackexchange.com, let's keep it practical.

You call hardware that doesn't support AES-NI "non specialized" which is tendentious, in reality the majority of devices (which happen to be mobile devices) don't have AES-NI instructions in their CPU, only Desktop and Laptop CPUs have that instruction set, and the only advantage using AES instead of XChaCha20 on those devices is Full Disk Encryption on NVME SSDs, in all other use cases XChaCha20 is not a bottleneck (it encrypts faster than a SATA SSD can write) and it has only upsides, for Trilium it's a no-brainer.

As far as security goes, you minimize the implications too much, there are many more theoretical and even practical (side channel on non-AES-NI devices) attacks against AES than XChaCha20, AES is harder to implement correctly and less quantum resistant, it's slower and more complicated.

What most people don't understand is industries move very very slowly, they are not up-to-date with the best security practices. Industrially AES128 and RSA2048 are considered "safe enough to not need an immediate move to something better", those older and worse algorithms will be used everywhere in the industry until they will be broken, and then everyone will panic and rush to switch them for something secure.

I suggested switching to AES256 as the very minimum change that should be made, moving to XChaCha20-Poly1305-Argon2id is the most reasonable solution that will be more advantageous for everyone.

[werererer]

@m3thm4th no, if I got smth false its even better! because then we get the correct info

[m3thm4th]

@werererer false is a strong word, you just don't seem to see the full picture and theorize too much when discussing practical applications, by no means I intended to throw shade or disrespect you, what you wrote is not false, just too optimistic (also considering we are talking about public technologies, we don't know what it's still covered by military and industrial secret).

[m3thm4th]

I opened #7514 that would allow additional possibilities by using external encryption software