Bizarre Design Choices in Zoom’s End-to-End Encryption | Hacker News Reader

Bizarre Design Choices in Zoom’s End-to-End Encryption

soatok.blog

66 pointsnotRobot42 comments

I have to admit that I felt that the title wrote a cheque that it failed to cash.

I'm not sure who the intended audience is. It's light on crypto and it's light on furry stuff. I think both audiences will feel short-changed.

Hehe, you're not wrong on the lightness but I have to say I did enjoy the change of style and pace. Artwork was a nice touch as well.

Why is the author so fake-surprised that the source code isn't available on the internet? Zoom isn't open source software, and has never claimed to be. The title is also pure clickbait, since the article itself comes to the conclusion that the design is secure and the oddities are likely due to the need for legacy support.

Pure clickbait? The design choices are indeed bizarre, even if the reason ends up being for legacy support, no?

Well, bizarre would be using SHA3, some GOST algo, or maybe putting some postquantum crypto in there. The article describes something that is just a little strange.

PQC would be more interesting than bizarre and SHA-3 wouldn’t be bizarre at all (it’s a straight improvement on SHA-2 in isolation).

> (it’s a straight improvement on SHA-2 in isolation).

That's debatable.

Right, the only technical sense in which SHA-3 is simply "a straight improvement on" SHA-2 is resistance to length extension, but you can have that with SHA-512/256 (yes that's the name of one SHA-2 family member, if you didn't already know that, and you were previously confident SHA-3 is what you needed, time to do some reading). In a non-technical sense to be sure 3 is a bigger number than 2 but that's a terrible reason to do anything.

Keccak's sponge construction is novel, it has some cool features compared to Merkle–Damgård but when SHA-3 was standardised we had very little experience with this construction. Now, maybe we lucked out and these are the perfect parameters, not too slow, not too weak. But most likely we went too far in one direction and so hence "Maybe Skip SHA-3"

https://www.imperialviolet.org/2017/05/31/skipsha3.html

Writing a "perfect" encryption algorithm which doesn't actually support any of your existing clients or services would be bizarre. What they have done is standard software engineering.

"I've not seen this before, so it's weird and I don't like it."

Unfortunately, that sort of dogmatic cargo-culting is not restricted to security articles, although it seems a bit more prevalent in that area.

Except this isn't dogmatic cargo-culting, I've explained why it's a dangerous design decision to get in the habit of making on /r/crypto: https://old.reddit.com/r/crypto/comments/jkeq0z/bizarre_desi...

This might be deep lore that not everyone knows, but if you muck around with open source software for a while, you will discover that a lot of developers are somewhat impressionable. I've seen the "I did X because project Y did something similar and they were secure" genre of reasoning play out more than I care to remember.

Hi, author here.

> Why is the author so fake-surprised that the source code isn't available on the internet? Zoom isn't open source software, and has never claimed to be.

I don't use Zoom and wasn't familiar with the company before I looked at their whitepaper. It's not fake-surprised at all.

> The title is also pure clickbait, since the article itself comes to the conclusion that the design is secure and the oddities are likely due to the need for legacy support.

...Yes, but they're still oddities, right?

I wouldn't call a title clickbait when it's completely accurate.

If I found security issues, I would've titled it "Vulnerabilities in Zoom's End-to-End Encryption White Paper", if I even blogged about it at all.

> wasn't familiar with the company

I think you are in quite a rare position if you have not heard of Zoom but visit sites like this in 2020.

I am just curious with this following question. Do you usually not perform a search query before you read a paper?

> I think you are in quite a rare position if you have not heard of Zoom but visit sites like this in 2020.

I've heard of Zoom. But that doesn't mean I know their entire business strategy especially when it comes to open/closed source software.

I've also never had any reason to try it: I don't have any kids (so no school, etc.) and I lived most of my life too poor to afford health insurance, and I'm afraid to leave my house during the pandemic, so I still don't have a family doctor or anything of the sort to talk with. I work from home and use Slack for everything work-related (but Telegram elsewhere because that's where the furries all hang out for reasons I find wholly unsatisfying).

> Do you usually not perform a search query before you read a paper?

I'm curious: What precisely do you mean by "a search query"?

My search queries are usually of the form:

    site:github.com zoom encryption

So if I was supposed to find something more enlightening on the subject, my search habits probably weren't conducive to discovering it.

I mean go to www.google.com Type in "Zoom video communications"

I think some of the oddities can come from looking at sha256 as a way to make variable length data fixed length. Hashing the context and message before signing has the fingerprints of starting with RSA and pivoting later to ed25519. Janky for sure but really not bad at all. HMAC is cool and all, but from a practical standpoint you can do with concatenation if the message is prefixed with length, or you are using an algo such as blake2 where the keyed mode is prepending the key and the internal state does not allow for extension attacks.

As always: show us the source code if there's nothing to hide.

Theorycrafting: Is this choice of two SHA256's of different data a case of hedging your bets against a canonicalisation attack that may be involved in SHA512(Context || M).

The /r/crypto discussion on this might be worth considering too: https://old.reddit.com/r/crypto/comments/jkeq0z/bizarre_desi...

Ok, not using hmac in that one case is a mildly weird choice, but the criticism for choosing sha256 over sha512 seems a bit much to me.

I was expecting much more.

Reply on news.ycombinator.com