3 ms·
Couldn't this be solved by Diffie-Helman key exchange? [1] [1] https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange https://en.wikipedia.org/wiki/
by rmbyrro 5y ago
Couldn't this be solved by Diffie-Helman key exchange? [1]
[1] https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exc...
- acoard 5y agoUsing the Diffie-Helman would be good practice, but it's not enough to assume a defence against a malevolent actor who controls the client. It's not about the key exchange itself. Essentially, a determined malevolent actor who controls the client could exfiltrate your keys easily. Maybe it's intentionally introducing a subtle vulnerability and then exploiting it server-side[0], or it's just simply doing a file upload of the keys. Basically, you can't be certain there isn't a backdoor from a malevolent actor. [0] IIRC, there was some vulnerability in the Linux Kernel a few years ago that was basically there due to an errant space. Some people theorized that this could have actually been intentionally introduced by sophisticated actors, to hide in plain-sight open source code.
- chrismorgan 5y agoNo. The problem with first-party end-to-end encryption is that the entity whose customer you are not just providing the pipe for unknown encrypted traffic, but are also providing the encryption software, and can therefore subvert the encryption software (in order to report the key, or other similar actions) if they decide to act maliciously, or are compelled to by any third party (most likely government). If the software is third-party, then the service provider cannot breach the encryption in any way, or provide any assistance in doing so: the third-party software provider will be the party to attack/require to insert a back door, which in this age will generally be a fair bit harder, though it’s far from inviolable.