[Cryptography] Zoom publishes draft cryptographic design for end-to-end encryption
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:
> Draft design:
> 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
> 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
> In an ideal world, all public key cryptographic operations could
> happen via Diffie-Hellman over Curve25519 , and EdDSA over Ed25519
> . 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
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.
> 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
More information about the cryptography