如果你使用了上篇文章技术，在客户端中成功实现了端到端加密。那么恭喜你！这是真正值得骄傲的一步，也是值得庆祝的一步！但是，您可能已经注意到，有些事情仍处于粗糙边缘：您必须通过比较公钥来手动验证所有其他设备，解密密钥不会在您的设备之间共享等。如果您想在自己的客户端中实现更进一步这些功能，那么本指南适合您
这是实现以下所有内容所需的一般路线图：
- 表情符号验证（SAS 或短验证字符串）
- 根据交叉签名状态显示验证状态
- SSSS（安全秘密存储和共享）
- 其他密钥的签名
- 房间内验证（通过房间内的消息进行验证）
- 杂项交叉签名的东西
- 引导 SSSS 和交叉签名
- 在线密钥备份
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 消息的功能默认为加密发送它们。房间消息是否加密通常取决于发送它们的房间是否加密。