Zoom端到端加密的离奇设计选择

Zoom最近宣布，他们将向所有用户提供端到端加密，而不仅仅是客户。

我们新的端到端加密(E2EE)功能现在可供全球用户免费和付费使用。Https://t.co/ssGanYn4fB🔒。

-ZOOOOM👻(@ZOOM_US)2020年10月26日。

这是一个很好的举措，特别是对于生活在领导层无能的国家的人们来说，这些国家未能应对新冠肺炎疫情，因此需要通过Zoom这样的软件远程进行工作和学习。我热烈地为他们做出这一改变而鼓掌。

今年早些时候，他们收购了Keybase，紧随其后的是端到端加密功能。聘请一支由安全专家和密码学工程师组成的团队似乎是一项不错的举措。

听到这个消息后，我决定做一个好邻居，看看他们的源代码，推理是这样的：“如果这么多人的隐私依赖于Zoom的安全，我不妨确保他们不会做一些可笑的坏事。”

只是我在网上找不到他们的源代码。但是他们确实发表了一份关于github…的白皮书。

下面是互联网上一些人的观点-所以你是否选择认真对待它应该从这个背景中得到信息。这不是任何人的雇主的意见，也不是Zoom等的认可。告诉你的律师让他们冷静下来。

更重要的是，我在这里并不是要憎恨Zoom做了一件好事，也不是要憎恨那些努力让Zoom更好地为他们的用户服务的安全专家。毕竟，安全专业人员对用户负有责任。

另外，现在不是零日，所以不要试图对我讲“负责任的”披露。(顺便说一句，这个术语也有问题。)。

注意：我已经将屏幕截图更改为黑色背景上的白色文本，因为我的博客的配色方案比典型的学术PDF更暗。你可以在这里找到来源。

考虑到Ed25519在内部使用SHA512，他们在SHA256(上下文)||SHA256(M)上计算签名有点奇怪。

直接对上下文||M进行签名也同样有意义-或者，如果需要预散列大型流，则使用SHA512(上下文||M)。

在这一节的顶部，它说它使用libNa的加密箱接口。但之后他们就会上…。而不是真正使用它。

正在使用的libNa接口的唯一部分是crypto_box_beforenm()，它很容易成为对crypto_scalarmult()的调用(因为它们无论如何都会将标量乘法的输出传递给HKDF)。

此外，SHA256(A)||SHA256(B)模式也会返回。出于某种原因，Zoom的工程师一定很喜欢SHA256。

将密文和签名绑定到相同的上下文字符串是明智的做法，只是当SHA512存在时，SHA256散列的连接有点奇怪。

在这里，我们看到了在尝试为HMAC但失败的构造中使用常量字符串(“Zoombase-1-ClientOnly-MAC-SecurityCode”)的SHA256的Zoom。

然后，他们将其与公钥的SHA256散列(已经是256位的值)连接起来，然后再次对整个过程进行散列。

一直往下都是多余的SHA256。常量字符串中“MAC”和“SecurityCode”的冗余至少与其设计理念的其余部分一致。

如果双重散列有使安全证明无效的风险，或者如果HMAC的安全证明需要填充常量的高汉明距离，并且此设计决定后来还使HMAC免于相关密钥攻击，那将是一件非常遗憾的事情。

等等你是说Zoom一直都知道HMAC的存在？

我在这里批评过的Zoom所做的设计决定都不是安全漏洞，但它们确实表明了他们在产品设计中早期缺乏密码学专业知识。

毕竟，奇怪之处几乎全部包含在他们的白皮书第三部分，其中描述了他们推出的“第一阶段”。因此，我在这里指出的似乎主要是遗留的问题，没有足够的风险来费心在最终设计中进行更改。

他们论文的其余部分相当直截了当，读起来也很愉快。他们的设计大体上是有意义的，每个阶段都包括一个“需要改进的地方”部分。

总而言之，如果你担心Zoom的E2EE功能的安全性，他们唯一能做得更好的事情就是发布这一功能的源代码(并从白皮书存储库链接到它，以便于发现)，这样独立的专家就可以公开审查它。

然而，他们似乎从他们的工资单上的专家那里获得了很多里程数，所以我不会指望会发生这种情况。