[Cryptography] Zoom publishes draft cryptographic design for end-to-end encryption

[Phillip Hallam-Baker]

On Fri, Jun 5, 2020 at 2:54 PM Lea Kissner <chialea at gmail.com> wrote:

> I know I'm not active here, but hi. We're aware that binary transparency
> exists, it's just not on the first few priorities, which should help
> protect against risk of targeted backdoors. That's quite a lot of why
> web clients are specifically excluded.
>

I was considering the issue more as a research challenge problem for the
general case.

End to end is important but Zoom is not my first concern. There is
relatively little I can learn from video quickly unless people are
livestreaming activities that would render them vulnerable to coercion. I
stated that in the first video I made on Zoom crypto.

What worries me most are shared documents. An attacker can download them
and use regex searches to find the good stuff in megabytes of material. So
Google Docs, Dropbox, Slack etc worry me more. Github is also a concern.

Next concern after that is asynchronous messaging such as email. It should
be clear at this point that S/MIME and OpenPGP don't meet the user
requirements to become ubiquitous and never will.

On the code transparency/validation front, I think we are going to have to
start seeing 'designed for validation' as part of the spec. For example,
anything that can read/write arbitrary files on disk is going to be really
hard to verify. That risk can be minimized by funneling all file handling
system calls through a single point that limits access to the limited
directory locations an app is allowed to access. Essentially the principle
of Hoare's monitors brought into the application layer.

Assume for the sake of argument that we are using a managed code language
such as C# and that we do not allow code obfuscation or some of the more
aggressive features (e.g. ability to generate and compile code on the fly).
Further assume that it provides the .NET style 'strong assembly' capability.

Using those capabilities it would be possible to determine by static
analysis of the executable that it was using a particular support library
that prevents the code exceeding its intended privileges. Essentially
providing a 'trusted computing base in software'

Instead of validating the entire program, it would be sufficient to check
that it only used managed code libraries with no native code and that the
support library had the appropriate checking.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20200608/ca078054/attachment.htm>