I find it beyond bizarre that I can’t add a comment to a comment to my own answer, but whatever.
@mentallurg: He does not “clearly enumerate” that threat at all. For example, he doesn’t address the obvious question of whether the system should be secure against a malicious administrator - the most obvious and dangerous risk for any E2E encryption system. Do you seriously contend that the OP’s post provides a sufficient threat model against which to build a system?
———
I’m just an amateur too, but here’s how I see it.
You say that [part of] your goal is “to design an encryption scheme for the application so that the backend stores encrypted data and the whole process of encoding and decoding happens on the frontend”.
I would argue that that is not your goal at all!
When I go to the supermarket, my goal is not “to drive from here to there in a four-cylinder turbocharged vehicle”. It is instead, “to obtain some food that I can take back home and cook for dinner”. How I actually achieve that goal, is an entirely different thing: drive there in my own car, take an Uber, walk there on foot, ring them up and get them to deliver it, and so on.
In the case of cryptographic systems, as I understand it, goals are generally stated in the form of a “threat model”. A threat model is, in effect, a list of specific things that you do not want an attack to be able to do. You develop the threat model first, before you can choose an implementation to mitigate the threats described therein.
For example, your post says nothing about “integrity”, which (in my amateur definition) is the ability of someone receiving a ciphertext, to tell unequivocally whether that ciphertext has been altered in transit.
At least one mode of AES is “malleable”, meaning that an attacker can alter selected bits in the ciphertext, and that will alter just the corresponding bits in the decrypted plaintext - perhaps without the recipient being able to tell that! This can lead to nasty attacks, even when the attacker can not decrypt the data at all!
So one entry in your threat model might be: “The client must be able to tell unequivocably whether data received back from the server has been altered since it was sent to the server”, or somesuch.
As another example, what if an attacker intercepts a server response, and entirely replaces the ciphertext with one of their own choosing? Perhaps a previously intercepted, older version of the encrypted file that the client is trying to retrieve? Your threat model should probably say, “An attacker should not be able to replace a server response with one of their own choosing (without the client being able to see that)”.
As a final example, what if an attacker hacks the server, and modifies the encryption software that the server sends to the client? Now, when the client encrypts a file, the modified software sends a copy of the encryption key to the attacker! The attacker can now intercept the ciphertext and decrypt it - then even encrypt a plaintext of their own choice, and send that on to the server! What if a server admin does that (not an external attacker)? Should all that be in the threat model?
In conclusion: I suspect, with all due respect, that you haven’t thought about any of this. That means that any talk of AES, cipher modes, salts, who encrypts what/where, and so on, is entirely premature. There’s no point driving to the supermarket in your supercharged four-cylinder vehicle, if you don’t know what you want for dinner!
I suggest you develop a written threat model. Then others can help you to design a system to mitigate the threats therein.
Just my 2c
