The below information is from reading the Wire Whitepaper. One could put it in browser storage, but what happens if a user changes browsers? Do you generate new keys each time a user uses a new browser? Or do you put the key material somewhere else on the user’s machine? At least for Wire, they do generate new keys when you use a new browser, which we’ll see more below. In the desktop application case, if the server you’re connected to is malicious they can’t replace the code running on your desktop.īut for e2e webapps, you’re trusting the server - and the integrity of the data flow between your browser and the server.Īnother challenge is you need to decide where to store the key material. This means a malicious server can tamper with any of the code served to you and can, for example, display “verified fingerprints” in the webapp while an active man-in-the-middle is taking place.Ĭompare this with developer-signed desktop applications, where you can ensure that code from the developer you trust is what is running. The main issue is that when you use an e2e webapp, the webserver you’re connected to is serving the cryptographic code to you. End-to-end over the webĪ lot has been written already on the significant challenges using a web browser for e2e crypto. As always, if you have thoughts on this or notice errors, feel free to drop me a note on Twitter or by email. I’m not looking into the voice and video aspects, just the messaging and file sharing capabilities as I’m investigating to see how a similar approach could be used for SecureDrop, where voice/video isn’t an option. Next in the series, I investigate current messaging applications that both provide web applications and are using the Signal Protocol (or a protocol very similar or derived from Signal), here specifically Wire and Whatsapp.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |