For Password-Based Algorithms You Want to Seek the Opposite
It goes without saying, but when it comes to securely storing one's password, whatever cryptographic primitives that are used to secure it should be:
A) Memory intensive (i.e., 'Argon2id' ; this is a variation of the Argon2 hash / salt scheme we've been discussing up to this point, but we'll get to that later)
B) Extensive to hash (even i this results in somewhat of a higher load for the hardware / chip that's going to need to ultimately run the cryptographic scheme in live time) .
We need to keep in mind that we don't need to access passwords that often. And, comparatively speaking, they're very tiny pieces of data (vs. the amount of encrypted data that must be encrypted + decrypted + synced back & forth continuously when it comes to ensuring StandardNotes continued functionality).
C) Encrypt, then MAC (in that order, specifically) = https://www.daemonology.net/blog/2009-06-24-encrypt-then-mac.html
This is age old wisdom handed down from the OGs of cryptography and math.
Pay heed.
D) Understand **what kind of mode you should be using if you're implementing AES encryption (yes, it does matter - substantially - in terms of both performance + security).
E)
>>Click here to continue<<