高级的E2EE——交叉签名（区块链密码签名）（第一篇-SAS）

  如果你使用了上篇文章技术，在客户端中成功实现了端到端加密。那么恭喜你！这是真正值得骄傲的一步，也是值得庆祝的一步！但是，您可能已经注意到，有些事情仍处于粗糙边缘：您必须通过比较公钥来手动验证所有其他设备，解密密钥不会在您的设备之间共享等。如果您想在自己的客户端中实现更进一步这些功能，那么本指南适合您

 这是实现以下所有内容所需的一般路线图：

1. 表情符号验证（SAS 或短验证字符串）
2. 根据交叉签名状态显示验证状态
3. SSSS（安全秘密存储和共享）
4. 其他密钥的签名
5. 房间内验证（通过房间内的消息进行验证）
6. 杂项交叉签名的东西
7. 引导 SSSS 和交叉签名
8. 在线密钥备份

  1.实施表情符号验证（SAS）

  表情符号验证是称为 SAS 的验证模型的一部分，用于短验证字符串。除了表情符号验证，还有数字验证。预计所有支持 SAS 的客户端都至少支持数字验证。这是为了确保仍然可以验证可能无法显示表情符号的客户端（可能是某些 CLI 应用程序或嵌入式设备显示）

验证过程概览

验证通过两个设备相互发送消息，通过 to_device 消息或通过房间中的消息进行。想要验证另一个设备 (Bob) 的设备 (Alice) 会发送一条m.key.verification.request 消息及其支持的方法。Bob 用 回答m.key.verification.ready，同时通知 Alice 它支持哪些方法。在客户端 UI 中，Bob 在收到m.key.verification.request 消息后会弹出一个新的验证请求。在双方都接受开始后，任何一方（Alice 和/或 Bob）都可以发送一个m.key.verification.start特定于所使用的验证方法的 。如果 Alice 和 Bob 都发送 a m.key.verification.start且验证方式不匹配，则取消验证请求。如果验证匹配，则m.key.verification.start使用按字典顺序较小的用户 ID。如果它们也匹配（例如，如果您正在验证自己的设备），则使用字典顺序较小的设备 ID。这确保了m.key.verification.start 使用哪个是明确的。从现在开始，使用的设备m.key.verification.start就是发起请求的设备（这很重要，因为 SAS 中的某些事情取决于谁发起了请求）。之后，会发生一些验证过程，即特定的验证方法。如果一切都成功，则双方m.key.verification.done互相发送一个。

为了使所有这些工作，每个验证请求都有一个唯一的交易 ID，这是一个不透明的字符串，用于标识特定的验证请求。在房间验证的情况下，这是第一个发送消息的事件 ID ( m.key.verification.request)。任何一方都可以随时取消验证请求，方法是发送一个m.key.verification.cancel以及有关取消原因的一些信息。

send由于发送的所有消息都会添加一些通用元数据，因此编写一个包装函数来发送密钥验证数据可能是一个好主意。此函数还可以将发送事件处理为 to_device 消息或房间事件。to_device 和房间验证的消息内容略有不同：

对于 to_device 消息，transaction_id和from_device被简单地添加到发送的对象中。 transaction_id表示交易的唯一 ID，而from_device只是一个包含您自己的设备 ID 的字符串。有效载荷，例如

{
  "foo": "bar"
}

因此看起来像：

{
  "foo": "bar",
  "transaction_id": "some-awesome-id",
  "from_device": "DXKKF"
}

对于房间消息，事务ID，即第一个事件的事件ID，被添加到 m.relates_to事件的部分。设备 ID 与 to_device 消息相同；它应该设置为发送设备的 ID。所以上面的payload就变成了：

{
  "foo": "bar",
  "from_device": "DXKKF",
  "m.relates_to": {
    "rel_type": "m.reference",
    "event_id": "$firstEventId"
  }
}

为简单起见，下面提到的所有有效负载都将在没有这些额外键的情况下显示。

发送的 to_devices 不必加密，因为验证请求的整个想法是它们可以公开。然而，客户端无论如何都可以选择这样做，例如，如果它们发送 to_device 消息的功能默认为加密发送它们。房间消息是否加密通常取决于发送它们的房间是否加密。