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

other.arkitech other.arkitech at protonmail.com
Tue May 26 18:56:14 EDT 2020




Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, May 26, 2020 2:00 AM, John Gilmore <gnu at toad.com> wrote:

> Blog post:
>
> https://blog.zoom.us/wordpress/2020/05/22/zoom-publishes-draft-design-of-end-to-end-encryption-offering/
>
> Draft design:
>
> https://github.com/zoom/zoom-e2e-whitepaper/raw/master/zoom_e2e.pdf
>
> E2E Encryption for Zoom Meetings
>
> Josh Blum, Simon Booth, Oded Gal, Maxwell Krohn, Karan Lyons, Antonio
> Marcedone, Mike Maxim, Merry Ember Mou, Jack O’Connor, Miles Steele,
> Matthew Green(*), Lea Kissner, and Alex Stamos(**)
>
> Zoom Video Communications
>
> -   Johns Hopkins University
>     ** Stanford University
>     May 22, 2020
>     Version 1
>
>     Introduction
>
>     Hundreds of millions of participants join Zoom Meetings each day. They
>     use Zoom to learn among classmates scattered by recent events, to
>     connect with friends and family, to collab- orate with colleagues and,
>     in some cases, to discuss critical matters of state. Zoom users
>     deserve excellent security guarantees, and Zoom is working to provide
>     these protections in a transparent and peer-reviewed process. This
>     document, mindful of practical constraints, proposes major security
>     and privacy upgrades for Zoom.
>
>     We are at the beginning of a process of consultation with multiple
>     stakeholders, including clients, cryptography experts, and civil
>     society. As we receive feedback, we will update this document to
>     reflect changes in roadmap and cryptographic design.
>
>     ...
>
>     This proposal lays out a long-term roadmap for E2E security in Zoom in
>     four phases. The first phase is an upgrade of the meeting key
>     exchange protocol to use public-key cryptography, hiding all secret
>     keys from the server. The next three phases harden the notion of a
>     user’s identity—even across multiple devices—to help maintain server
>     honesty in the key exchange and to give hosts better information when
>     allowing or disallowing participation in a meeting. We provide the
>     most detail for the earliest stages. We surmise that the specifics of
>     later phases will change with more implementation and deployment
>     experience.
>
>     ...
>
>     In an ideal world, all public key cryptographic operations could
>     happen via Diffie-Hellman over Curve25519 [3], and EdDSA over Ed25519
>     [4]. Relative to others, this curve and algorithm family have shown
>     a consistent track record for resilience to common cryptographic
>     attacks and implementation mistakes. These algorithms are currently in
>     review for FIPS certification but, unfortunately, are not currently
>     approved. Therefore, in some cases (like government uses that require
>     FIPS certification) we must fall back to FIPS-approved algorithms,
>     like ECDSA and ECDH over curve P-384. The protocol below has support
>     for both algorithm families, and for now “doubles up” all public key
>     operations. This technique eliminates error-prone branching. Once
>     certification succeeds, we can safely “no-op” the operations over
>     P-384.
>



I wonder why not using the same secp256k1 used by Bitcoin. It is bullet proof as it is publicly able to keep safe billions in capitalization.
I wonder why this is not the cypher suite of choice today.






>     John
>
>     PS: I think I see a denial-of-service attack in section 3.7.3,
>     "Participant Join (Leader)". If a second participant Mallory can post
>     an invalid signed binding claiming to be for a first participant Bob,
>     to the meeting's crypto bulletin board, then the leader's algorithm
>     aborts ("If verification fails, it aborts"), it doesn't post the
>     encrypted meeting key for Bob, and Bob is locked out of the meeting.
>     Fixing this may mean more tightly specifying how the "bulletin board"
>     works, as opposed to letting any participant post any message to it
>     at any time.
>
>
> The cryptography mailing list
> cryptography at metzdowd.com
> https://www.metzdowd.com/mailman/listinfo/cryptography




More information about the cryptography mailing list