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

[Ángel]

On 2020-04-02 at 23:57 -0400, Phillip Hallam-Baker wrote:
> 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.
> 

I don't think you *really* need OTR encryption for a video meeting
program. It makes sense on a messaging platform where the same "thread"
continues for months, so you want to rotate the keys frequently enough¹
so that a stolen key doesn't allow to decrypt past ciphertexts¹ nor
intercept future communications. So far, so good. But here our usecase
is a virtual meeting. The average length of these would maybe be around
an hour. Just generate a new symmetric key when the session starts and
discard it at the end. You have deniability in that the other side could
have created the same stream. Yes, an attacker that got hold of the key
could decrypt a network stream that it had separately recorded. Or probe
that the video evidence matches the notarized encrypted network content.
However, on a video stream you would be easily identified by voice /
image, and analyzed checking its continuity, not using those roundabout
ways. In order to decrypt the traffic, Eve would need to extract the key
from an identity joined in the meeting, which could as well be recording
it locally and then forwarding to her. Thus, if you are dealing with
well-behaved software your OTR could simply be a signal in the stream
that kindly asks not to allow local recording.²

Sure, an encryption key is easier to leak unnoticed than a full video
stream, and there would occasionally be some uncommon meetings, such as
one that is hosted by a streaming security camera. It is good to have
the ability to rekey, but you don't need to do so constantly.
I expect that in addition to the udp video stream, the system would also
use a separate reliable stream for things like metadata, text chat,
people join/part, raise hand, etc. where rekeying info could be easily
included. But in fact, the only use case I can think that actually would
need it would be when someone leaves a meeting that will turn into
things that they shall not know about (e.g. a job interview where after
the candidate leaves the interviewers continue on the same chat room,
discussing if they would like to hire him or not).


Kind regards


¹ An attacker that was able to obtain the keys would probably find a
copy of the whole history alongside, though.
² And a determined attacker legitimately allowed to watch the meeting
could just point a video camera to the computer screen.