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

[Phillip Hallam-Baker]

On Thu, Apr 2, 2020 at 9:21 PM Peter Fairbrother <peter at tsto.co.uk> wrote:

> actually end-to-end at all. Good thing the PM isn't using it for Cabinet
> calls. Oh, for f..."
>
> https://www.theregister.co.uk/2020/04/01/zoom_spotlight/
>
> tldr:
>
> not end-to-end despite explicit claim
> mines all your data
> tracker-friendly
> sends data to facebook
> big login hole
> host can detect if watchers present
> all your base are belong to us
>

It is all fixable. Question is whether they will have the nouse to fix it
or not.

We should have an open standard for end-to-end secure video conferencing
that uses a client that doesn't have HTML, Javascript and all that stuff
included in it. Which leaves out WebRTC as well.

Having been thinking on these lines, the pushback I have got from the
people in the field are that the reflector has to be able to see the
plaintext of the fields because that is the only place they can think of to
change the resolutions.

I think the obvious answer is to do resolution changes at the device that
is originating that image. So there are three basic possibilities. My
camera is off, My camera is on and I am sending a thumbnail image and My
camera is on and I am sending separate thumbnail and large images.

Of course 'thumbnail' probably means dropping the bit rate as well. So we
want to expose enough information to the reflector to allow it to know
which encrypted frames are the keyframes, which are the deltas and so on.

So the hard part is in the encoding stuff. And you have to really have a
handle on that because all the major platforms have very different API
models so that they can make use of the hardware assistance for the CODECs .

I remain profoundly unmoved by the obsession certain folk have with 'off
the record' capability. The MLS tree is just too complex to be viable in my
opinion. I want end-to-end secure communications of course. And sometimes I
want forward secrecy. But in an enterprise setting I want to record a lot
of calls and store them on disk forever because this is about getting work
done, not playing Mission Impossible. I never did understand why the
recording announcing a mission self destructed when it came with a big fat
dossier that was far more sensitive.

So the approach I am taking is to make use of threshold cryptography to
provide end-to-end security. There is an encryption key for the group and a
separate threshold split of the private key for each member the
administrator adds.

In the case that we want a portion of a conference to be off the record
(i.e. with forward secrecy enforced), each participant's device posts an
ephemeral key that is used to establish a second shared secret with either
the key management service or an administrator. If you have 100 people in
the channel and you rekey once an hour, having that performed by
administrator's machine is not a problem. If you have more than 100 people
in the conference your cryptography is nowhere close to being your weakest
link.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20200402/4f097ef0/attachment.htm>