[Cryptography] "Zoom's end-to-end encryption isn't

Benjamin Kreuter brk7bx at virginia.edu
Sun Apr 5 13:14:06 EDT 2020

On Sat, 2020-04-04 at 13:52 +0100, Peter Fairbrother wrote:
> On 04/04/2020 01:29, John Levine wrote:
> > In article <c3a39de0-e62a-0bde-5f0c-8eafb968cef4 at tsto.co.uk> you
> > write:
> > > To begin: You don't use, or need, a central server.
> > 
> > That seems awfully optimistic.  
> It is not optimism, grasshopper, it is formulated as a
> requirement.  :)
> How are the people supposed to find each other?
> I have never used Zoom, so I am at a disadvantage insofar as knowing
> the 
> expected user interaction and features,

Currently users receive a URL by email, and then Zoom is launched as
needed for their platform (with the browser being used as a last resort
if no standalone app can be launched).  One very convenient aspect is
that the URL can also be added to a person's calendar, which really
helps in the "enterprise" setting.

> How do people find each other with Zoom? I'd guess through email or 
> mobile numbers.

What are the participants going to receive by email?  The real issue is
that somehow the participants need to learn each other's IP addresses
if there is no central directory service or infrastructure (e.g.
federated servers, as one has with SIP) to coordinate everything.  It
is the same peer-to-peer bootstrapping problem that people have been
working around for decades.

> > Also, in the absence of a central server every participant needs to
> > send N streams to the N other participants 
> Only streams between the conference host and the participants are
> required.

Which would be great if the conference host has a reliable and high-
throughput connection.  Unfortunately that is not always true, and
becomes more and more difficult as the number of participants grows. 
In some cases it would become hard even with fiber optic service; for
example, if a single person is presenting to 1000+ participants (i.e. a
broadcast scenario).

> As an aside, the main raison d'etre for central servers is often
> more 
> related to income streams than to functionality or security.

Actually it is functionality, which is what drives income; security is
an orthogonal concern.  The fact is that peer-to-peer video
conferencing is hard to do.  Most people have the requisite software
(netmeeting, ekiga, etc.) to do peer-to-peer video conferences, but
without at least having a directory service it is just too painful to
set up just a 1:1 chat, let alone multiparty conferences.  As for end-
to-end encryption of video conferences, it is a technically challenging
problem and there is a long history of broken protocols (including
several cases of the notorious problem of bad composition of
compression with encryption).

(Not that any of this excuses Zoom's claims about end-to-end encryption
nor their decision to roll their own cryptosystem.)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20200405/a9e417e2/attachment.sig>

More information about the cryptography mailing list