All: Resolves #8619: Add libsodium-based encryption method

[personalizedrefrigerator]

Summary

Adds a decryption method based on libsodium.

This pull request targets version 2.13.

Resolves #8619.

To-do

• (Required): Verify that crypto_generichash is safe to use for key derivation — Joplin master keys have a length of 384 bytes and many libsodium functions (crypto_kdf_derive_from_key, crypto_secretbox_easy, crypto_aead_xchacha20poly1305_ietf_encrypt, and probably others) require a key length of around 32 bytes. Alternatively, we could use pwhash, but that's intended for short human-generated strings.
  • Related: How to derive keys from high entropy input (other keys) jedisct1/libsodium#347 (though randombytes_buf_deterministic seems to have a fixed seed length).
  • This will likely involve creating a post in libsodium discussions.
  • Forum post
• (Required): Switch from the current encryption chunking to crypto_secretstream
• (Required): Add tests for the new encryption/decryption method
• (Required): Fix error: "Invalid secret key" for some items.
• (Required): Verify that it builds and can encrypt data on all platforms
  • Desktop
  • Mobile/Android
    • libsodium.js encryption seems to work despite this issue.
  • Mobile/iOS
  • Terminal
• (Optional): Don't base64-encode cypher text — output as raw binary data.
  • Existing encryption methods all encode cypher text using base64.
• Performance comparison with sjcl.
  • If needed, we could use sodium-native and react-native-libsodium for probably-better performance. However, libsodium.js is maintained by the author of libsodium and seems to be more popular than the two alternatives.

[laurent22]

Since this is also as js lib won't it have the same performance issues as sjcl?

[wh201906]

I think the new algorithm will bring the better performance than the AES in SJCL.
I just found a website with the performance comparison between AES-128-GCM and ChaCha20-Poly1305, showing the latter is 3x speed to the former without using the dedicated hardware instructions.
https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto.html

[laurent22]

Yes but if it hits memory limits or similar, we'll be back to poor performances, even if it's faster than SJCL. I'm not convinced it's worth the effort if we end up with another non-native lib.

If someone contacts us and prove that SJCL is not secure anymore, then yes let's look for an alternative quickly, but in the meantime we can investigate without spending too much time on a final implementation. SJCL was developed by academics over many years so I'm not convinced it has any security issues, and indeed nobody so far has proven there is one (and we need a working PoC, not assumptions).

[personalizedrefrigerator]

if we end up with another non-native lib.

See the above comment:

If needed, we could use sodium-native and react-native-libsodium for probably-better performance. However, libsodium.js is maintained by the author of libsodium and seems to be more popular than the two alternatives.

Switching to libsodium.js should give us the option to switch to a native implementation if we need to (though it's possible that the mobile build will require extra work).

[laurent22]

Switching to libsodium.js should give us the option to switch to a native implementation if we need to (though serenity-kit/react-native-libsodium#45).

Yes I saw this, but I feel it's an all or nothing - either we can use the native implementation, or it's simply not worth switching.

And actually this rn-libsodium package with its big .cpp file is a bit scary especially since it's developed by just one person. Ideally we would find a package that is widely used so that we know it's well maintained

[personalizedrefrigerator]

Yes I saw this, but I feel it's an all or nothing - either we can use the native implementation, or it's simply not worth switching.

A faster alternative could be to directly use the Java/Swift built-in cryptographic libraries (javax.crypto and CryptoKit) on mobile and the built-in SubtleCrypto API in node/Electron.

I'm closing this pull request for now.

[laurent22]

Electron has access to the Node.js crypto package so normally this part shouldn't be an issue. Whatever encryption works on mobile is what we'd use on the other platforms (including the CLI app).