Here’s my problem: every F(L)OSS and E2EE solution that I know of requires other people to download an app or log in.
I want to reduce the friction for others to communicate for me. I want to give a business card with a URL where people can go and immediately send messages to my Matrix or my email or something, and they don’t need to log in at all.
They just open their browser, go to snek_boi.io or whatever and a chat appears.
A couple of years ago, I was suggested Cactus Comments. I suppose that works, but I was wondering if there are other solutions. I was wondering if now there was an even easier solution for my purposes.
Can you expand more on the key management? I thought https://chat-e2ee-2.azurewebsites.net/ passes a PSK Through the header and sets that as a cookie in the browser to sign further comms. I could be mistaken of course.
Yes you can juryrig something like that with cookies, but it is highly fragile and browser based e2ee is basically a scam anyways as the server serving the website can always swap out the javascript that decrypts the messages.
Fragility is by design as it’s ephemeral comms. Swapping the js decryption doesn’t make sense as wouldn’t the client just fail or refuse the message stream as the decrypt/encrypt changed? It’s an interesting problem. Thanks for giving me something to noodle on.
The server can swap to a modified JS that exfiltrates the e2ee key and thus allows the server owner to decrypt the messages, or in more advanced encryption schemes add additional keys without you knowing and achieve the same thing.
https://medium.com/sessionstack-blog/how-javascript-works-cryptography-how-to-deal-with-man-in-the-middle-mitm-attacks-bf8fc6be546c
I still don’t see how
or
Wouldn’t significantly change the recieved hash and break the stream thus ending comms. Also unless you’re hosting and building it yourself you have to trust the recipient and the cloud host.
I agree if an attacker owns the server comms can be compromised. I thought that was the benefit of the ephemeral nature. It’s for quick relay of information. Best practices would probably include another cypher within the messages themselves like a one time pad or some such.
https://www.itstactical.com/intellicom/tradecraft/uncrackable-diy-pencil-and-paper-encryption/
https://github.com/muke1908/chat-e2ee