Ask HN: Why no browser-based E2E encryption?
5 コメント
[where this model breaks down] -- Alice and Bob go to your website and have a conversation. Eve hacks into the website and modifies the E2EE code. She can switch between serving the normal webapp and the malicious non-E2EE webapp. There's no good way to detect it. There are people out there who really like end to end security, but don't like browser-based e2ee because it doesn't have end to end security.
Note: https://www.cyph.com/ is a bbE2EE chat system.
Note: https://www.cyph.com/ is a bbE2EE chat system.
More generally: since you have to trust the server, you might as well just rely on TLS, because the "E2E" extra stuff isn't actually buying you anything. This is the Telegram model.
Perhaps search hnn for "cryptocat" which was an attempt to do e2e chat through a website a dozen years ago. It was somewhat controversial at the time.
https://hn.algolia.com/?q=cryptcat
The author gave up on it after a while and the website stopped working.
https://hn.algolia.com/?q=cryptcat
The author gave up on it after a while and the website stopped working.
Essentially the idea is that you land on the page and an asymmetric keypair is generated for you. You send a link to someone else that contains the public key in the URL. When they go to that link, they can encrypt a payload using your public key (envelope encryption, which I believe is needed for arbitrary payload sizes). They send you the encrypted payload back and you can decrypt in your existing browser session.
So if it's not obvious by now, I'm clearly no cryptography expert, but I know enough to be horrifyingly dangerous :). Can anyone here help me understand where this model breaks down, assuming someone very smart about this stuff were to do the implementation? Thank you!