In my last blog post about Zoom, I noted that the company says “that critics have misunderstood how they do encryption.” New research from Citizen Lab show that not only were the critics correct, Zoom’s design shows that they’re completely ignorant about encryption. When companies roll their own crypto, I expect it to have flaws. I don’t expect those flaws to be errors I’d find unacceptable in an introductory undergraduate class, but that’s what happened here.

Let’s start with the egregious flaw. In this particular context, it’s probably not a real threat—I doubt if anyone but a major SIGINT agency could exploit it—but it’s just one of these things that you should absolutely never do: use the Electronic Code Book (ECB) mode of encryption for messages. Here’s what I’ve told my students about ECB:

• Direct use of a block cipher is inadvisable
• Enemy can build up “code book” of plaintext/ciphertext equivalents
• Direct use of the block cipher [is]
• Used primarily to transmit encrypted keys
• Very weak if used for general-purpose encryption; never use it for a file or a message.
• Attacker can build up codebook; no semantic security

Again, it would be hard to exploit here, but it suggests that the encryption code was written by someone who knew nothing whatsoever about the subject—and lays open the suspicion that there are deeper, more subtle problems. I mean, subtle problems are hard to avoid in cryptography even when you know what you’re doing.

The more important error isn’t that egregious, but it does show a fundamental misunderstanding of what “end-to-end encryption” means. The definition from a recent Internet Society brief is a good one:

End-to-end (E2E) encryption is any form of encryption in which only the sender and intended recipient hold the keys to decrypt the message. The most important aspect of E2E encryption is that no third party, even the party providing the communication service, has knowledge of the encryption keys.

As shown by Citizen Lab, Zoom’s code does not meet that definition:

By default, all participants’ audio and video in a Zoom meeting appear to be encrypted and decrypted with a single AES-128 key shared amongst the participants. The AES key appears to be generated and distributed to the meeting’s participants by Zoom servers.

Zoom has the key, and could, in principle, retain it and use it to decrypt conversations. They say they do not do so, which is good, but this clearly does not meet the definition [emphasis added]: no third party, even the party providing the communication service, has knowledge of the encryption keys.”

Doing key management—that is, ensuring that the proper parties and only the proper parties know the key—is a hard problem, especially in a multiparty conversation. At a minimum, you need assurance that someone you’re talking to is indeed the proper party, and not some interloper or eavesdropper. That, in turn, requires that anyone who is concerned about the security of the conversation has to have some reason to believe in the other parties’ identities, whether via direct authentication or because some trusted party has vouched for them. On today’s Internet, when consumers log on to a remote site, they typically supply a password or the like to authenticate themselves, but the site’s own identity is established via a trusted third party known as a certificate authority.

Zoom can’t quite do identification correctly. You can have a login with Zoom, and meeting hosts generally do, but often, participants do not. Again, this is less of an issue in an enterprise setting, where most users could be registered, but that won’t always be true for, say, university or school classes. Without participant identification and authentication, it isn’t possible for Zoom to set up a strongly protected session, no matter how good their cryptography; you could end up talking to Boris or Natasha when you really wanted to talk confidentially to moose or squirrel.

You can associate a password or PIN with a meeting invitation, but Zoom knows this value and uses it for access control, meaning that it’s not a good enough secret to use to set up a secure, private conference.

Suppose, though, that all participants are strongly authenticated and have some cryptographic credentials they can use to authenticate themselves. Can Zoom software then set up true end-to-end encryption? Yes, it can, but it requires sophisticated cryptographic mechanisms. Zoom manifestly does not have the right expertise to set up something like that, or they wouldn’t use ECB mode or misunderstand what end-to-end encryption really is.

Suppose that Zoom wants to do everything right. Could they retrofit true end-to-end encryption, done properly? The sticking point is likely to be authenticating users. Zoom likes to outsource authentication to its enterprise clients, which is great for their intended market but says nothing about the existence of cryptographic credentials.

All that said, it might be possible to use a so-called Password-authenticated key exchange (PAKE) protocol to let participants themselves agree on a secure, shared key. (Disclaimer: many years ago, a colleague and I co-invented EKE, the first such scheme.) But multiparty PAKEs are rather rare. I don’t know if there are any that are secure enough and would scale to enough users.

So: Zoom is doing its cryptography very badly, and while some of the errors can be fixed pretty easily, others are difficult and will take time and expertise to solve.