Need some clarification regards end-to-end encryption process

Question

Let's say I want to make a messaging(just an example, take it as any data) web(react + node) application(more like an email rather than chat) with end-to-end encryption. So at some point, I will want to send an encrypted(with public key) message and the recipient will need to decrypt it(with private key). Now, say I want to make an encryption process happen on the client(isn't always should be on the client?), so:

1. user_1 want to send a message to user_2
2. user_1 requests public key of user_2
3. user_1 encrypt his message with public key from step 2 and sends it
4. user_2 receive the message and decrypt it with his private key

Now, all sounds great, but...:

1. For good UX, a user should know/care only about his own password and all the encryption should magically happen(right?), so generating and storing private key should be done behind the scenes. But how exactly? Storing private key encrypted with user's password, and on the Auth process, send it to the client and then decrypt the private key and store locally for the session. Is that really supposed to be like that?
2. Where to store the private key then exactly? Storing in local host isn't really nice due to XSS, storing inside a cookie(secured, samesite etc) also isn't nice due to same XSS and CSRF. Where then?
3. Also, it isn't really clear how to secure the connection between the client and the server. Is using SSL(https) really enough? What else can be done?

Answer 1

There are many ways that private key can be stored by the client in a web-based end-to-end encryption application.

One way is not to store the key it at all, but instead, derive the key from a password. The user enters a password, then the private key is derived from the password using a key derivation function, such as PBKDF2.

Another way is to use the Web Crypto API to store the private key in a CryptoKey object, then store the CryptoKey object in the web browser's indexDB storage. See https://crypto.stackexchange.com/questions/35530/where-and-how-to-store-private-keys-in-web-applications-for-private-messaging-wi/52488#52488 for more info on this method.

Another way of storing the private key is the way that ProtonMail does it. The private key is encrypted using another key derived from a password, then the encrypted private key is stored on their server. See https://protonmail.com/support/knowledge-base/how-is-the-private-key-stored/ for more info.

Yet another way of storing a private key is the way that EncryptedSend does it (full disclosure, I am the developer of EncryptedSend). The private key is encrypted using another key derived from a password, then this encrypted blob is written to a file that the user stores on his/her system. To begin a session, the user simply provides this file and the password, then the private key is used both to decrypt messages and authenticate the user with the server.

Answer 2

Generally, these days we want something that is forward secure that is, past messages will be secure even if long term private keys are compromised. That cannot be provided by encrypting the message, or even just the key with the public key. In actual communication processes we use forward secure mechanisms like Diffie-Hellman with ephemeral key pairs. Signal for instance uses Extended triple Diffie-Hellman (X3DH) over curve25519 which uses a combination of long term and short term and one-time-use Diffie-Hellman key pairs for session establishment and uses double ratchet algorithm which uses DH every time message sender changes. TLS 1.3 has dropped support for all non-forward safe key exchange, it uses long term private keys in order to sign and authenticate the key exchange so that they can be sure that the one in the other side is indeed who it is supposed to be and the key exchange hasn't been tampered with a man-in-the-middle.

So basically in nutshell, end-to-end encrypted systems need something which use the long term private/public keys for authentication but use ephemeral key pairs for actual session establishment and data encryption.

1 & 2. You can store your private key after encrypting with a key derived from your password using suitable KDF's like scrypt or argon2. Try to not ever share private key, even in encrypted form because passwords can be more easily guessed and attackked. But for your application you can also use Password-Authenticated-Key-Exchange, which you can look for in the internet. An improved version of dragonfly key (without its original clumsiness) might do. About the security of dragonfly, you can ask at crypto.stackexchange.com, about that, I am not sure how secure dragonfly beyond its clumsy specification in RFC, you might get better answer there but only if it is available. Don't try to implement it yourself without in depth understanding of side channel attack prevention, it will almost certainly be insecure from side channel attacks, even if dragonfly is proven secure mathematically and correctly implemented.

3. TLS is best we have, so your communication will be as secure as it gets with https alone, you don't need anything else