密钥库在应用程序中的聊天从未经过可验证的端到端加密

端到端加密(E2EE)的前提是客户端安全可信，您的终端设备安全可信，但网络和服务器不需要可信。您已经阅读了客户端中的所有代码，或者您信任的某个人已经为您这样做了。但是，在将代码加载到您的手机上--安装密钥库应用程序--并开始与您的朋友聊天之后，您仍然需要验证服务器是否向您发送了正确的加密密钥。因为您不能托管您自己的服务器，所以必须是Keybase，Inc.的服务器向您发送您朋友的加密密钥。

对于E2EE软件来说，(客户端)代码是开放的，服务器向您发送加密密钥，您可以在带外检查加密密钥，这是E2EE软件的标准。在Signal中检查安全号码，在Wire中检查设备指纹，在Telegram中检查加密密钥。如果它们匹配，您就知道(基于开放客户端代码和它使用的密码)中间没有(Wo)man。

爱丽丝和鲍勃共享一个对称加密密钥，他们通过将其加密到每个设备的公共加密密钥来传递给服务器。

好的，我们要么验证对称密钥(在两部手机上相同)，要么验证公钥(我应该能够在我的手机上显示我的公钥，我的朋友会查询他们的手机认为我的公钥是什么，这应该是匹配的)。

奇怪的是，没有按钮来做这两件事中的任何一件。文档里没有提到任何东西，我四处看看也找不到。“。

所有密钥库设备在第一次提供时都会发布一个crypto_box公钥和一个crypto_sign公钥。这些密钥位于用户的签名链中[.]。聊天对称加密密钥是32个随机字节。它由聊天中的每个人共享，[.]。当新设备需要该共享密钥时，拥有该共享密钥的另一设备将使用新设备的公共CRYPTO_BOX密钥对其进行加密，然后将其上载到密钥库服务器。

因此，如果我读对了这一点，当我的朋友与我打开新的聊天时，他们的客户端将生成共享密钥，它将从我的签名链内的crypto_box中获取公钥，并使用该公钥加密共享密钥，然后将结果上传到密钥库的服务器，以便我可以下载和解密它，从而建立共享密钥并开始聊天。

..。但是这个签名链是从哪里来的呢？它必须从密钥库服务器获取，因此由于无法显示它，我必须信任服务器会给我发送正确的密钥。当他们宣称所有消息都是安全的、端到端加密的时，这又有什么意义呢？客户偶尔也会在聊天上方短暂地显示一个横幅，上面写着“端到端加密"；”。

有关于如何一步一步进行验证的文档，但是除了指令被破坏之外(root_desc中没有sigs字段，这是root.json？hash=X的结果)，这不是我可以在我的手机上做的事情。恶意服务器可以向我的命令行客户端返回正确答案，同时告诉移动应用程序签名链包含完全不同的密钥(即恶意行为者用来执行MITM的密钥)。

当与其他人谈论它时，他们会提到区块链这件事，因为它是安全的，而不需要自己验证任何东西，但我不知道它是如何工作的。

密钥库聊天是否需要手动验证任何类型的密钥才能进行端到端加密，或者区块链数据(应用程序可以在幕后静默验证)是否以某种方式阻止了我们不得不比较指纹/密钥/图章链？

如果我们确实需要比较指纹/密钥/图章链，那么如何在密钥库应用程序中做到这一点呢？

最新消息：一位朋友将GitHub的问题联系了起来，基本上是说整个区块链的事情还不是这个应用程序做的。至于SPV是不是一个好的解决方案，目前还没有实现。如果我没记错的话，这就排除了第一个选择。

由于这个应用程序似乎也不允许实现第二个选项(比较键)，我猜这得出的结论是目前在Keybase中没有实现E2EE？攻击很难成功：即使是恶意服务器(非常理想的位置)也必须从一开始就攻击MITM，因此他们必须事先知道目标是谁。但我们确实相信服务器是诚实的，至少在某些时候是这样。或者，我是否仍然缺少某种方法来实现真正的端到端加密？

更新2：黑客新闻提到，这款应用程序应该自己检查第三方的证据。这并不完全是端到端加密的意思，因为它仍然依赖于第三方，但尽管如此，必须拥有两家或更多公司的服务器，才能窃取某人的密钥(另外还有豆腐密钥)，这应该会给人相当大的信心。然而，当检查Wireshark是否真的这样做时(向Twitter API请求证明字符串，并使用它从密钥库收到的公钥验证签名)，我手机上的密钥库根本没有联系Twitter。(然而，它确实自豪地宣布，新的聊天是端到端加密的。)。

在数据包捕获之前，与其开始聊天的用户名从未键入测试系统(开始聊天的那个用户名)。

这两个账户之前从未在任何设备上进行过任何形式的联系。他们也不会互相效仿。在聊天建立之前，对方甚至不知道我的用户名，所以他们也不可能触发任何事情。

数据包捕获在用户名输入到测试设备的搜索字段之前开始，只有在密钥库完全建立聊天并声称它是端到端加密之后才结束。

Twitter似乎将其所有服务都托管在自己的IP范围内，测试系统在聊天过程中与之交谈的IP都不在该范围内。如果此假设为假，并且密钥库客户端使用104.244.40.0/21之外的端点，请发表评论。我检查了所有的IP地址，都不太可能是Twitter的幌子(黑客新闻的细节)，但我想知道Twitter是否会在亚马逊网络服务(Amazon Web Services)或其他网站上发布推文。

移动密钥库客户端简单地从密钥库上存在的所有用户下载了所有签名链，并且在开始数据包捕获之前检查了他们的所有证据，这被认为是不可信的。这是我唯一能想到如何在数据包捕获之前验证第三方托管的证据的方法。

令人惊讶的是，通过密钥库访问远程方的公钥如此困难。使用EncryptedSend(www.cryptedsend.com)，可以很容易地访问远程方的公钥。-11mti2935。

据我所知，答案是应用程序应该像你提到的那样自己检查第三方的证明，这就是允许你信任提供的密钥的原因。然而，可能会发生的情况是，它只验证一次或定期验证-如果它已经检查了您设备上的证明，则不会在每个新的聊天会话中再次检查。-CristianTM。

@CristianTM我确保以前从来没有查过和我一起在手机上测试过的用户名，在声称聊天是安全的之前，它肯定没有检查过。请注意，黑客新闻帖子中记录了这一点。-*LUC。

@CristianTM你看到帖子里的编辑了吗？我想这应该能澄清你的问题。如果没有，请告诉我。-*LUC

看起来真的很奇怪。我认为这是一个为开发者或查看源代码的案例。但是，如果他们依赖于服务器端的校样检查或类似的东西，那么安全的期望在这里似乎就被打破了。-CristianTM。

当您第一次与某人交谈时，它会从密钥库服务器下载他们的加密密钥，您必须信任服务器会向您发送正确的密钥。它还可以向您发送一个假密钥，这样您就可以使用恶意密钥来加密您的消息。没有办法在应用程序中验证这一点。

在密钥库的情况下，公平地说，攻击很难成功，因为他们提供的检查可用，但它不是端到端加密，除非你想扩大定义，以包括信任服务器的密钥交换(再加上一点一厢情愿的想法，甚至有少数人曾经检查Merkle根包含他们的密钥，尽管关于如何检查的说明被打破，如问题所述)。

如果要验证密钥库服务器没有执行任何类型的攻击，则必须使用命令行；这在官方应用程序中是不可能的。校样(推特校样、网站校样等)。似乎工作不可靠(如问题中所述)，但即使它们工作可靠，Keybase也会将聊天标记为E2EE，而不需要在您的帐户中提供任何第三方证据。如果不给我一个理由，我想我妈妈不会加证据的(也许即使到那时也不会，这是可以的，但是她不应该被误导去相信它比它实际上更安全)。所应用的密钥库机制通常称为豆腐：首次使用时信任。它只下载一次密钥，如果没有更改，它会认为一切正常。

我同意。好在他们花了10万多美元给NCC集团的安全和密码学专家，让他们进行一次审计.。在他们的报告中从来没有提到过这个问题吗？(我还给其中一名审计师发了电子邮件，上面有这个问题的链接，但从来没有收到过确认收到的邮件。)。审计师确实发现了其他问题：

[NCC发现的这两个]漏洞只有在我们的服务器恶意操作的情况下才能被利用。我们可以向你保证，他们不是，但你没有理由相信我们。这才是关键所在！

只是我们必须相信他们，因为我们不能自己检查。

不过，也许我没有给予Keybase足够的信任。我引用的博客正确地指责其他应用程序只接受和使用新的(可能是恶意的)密钥，而不需要用户输入。WhatsApp就是一个很好的例子：你最多只能打开警告，但WhatsApp客户端仍会很高兴地参与切换，在你发送消息时，攻击者会马上向你发送新的加密密钥，让他们知道至少一个明文，即使你非常小心，只在你看到密钥没有改变的时候才发送消息。但默认情况下，不会显示新的密钥通知，因此默认情况下它是机会性加密的。我认识的许多技术人员似乎都信任它，因为它使用信号协议，所以它一定很好。我希望密钥库应用程序能正确地做到这一点。虽然再次检查一下机制中是否没有任何缺陷可能是件好事，但我预计如果有缺陷，审计就会发现这一点，所以Keybase可能会做得很好。

但是这个具体的问题现在已经没有意义了，因为Keybase已经被Zoom关闭了。我在等待Keybase要么解决这个问题并发布一个令人满意的答案，要么等待一个独立的人重新做我的分析并用他们的结论回答，或者等待Keybase承认他们欺骗了整个安全社区。一个叫贾里德的好心的陌生人就这个问题开了赏金，我把它贴到了黑客新闻上以吸引答案，希望也有一个人尝试过关键的验证。但现在这一切都不会发生，所以让我们从更广泛的角度来看这个问题背后的原因。

用户应该要求有可遵循的说明。我们应该询问Keybase，现在是Zoom，以及任何提出强烈安全声明的人。他们认领了吗？您应该希望看到可以遵循的步骤来验证它。因为您信任已发布的代码，所以这些指令不应该涉及任何命令行编码工作，并且绝对不会有诸如验证笔记本电脑上的密钥和希望服务器将相同的密钥发送到您的手机这样的空白。

举一个很好的例子，我讨厌这么说，Telegram的呼叫功能很好地解决了这一点。他们在屏幕上显示了四个表情符号，用于密钥验证。见鬼，这很有趣：在与我女朋友的通话中，我有时发现我们在随机进行验证，比较表情符号库的差异，或者取笑其中一个图标。我还没有研究过它的安全性，也许你需要五个表情符号才能达到128位以上的熵，但从用户体验的角度来看，这是一个很好的例子。Matrix对调用做了类似的事情，但(目前还没有)。

黑客新闻(Hacker News)、Reddit、PrivacyTools(Keybase[提供]E2EE)上的技术社区，甚至连审计人员都忽视了这个纯粹的实际问题(总的来说，我相信他们的专业知识，在像Keybase或Zoom这样复杂的项目中，没有一项审计是真正完整的)。当我问问题时，人们都很敌视我，以为我是一个新手，不会读文档，不会弄清楚验证是如何进行的，而他们自己从来没有真正尝试过。保持更多的好奇心。当调用端到端加密时，密钥验证不应该很困难，因为最终用户必须能够验证它。虽然我妈妈可能需要信任某个人来检查代码，但我(或者像F-Droid这样的项目)可以独立编译二进制文件并将其交给她。但是，如果她希望这样做，她需要能够检查加密密钥。我们知道，即使是美国国家安全局也很难破解好的密码学，并称赞密钥库建立了好的密码学，但攻击者通过交换服务器响应来解决这个问题没有问题。

点击“发布您的答案”，即表示您同意我们的服务条款、隐私政策和Cookie政策。

不是你想要的答案吗？浏览标记的其他问题或提出您自己的问题。