端到端加密（E2EE）的前提是客户端安全可信，你的终端设备安全可信，但网络和服务器不需要可信。您已经阅读了客户端中的所有代码，或者您信任的人已经为您完成了这些代码。但是在将代码加载到您的手机（安装 Keybase 应用程序）并开始与您的朋友聊天之后，您仍然需要验证服务器是否向您发送了正确的加密密钥。由于您无法托管自己的服务器，因此必须由 Keybase, Inc 的服务器向您发送您朋友的加密密钥。
（客户端）代码是开放的，服务器向您发送加密密钥，您可以在带外检查加密密钥，这是 E2EE 软件的标准。在 Signal 中检查安全号码，在 Wire 中检查设备指纹，在 Telegram 中检查加密密钥。如果它们匹配，您就知道（基于开放的客户端代码和它使用的密码术）中间没有（wo）人。
这如何与 Keybase 一起使用？他们的文档解释了其中的一部分：
Alice 和 Bob 共享一个对称加密密钥，他们通过服务器将其加密为每个设备的公共加密密钥。
好的，所以我们要么验证对称密钥（在两部手机上相同），要么验证公钥（我应该能够在我的手机上显示我的，我的朋友会打电话给他们的手机认为我的公钥是什么，并且应该匹配）。
奇怪的是，没有按钮可以执行这两项操作。该文档没有提及任何内容，我环顾四周时找不到它。
此外，它解释了将公钥放入您的签名链中：
所有 Keybase 设备在首次配置时都会发布一个
crypto_box公钥和一个crypto_sign公钥。这些密钥存在于用户的签名链中 [...] 聊天对称加密密钥是 32 个随机字节。它由聊天中的每个人共享，[...] 当一个新设备需要这个共享密钥时，另一个拥有它的设备将使用新设备的公钥对其进行加密crypto_box，然后将其上传到 Keybase 服务器。
所以如果我没看错的话，当我的朋友和我开始新的聊天时，他们的客户端会生成共享密钥，它会从crypto_box我的签名链中获取公钥，并使用该公钥加密共享密钥，然后上传将结果发送到 Keybase 的服务器，以便我可以下载和解密它，从而建立共享密钥并开始聊天。
...但是那个签名链是从哪里来的？这必须从 Keybase 服务器获取，所以由于无法显示它，我必须相信服务器会向我发送正确的密钥。当他们声称“所有消息都是安全的、端到端加密的”时，这有什么意义？客户端偶尔也会在聊天上方短暂地显示一条横幅，上面写着“端到端加密”。
有关于如何逐步进行验证的文档，但除了说明被破坏（没有sigs字段root_desc，结果root.json?hash=X）之外，这不是我可以在手机上做的事情。恶意服务器可以向我的命令行客户端返回正确的答案，同时告诉移动应用签名链包含一个完全不同的密钥（即恶意行为者用来执行中间人的密钥）。
当与其他人谈论它时，他们提到这个区块链的东西是它安全的原因，不需要自己验证任何东西，但我不知道它是如何工作的。
Keybase 聊天是否需要手动验证任何类型的密钥以进行端到端加密，或者区块链数据（应用程序可以在后台静默验证）以某种方式阻止我们必须比较指纹/密钥/sigchains？- 如果我们确实需要比较指纹/密钥/sigchains，如何在 Keybase 应用程序中完成？
更新：一位朋友链接了这个 GitHub 问题，基本上说整个区块链的事情还没有由应用程序完成。中间是否（类似）SPV是一个好的解决方案，目前尚未实施。如果我没记错的话，那就是第一个选项。
由于该应用程序似乎也不允许实现第二个选项（比较密钥），我猜这得出的结论是 Keybase 目前没有实现 E2EE？攻击很难成功：即使是恶意服务器（非常理想的位置）也必须从一开始就进行中间人攻击，因此他们必须事先了解目标对象。但我们确实相信服务器至少在某些时候是诚实的。还是我仍然缺少某种方式来实现真正的端到端加密？
更新 2：黑客新闻中提到该应用程序应自行检查第三方证明。这并不完全是端到端加密的含义，因为它仍然依赖于第三方，但是，在能够 MitM 某人的密钥（也是 TOFU 的）之前必须拥有 2 家或更多公司的服务器应该会给人一些信心.
然而，当在 Wireshark 中检查它是否真的这样做时（向 Twitter API 询问证明字符串并使用它从 Keybase 收到的公钥验证签名），我手机上的 Keybase 根本没有联系 Twitter。（然而，它确实自豪地宣称新的聊天是端到端加密的。）
对于那些想知道 Wireshark 测试是否可以控制各种事情的人：
- 在数据包捕获之前，从未将用于开始聊天的用户名输入到测试系统（开始聊天的系统）中。
- 这两个帐户以前从未在任何设备上进行过任何形式的联系。他们也不会互相关注。在聊天建立之前，对方连我的用户名都不知道，所以他们也无法触发任何事情。
- 数据包捕获在用户名被输入到测试设备的搜索字段之前开始，并且仅在 Keybase 完全建立聊天并声称它是端到端加密后才结束。
- Twitter 似乎将其所有服务托管在其自己的 IP 范围内，并且测试系统在建立聊天期间与之交谈的 IP 均不在该范围内。如果这个假设是错误的并且 Keybase 客户端使用了 之外的端点
104.244.40.0/21，请发表评论。我检查了所有 IP，所有 IP 都不可能成为 Twitter 的前线（有关黑客新闻的详细信息），但我很想知道 Twitter 是否会在 Amazon Web Services 的简单存储服务或其他内容上发布推文。 - 移动 Keybase 客户端简单地从存在于 Keybase 上的所有用户下载所有签名链并在开始数据包捕获之前检查他们的所有证明，这被认为是不可信的。这是我能想到的在数据包捕获之前如何验证第三方托管证明的唯一方法。
