3 ms·

Now I could be way off here, but could you hash/salt the users password in 2 different ways: - the first way would be used before sending the password to the s

Now I could be way off here, but could you hash/salt the users password in 2 different ways: - the first way would be used before sending the password to the server. This would then be hashed and salted again to be used for authentication with the server. - the second way would be used locally. You could have the user create a pin to go with the password that would be used to create this hash. This hash would be the key to decrypt the contents. It would never be sent to the server. I haven’t actually done the thinking or research to validate or invalidate something like this though. My uses of encryption have all been rather standardized.

bastawhiz 2y ago
It's not a password, it's an encryption key. You don't want to use a password because if you can derive a key from the password it means there's one key per password. You can salt them but then the server can crack your key because it's exactly the same complexity as cracking a password (since the server has the salt). If you're doing e2ee, anyone you chat with needs to exchange key material with you (like diffie-hellman). Your private key decrypts messages sent to you, while the public key that you share encrypts messages that can be decrypted with your private key. The process has little to do with authenticating with the server, it has everything to do with exchanging keys with the people you talk to. And you can't just trust the server to do it, since a malicious server could just send its own public keys to the chat participants and man-in-the-middle the conversation. If you want to use Signal on your laptop instead of your phone, your private key needs to get to the laptop without going through the server. You could encrypt it, but then you need to encrypt it using a key derived from a password or PIN, and now you have the same problem as before.

bastawhiz 2y ago

It's not a password, it's an encryption key. You don't want to use a password because if you can derive a key from the password it means there's one key per password. You can salt them but then the server can crack your key because it's exactly the same complexity as cracking a password (since the server has the salt). If you're doing e2ee, anyone you chat with needs to exchange key material with you (like diffie-hellman). Your private key decrypts messages sent to you, while the public key that you share encrypts messages that can be decrypted with your private key. The process has little to do with authenticating with the server, it has everything to do with exchanging keys with the people you talk to. And you can't just trust the server to do it, since a malicious server could just send its own public keys to the chat participants and man-in-the-middle the conversation. If you want to use Signal on your laptop instead of your phone, your private key needs to get to the laptop without going through the server. You could encrypt it, but then you need to encrypt it using a key derived from a password or PIN, and now you have the same problem as before.