Bizarre Design Choices

[soatok]

I wrote a blog post about bizarre design decisions in the Zoom's E2EE whitepaper and wanted to raise them here on Github.

My hope is that, if a good reason exists, these decisions can be explained/justified in a future edition of the whitepaper... and if there is no good reason for the specific design decisions, that they can be reconsidered.

• Section 3.5.1

Use of SHA256(Context) || SHA256(M) is a little weird considering Ed25519 uses SHA512 under-the-hood.

• Section 3.5.2

You aren't actually using crypto_box here. You're using your own construction. The only function in the crypto_box namespace that's being used is crypto_box_beforenm which is just crypto_scalarmult() and HSalsa20.

• Section 3.8

The constant here is Zoombase-1-ClientOnly-MAC-SecurityCode, but you aren't actually using a MAC algorithm )e.g. HMAC). In section 4.1.4, your design demonstrates awareness of HMAC, so I don't understand why this wasn't used here.

[AMarcedone]

Thanks for your comments.

• We believe SHA256’s security guarantees are appropriate for our application. This particular design stems simply from convenience in the implementation, and as you point out there are no security vulnerabilities that we are aware of.
• We will clarify that we are not using crypto_box directly
• We realize the name "Zoombase-1-ClientOnly-MAC-SecurityCode" could be misleading, but updating it is not worth it as we would lose backwards compatibility