[f38zf5vdt]

When a product specifies "end to end encryption" my expectation is that the only function of the server is to pass the public keys from two clients around so they can Diffie-Hellman kx to achieve a mutually shared private key to encrypt their communications to each other, so that information flow is:

client <--> client (no server knowledge of communications aside from the encrypted packets being passed back end forth)

Not:

client <--> server <--> client (server controls the encryption keys and can snoop on client communication at any time)

Signal and Matrix Synapse/Riot is the former, Zoom and Jitsi are the latter. While it's true that the server could also MITM and provide false keys to each client, both Signal and Riot let you view the keys of the person you're communicating with so you can verify you're not being MITM'd.

[geofft]

I'm not sure what to do with systems like iMessage/FaceTime under this definition, where the server doesn't hold the private keys but also the client provides no means to check fingerprints out-of-band. In these systems, the server could MITM the clients to each other and thereby snoop on client communications with the same effective result as Zoom/Jitsi. (These systems also generally support changing the peer's fingerprint without notification.) But we still call those "end-to-end encrypted," right?

Is there a meaningful end-user difference between a design where you have to ask the server for your peer's public key and the server promises to be honest, and a design where the server generates a shared secret and then promises not to use it?

(Note that this question is completely orthogonal to whether the client or server are source-available - unless you can modify the client to display peer fingerprints, merely knowing that you're going to have to trust the server doesn't really change anything.)

[pbhjpbhj]

You appear to also realise that if it's a closed source client then the server could be fine, the client could do all the snooping and pass data in a side channel. It's worth spelling that out IMO.

[wilg]

Even worse, the same could happen if it's an open source client!

[geofft]

Right,

- if it's an open-source client but it doesn't display fingerprints and you haven't modified it, you're stuck. (At least you know you're stuck, but you knew that already.)

- if it's an open-source client but you're trusting someone else's binary, they can attack you.

- if it's an open-source client but you're not trusting someone else's binary, you're not on the embargo list and so responsibly-disclosed bugs are effectively zero-days for you.

- if it's an open-source client but it's written in C, you have no practical way of auditing it against intentionally-malicious source code (i.e., for almost everyone, the cost of auditing it is higher than the cost of visiting your conversation partner in person).

[cpeterso]

How do iMessage and FaceTime provide end-to-end encryption? Is there a public key associated with Apple account? How does my private key get on different Apple devices without my help?

[gruez]

>Is there a public key associated with Apple account

with each device

https://manuals.info.apple.com/MANUALS/1000/MA1902/en_US/app...