That's only spiritually correct. You can guarantee full e2e encryption with webapps, the issue is with the potential to leak the key to the middleman, giving them the ability to decrypt it as well - but itd still be e2e encrypted.
It means you either need to persist the key to localStorage or a cookie. If you clear your browsing data or switch browsers, you can't just log in again, you have to use an existing device to share the key (e.g., with a qr code). That's the friction.
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.
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.
PWA unlocked with a key is perfectly feasible. It keeps the key in memory and filters localstorage/network data with it. New instances require the key again. Have you ever used 1password or equivalents?
Comments
As long it’s an web app it cannot reliably guarantee e2e anyway, so where is the point
That's only spiritually correct. You can guarantee full e2e encryption with webapps, the issue is with the potential to leak the key to the middleman, giving them the ability to decrypt it as well - but itd still be e2e encrypted.
It means you either need to persist the key to localStorage or a cookie. If you clear your browsing data or switch browsers, you can't just log in again, you have to use an existing device to share the key (e.g., with a qr code). That's the friction.
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.
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.
PWA unlocked with a key is perfectly feasible. It keeps the key in memory and filters localstorage/network data with it. New instances require the key again. Have you ever used 1password or equivalents?