Comment by upofadown | Hacker News Reader

Comment by upofadown | Hacker News Reader

Parent Full thread

Inherent to any e2e encryption scheme is the question; are you talking to who you think you are talking to? In other words; are you the victim of a man in the middle attack?

So if you ever encounter a system that has the ease of use feature where you don't have to verify the identity of the other participant(s) with something like a identity fingerprint number then you already know you do not have all the protection that e2e encryption can provide. This is particularly relevant in a case like Zoom, where all the data goes through servers that Zoom controls making a MITM attack trivial.

So we really should of known that Zoom doesn't provide complete e2e encryption already just from the lack of the identity check.

Skipping the identity verification step seems to be common these days. Even Signal does that by default, but they at least make the verification of what they call "safety numbers" fairly easy and straightforward.

Added: So can true e2e encryption ever be practical for conferences involving a large number of participants? Perhaps Zoom is claiming the impossible... The issues surrounding the addition of OMEMO encryption to XMPP conferences make for an entirely relevant example. What do you do if one of the participants is not known to all the others? There are lots of possible answers to that question.

Added2: >The only feature of Zoom that does appear to be end-to-end encrypted is in-meeting text chat.

I don't see how this can be true either based on the same thinking.

It is possible to have conference calls with e2e encryption.

Many conference calls are implemented using what's called a Selective Forwarding Unit (SFU) and the sending clients send multiple resolutions (either independent, called "Simulcast" or dependent, called "SVC"). In that case, the adaptation is done by the server in selecting which resolution to forward at any given time. This is fairly common practice in the industry. For example: https://github.com/jitsi/jitsi-videobridge and https://tools.ietf.org/html/draft-aboba-avtcore-sfu-rtp-00 and https://www.w3.org/TR/webrtc-svc/.

For those types of conference calls, the server only needs to know the sizes of the various streams and which packet is for what stream. It does not need to see the decrypted media, so one can implement e2e encryption for such types of group calls. This is less common in the industry, but is possible. For example: https://support.google.com/duo/answer/9280240?hl=en

(I used to work at Google on WebRTC, Duo, and Hangouts, but now work on video calling at Signal).

It's true that you need an out-of-band verification to determine who the other party is in an end-to-end encrypted system. But it is not true that the absence of such a verification means you don't have end-to-end encryption.

It means only that you don't know for sure who the other party is. You are only put at risk if there is an active MITM attack in progress.

Depending on your threat model that's an enormous change.

Additionally, just because you have o-o-b verification, that still doesn't mean that it is e2ee. Until you can view the source and build it yourself, who knows what back doors could exist. But this is the challenge, how do you balance security and convenience? People, by and large, aren't building source and side loading. They are going to have to take a leap and trust someone. It is a very hard problem to solve. Generally, no one cares until the one bad thing happens, then they care immensely. I've said that it is hard to get people to care about privacy when they live stream and share pictures of their life every 30 minutes already.

Just semantics at this point. A system that distributed the keys to all participants in the clear from a central server is still encrypted end to end in some sense. As pointed out by someone else in this comment section, the expression "end to end encryption" comes from the early day of PGP. PGP specifically protects against MITM with a fairly sophisticated web of trust system. So it is entirely legitimate to assume that e2e encryption includes MITM protection as a hard requirement.

PGP's "Web of trust" doesn't actually scale and so it doesn't meaningfully improve upon just doing out-of-band verification with a handful of your closest peers and nothing for everybody else.

Web of trust can give an illusion of scaling because it uses sleight of hand to persuade you to accept transitivity of trust. If you see someone who took this seriously you'll find that almost all contacts show as "unverified" (when I've had PGP setups in the past that's what happened). If they just click blindly along accepting trust transitivity then everything is "verified" but based on trust beliefs that have no basis in reality.

The sleight of hand goes like this. You trust Alice. Alice says this is Bob and she trusts Bob. The correct inference is that this is indeed Bob (Alice says so and we trust her) but we still don't trust Bob. PGP tries hard to persuade you that you in fact now trust Bob. Bob says another contact is Carol, and he trusts Carol. The correct inference is null, we don't trust Bob so we don't care what Bob says. But PGP encourages us to accept that this is Carol and we should trust Carol too.

How stupid the WOT may or may not be affects my point about what the phrase "e2e encryption" means not at all.

Reply on news.ycombinator.com