Zoom Finally Takes Encryption Seriously: And Goes All GCM

Zoom Finally Takes Encryption Seriously: And Goes All GCM

Still not end-to-end, but a big improvement!

Zoom’s encryption has — to the say least — been novice. They used 128-bit AES keys and with ECB (Electronic Code Book). Any cybersecurity student should know that ECB is shockingly insecure (and is almost laughable in its implementation). But after great pressure from many in the community, Zoom is now upgrading with a new high-quality upgrade — 256-bit AES with GCM (Galois/Counter Mode).

So why GCM? Well, it’s perfect for video conferencing as it is a stream cipher, rather than a block cipher. Here is my implementation of the different modes:

Notice that the stream methods (OTB and GCM) do not need padding, as all we need to encrypt is an XOR of the data stream with the keystream. The processing thus becomes a key generation process and then once generated, it is a simple operation of XOR-ing the bits of the data stream and the keystream.

All of the AES modes use a salt (or IV) value, apart from ECB. With CBC we have feedback fed into future blocks, and where it is thus slow, as we need to process the data blocks (128-bit) in sequence. In GCM, we can run the blocks in the stream in parallel, and which significantly increases the encryption and decryption process.

A sample run shows CMS padding for ECB, CBC and CFB, but where it is not required for OFB and GCM [here]:

IV: 000000000000000a
Input data (CMS): 68656c6c6f0b0b0b0b0b0b0b0b0b0b0b
Cipher (ECB): 3c0076b3fc7418fe876700a9b23f19d9
 decrypt: hello
Cipher (CBC): 578f4504c95b43dedc98a171474b69c8
 decrypt: hello
Cipher (CFB): d082803b9ab6026db1e9d73dd5705ab5
 decrypt: hello
Cipher (OFB): d06b435968
 decrypt: hello
Cipher (GCM): 9b1785bb25
 decrypt: hello

One of the great things about GCM is that we can authenticate our encryption, and where we can sign the ciphertext. In this case, we will use Golang to create the GGM cipher:

Note, that the new Zoom update it is still not end-to-end encryption, and is simply an encryption of the data stream. It’s a step in the right direction, though.

Message: hello
Cipher: 3121f5871d871d9560f05cd61ee44822957a0a4cd6
Key: 2cd725c80452e8319b76ea90dd0ac08c7db8898f68ffa422e8caae727f6911bb
Nonce: 984212c7fa0b87bb6730cd00
Decrypted: hello

In this case, the GCM cipher contains an authentication tag, and which is checked when decrypted.

Conclusion

To say that Zoom’s security has been at the novice level is an understatement (previously the setup a server on the host machine, and where anyone could connect in). One would not even imagine an undergraduate student making the same of the design choices they have made in the past. But, they struck lucky at the start of the lockdown, and users found Zoom so much easier to run. But now organisations are rejecting it, as the security has been so weak. So, finally, Zoom is building their software with standard good practice. Hopefully, they will learn from this, and invest in strong security, especially with end-to-end encryption.

If you like Java, here’s some AES-GCM in Google Tink:

and here is CTR and OFB mode: