这是一篇关于在 Fediverse 中为直接消息构建端到端加密背后的一些推理的系列文章的第一篇。主要内容如下：

• 背景：

  • 密钥透明度：目标是确保网络中的每个人对谁拥有哪些公钥有相同的视图，通过 Merkle 树、数字签名和影响状态机的不同动作的高级协议来实现，使用集中式发布者模型和去中心化验证，可构建公共密钥目录网络以获取用户的公钥列表等。
  • 被遗忘权：不是法律建议，《GDPR》第 17 条为个人数据建立了“被遗忘权”，但关于此数据在只读分类账中持续存在是否有公共利益以及是否可以 override 被遗忘权仍未确定，作为在欧盟设计的人需考虑此潜在缺陷并在设计中减轻。
• 矛盾与挑战：密钥透明度和 GDPR 的“被遗忘权”的隐私目标看似矛盾，一方创建不可变的历史，另一方允许选择性删除历史，但有一种未经测试的法律理论认为“加密销毁”在法律上等同于删除，欧洲议会研究服务的报告也提到“加密销毁”可能是解决办法，但缺乏明确的法律框架，不能确定其合法性，因此不能仅因在分布式账本中实现“加密销毁”就声称符合 GDPR。

• 解决方案：

  • 协议风险引入：引入“加密销毁”后，公共密钥目录的工作变得更复杂，需提交密文而非明文，以避免破坏后续记录的包含证明，在选择如何提供解密服务时，应选择解密后保留密钥以便后期删除的方式，同时要确保用户能知道提交到透明分类账的密文能解密为公共密钥目录提供的特定明文值，且不会被欺骗。
  • 零知识证明：看似适合的 Schnorr 识别协议因公共密钥被视为个人数据而难以实现，很多零知识证明设计在实践中也不满足算法可获取性和避免使用通用大整数库的规则。
  • 可验证随机函数（VRFs）：与零知识证明类似，也存在公共密钥被视为个人数据的问题，且使用 VRF 会引入密钥管理问题，不能解决此问题。
  • Soatok 的提议解决方案：加密协议消息的每个属性，使用 HKDF-HMAC-SHA512 进行子密钥派生，AES-256-CTR 加密实际明文，HMAC-SHA512 进行消息认证，包括明文承诺哈希作为附加数据（AAD），以防止服务器不诚实，明文承诺的安全性通过 Argon2id 密码哈希函数实现，要注意盐的选择和处理，以避免预计算攻击等，最后给出了明文承诺算法的具体步骤和注意事项，同时指出此设计存在攻击者已知正确明文可确认记录的局限性，但总体上满足了使加密销毁成为可能同时保持公共密钥目录诚实的要求，且无需使用复杂的加密技术。

总之，此设计旨在在不使符合 GDPR 变得几乎不可能的情况下实现密钥透明度和加密销毁。