Score:1

Crypto

Encrypt messages for two-participants chat

SparxDev

10/14/23, 3:52 PM

I need a chat between two users and I obviously want to make it as secure as possible. I am, by no means, a cryptography expert, so I turn to you guys for some advice.

Because I like the idea of having E2E encryption, I did some reading about the Diffie–Hellman method and the Signal Protocol.

My issue is that this is a web app and the users are not bound to a fixed device, so I can't just generate and store a key locally. Storing the key in a database would destroy the point of having E2EE.

I've read an article that Facebook Messenger is planning (or already has, idk I don't use Facebook lol) to implement E2EE for their messages, and because Facebook can be used via web – or more specifically, can be used from multiple devices – it has to be possible somehow, right?

I spoke to a professor at my uni about this and he suggested generating the keys from the user password upon login, but that would mean that the user can't change his password or else all his messages become inaccessible.

1 + 8

key-exchange

diffie-hellman

signal-protocol

kelalaka

10/14/23, 4:56 PM

The server can store the encrypred private keys with keys generated from user's password. The server can send the information to the user, and this runs locally on the user machines. Though you need some PAKE to never reveal the password of the users to the system...

SparxDev

10/14/23, 5:00 PM

But when storing the private key on the server, the server (and thus, a potential attacker) could decrypt the messages.

kelalaka

10/14/23, 5:13 PM

No, the private key is always stored encrypted. The server should never get the key in plain. All encryption and decryption of the private key is performed on the client side. This is one solution with goods and bads.

kelalaka

10/14/23, 5:15 PM

How do you think that WhatsApp web does works?

SparxDev

10/15/23, 6:17 AM

"the private key is always stored encrypted" - okay, and with whose key do I encrypt/decrypt it? This doesn't make any sense to me... The private key shouldn't be stored on the server at all (best case scenario)

p_1092131280

4/3/24, 12:34 PM

The private-keys are needed for the Signal-Protocol for example. The log-in password is a **different** key. The encryption of the Protocol-Private-Keys would be done by using the log-in password. Also old messages should be encrypted with the password.

Rohit Gupta

5/4/24, 3:57 AM

However you are storing the keys and messages. If the user changes his password, you can use the old password to decrypt the messages and re-encrypt with the new password.

SparxDev

5/4/24, 3:52 PM

@RohitGupta that only works if the user remembers his old password, because the password isn't saved in pain-text.

Score:0

Crypto

p_1092131280

4/3/24, 12:24 PM

I support the comments of @kelalaka. As far as I understand, you don't want to save the private keys on the server, even if they are encrypted with the latest password.

In general, regarding the server, your password is all the security you have. This has to be the case, because otherwise you wouldn't be able to use the application when logging in.

You have two options. First is, to generate all Private-Keys from the current password. This would mean, that the whole communication traffic (user to user) is based on this one password. Moreover, you would run into a problem when changing your password, for example with the change of the Identity-Key of X3DH.

The better option is to generate random Private-Keys, not generated from the password. This leads to a secure traffic for the Signal-communication. Of course, the keys are stored on the server. But they are secured with the power of the password, which is no less secure than the ability to generate the Private-Keys right away out of the password.

+ 0

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Encrypt messages for two-participants chat

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.