全面采用 Signal Protocol 端到端加密和 AES-256
Tosh Defence 的 Sanket (Sanket.Chat) 使用 Signal 官方、经独立审计的 libsignal，通过采用 PQXDH 密钥协商和带有 SPQR 的 Double Ratchet 的 Signal Protocol，对每条消息、每次表情回应和每条加密群发消息进行端到端加密。文件、通话帧、通话传输、本地存储，以及部署实例所终止的每个 TLS 会话，均使用 AES-256；不回退至 AES-128，也不启用兼容模式。
必须使用 AES-256，否则拒绝执行：这是 SANKET 的工程策略，并通过代码强制实施。如果无法完全按设计进行加密，系统会拒绝该操作，而不是降低加密强度。
消息：未经修改的 Signal Protocol
SANKET 使用 Signal 官方的 libsignal 库加密所有消息，iOS、Android、桌面端和服务器均采用同一发布版本。其中不包含对 Signal Protocol 的重新实现，也不使用其他消息加密算法。
会话通过 PQXDH 建立。PQXDH 是 X3DH 的后量子扩展，将 X25519 密钥协商与 Kyber 密钥封装相结合。随后，消息通过 Double Ratchet 加密：每条消息的密钥被扩展为一个 AES-256 密钥、一个 HMAC-SHA256 密钥和一个初始化向量；消息使用 AES-256 加密，并使用 HMAC-SHA256 进行认证；密钥在使用后删除。Signal 的稀疏后量子棘轮机制也在每个会话中并行运行。
设计上不提供降级回退机制
如果无法使用 libsignal 加密，客户端将拒绝发送。未发布 libsignal 身份密钥的设备会被跳过，不会向其发送明文；旧版明文标记会被拒绝；服务器也会拒绝不符合 libsignal 格式的密钥包。消息内容不存在明文或其他密码算法的传输路径。
不使用共享密钥的群组
群组消息采用逐对分发加密：发送设备通过各自独立的libsignal会话，分别为每位成员的每台可信设备加密消息。成员变更无需重新生成密钥，被移除的成员只是不再列入分发名单。
加密前，发送方会核查每个接收方账户由该账户自身密钥签名的设备列表，不会向列表之外的设备发送任何内容。
文件与通话
附件的内容、名称和类型均在设备端使用 AES-256-GCM 加密，每个文件使用一个随机的 256 位密钥，该密钥随 libsignal 消息传输。
语音和视频受到双重保护。每位参与者的媒体帧均使用 AES-256-GCM 和按发送方分配的密钥进行端到端加密；该密钥每 200 毫秒轮换一次，因此每位发送方每秒获得 5 个新的媒体帧密钥，且每当有人加入或离开时都会生成新的随机密钥。每台设备与媒体服务器之间的 SRTP 仅接受 AEAD_AES_256_GCM。媒体服务器转发其无法解密的加密媒体帧，且该设计不支持服务器端通话录制。
- 每个文件均使用 AES-256-GCM
- 每位发送方使用各自的通话密钥，绝不共用群组密钥
- 每位发送者每秒使用 5 个帧密钥
- 仅使用 SRTP AES-256-GCM
传输与存储
每条客户端连接均使用 TLS 1.3 和 TLS_AES_256_GCM_SHA384；对于平台网络协议栈有此要求的情况，则使用 TLS 1.2、ECDHE 和 AES-256-GCM。AES-128、ChaCha20、CBC 模式密码套件及静态 RSA 均被排除，混合后量子群 X25519MLKEM768 作为首选提供。每台获批设备还可通过双向 TLS，使用自己的客户端证书证明其身份。
在设备上，本地数据库使用 AES-256 加密并通过 HMAC-SHA256 进行认证；在手机上，协议存储和设备密钥由 Secure Enclave、StrongBox 或可信执行环境中受硬件保护的密钥加密。
技术验证材料
在 SANKET 白皮书中了解详情
本页面的每项陈述均在公开的 Sanket 技术安全与架构白皮书中完整阐述，无需注册即可免费阅读。
SANKET 是否使用 Signal Protocol？
是。SANKET 在所有平台上均使用 Signal 官方 libsignal 库加密全部消息，采用 PQXDH 密钥协商以及结合 SPQR 的 Double Ratchet。它不包含任何对该协议的重新实现。
SANKET 的消息是否采用 AES-256 加密？
是。消息在 libsignal 内使用 AES-256-CBC 和 HMAC-SHA256；文件、通话帧、通话传输、本地存储和 TLS 使用 AES-256-GCM。不提供 AES-128 降级方案。
语音和视频通话是否经过端到端加密？
是。通话帧使用通过 libsignal 传送的各发送方专属密钥，以 AES-256-GCM 进行端到端加密，每个发送方每秒生成 5 个新的帧密钥；外层的 SRTP 仅接受 AES-256-GCM。
表情回应和广播消息是否经过加密？
是。表情回应和加密广播均以 libsignal 消息形式传输，与其他消息一样采用端到端加密。广播的优先级、截止时间和失效时间也包含在加密内容中。
SANKET 是否对群组使用发送者密钥？
没有。SANKET 通过每台成员可信设备各自的 libsignal 会话，分别加密发往这些设备的群组消息，因此不存在共享的群组密钥。
Sanket 接受哪些 TLS 版本？
优先使用 TLS 1.3，且仅采用 TLS_AES_256_GCM_SHA384。仅在使用 ECDHE 和 AES-256-GCM 时接受 TLS 1.2。不接受低于 TLS 1.2 的版本，并优先提供混合式后量子密钥交换 X25519MLKEM768。
libsignal 是否经过审计？
是的。Sanket 基于 Signal 独立审计的 libsignal 库构建，PQXDH 协议也经过形式化分析。
与我们的工程师共同审查 Sanket 的密码技术
Tosh Defence 向安全架构师和评估委员会逐层讲解密码学设计，并可在签署保密协议后提供受控版本的白皮书。