WIZARD

深色模式

按规范文档组织：先建立读协议的方法，再逐条拆解 TLS、Signal、SSH、WireGuard、Noise 与链上密钥体系。

协议分析框架

密码协议不是单个算法，而是原语在状态机里的组合。读任何规范时，先回答四个问题：

  • 身份：谁向谁证明什么？（证书、预共享密钥、公钥指纹）
  • 密钥协商：KEX 输出什么秘密？是否前向保密（PFS）？
  • 密钥派生：KDF 如何把共享秘密拉伸为 session key / IV / MAC key？
  • 数据保护：AEAD 保护哪些字段？关联数据（AAD）绑定了什么上下文？

常见组合模式

层次典型原语失败后果
握手认证RSA/ECDSA/Ed25519 签名、证书链MITM、假冒服务器
密钥交换ECDHE、X25519、DH会话密钥泄露、无 PFS
密钥派生HKDF、TLS 1.3 key schedule密钥复用、上下文混淆
记录层AES-GCM、ChaCha20-Poly1305明文泄露、篡改
<h3>入门读物</h3>
<ul>
  <li><a href="https://cryptobook.dev/" target="_blank" rel="noopener">Boneh-Shoup Ch.18–21</a>（协议组合与证明直觉）</li>
  <li><a href="https://www.manning.com/books/real-world-cryptography" target="_blank" rel="noopener">Real-World Cryptography</a> 协议章节</li>
</ul>
<p class="kb-note-inline">练习：选一条 TLS 1.3 握手，标出每一步对应的四个问题答案。</p>

TLS 1.3

规范：RFC 8446 · RFC 8447（IANA 注册） · RFC 8701（ECH 扩展）

设计要点

  • 握手默认 1-RTT；支持 0-RTT 早期数据（有重放风险，需应用层处理）
  • 移除 RSA 密钥传输、静态 DH、CBC 模式、压缩、重协商
  • 全程使用前向保密的 (EC)DHE；证书签名与密钥交换分离
  • 密钥调度基于 HKDF-Expand-Label，上下文标签防跨协议复用

握手消息流（Full Handshake）

方向消息关键内容
Client → ServerClientHello支持的 cipher suites、key_share（ECDHE 公钥）、SNI
Server → ClientServerHello选定参数、key_share、协商版本
Server → ClientEncryptedExtensionsALPN、max_fragment_length 等扩展
Server → ClientCertificate服务器证书链
Server → ClientCertificateVerify对握手 transcript 的签名
Server → ClientFinished握手 MAC，确认密钥一致
Client → ServerFinished客户端确认
双向Application DataAEAD 加密的 HTTP 等载荷
<h3>Cipher Suite 结构</h3>
<ul>
  <li>TLS 1.3 仅保留 AEAD：TLS_AES_128_GCM_SHA256、TLS_AES_256_GCM_SHA384、TLS_CHACHA20_POLY1305_SHA256</li>
  <li>哈希算法主要用于 HKDF 与 CertificateVerify，不再用于 MAC-then-Encrypt</li>
</ul>
<h3>与 TLS 1.2 的关键差异</h3>
<ul>
  <li>1.2 允许 RSA 密钥传输（无 PFS）；1.3 强制 ephemeral DH</li>
  <li>1.2 握手更复杂、更多降级攻击面；1.3 状态机更简洁</li>
  <li>1.3 加密更多握手字段（EncryptedExtensions 之后）</li>
</ul>
<p class="kb-note-inline">练习：Wireshark 抓包，对照 RFC 8446 §2 标注每条消息。</p>

Signal Protocol

规范：Signal 技术文档 · X3DH · Double Ratchet · Sealed Sender

协议栈分层

  • X3DH：异步环境下首次建立共享密钥（身份密钥 + 一次性预密钥 + 签名预密钥）
  • Double Ratchet：每条消息后更新链密钥，实现前向保密与后向保密
  • Sealed Sender：隐藏发送者身份，由接收方服务器代投递

X3DH 密钥协商

  • Alice 从服务器获取 Bob 的预密钥包（IK、SPK、OPK）
  • 四次 DH：IK_A×SPK_B、EK_A×IK_B、EK_A×SPK_B、EK_A×OPK_B（有 OPK 时）
  • 拼接 DH 输出后经 KDF 得初始 root key 与 chain key

Double Ratchet 机制

  • DH Ratchet：每轮新 ephemeral key，更新 root key
  • Symmetric Ratchet：KDF chain 逐步派生 message key，用后丢弃
  • 乱序消息通过 message number + skipped keys 缓存处理

原语选型

  • 曲线：Curve25519；AEAD：AES-256-CBC + HMAC-SHA256 或 AES-GCM（版本演进）
  • 与 TLS 的差异：无 CA 体系，信任模型基于「安全号码」指纹比对

练习：画出 Alice 发第一条消息时的 X3DH 四次 DH 示意图。

SSH

规范：RFC 4253（传输层） · RFC 4252（认证） · RFC 5656（ECC） · OpenSSH 实现文档

传输层握手

  • 版本协商 → 算法协商（KEX、host key、cipher、MAC、compression）
  • KEX 输出共享秘密 H，经哈希得 session key、IV、MAC key
  • 服务器用 host key 对 exchange hash 签名，客户端验证主机公钥指纹

认证方式

方式机制注意
公钥客户端用私钥签名 session identifier推荐 Ed25519；禁用 DSA
密码加密通道内传输密码防暴力需 fail2ban 等
键盘交互多因素扩展较少见
<h3>主机密钥信任</h3>
<ul>
  <li><code>known_hosts</code> 存储服务器公钥指纹；首次连接需人工确认</li>
  <li>CA 签名主机证书（OpenSSH 证书）可用于大规模部署</li>
</ul>
<p class="kb-note-inline">练习：对比 SSH KEX 与 TLS 1.3 握手的异同（认证时机、PFS、证书模型）。</p>

WireGuard

规范：WireGuard 协议白皮书 · 原始论文 PDF

设计哲学

  • 约 4000 行内核代码；拒绝算法协商，固定 Curve25519 + ChaCha20-Poly1305 + BLAKE2s
  • 无证书：对等体通过静态公钥列表（allowed-ips + 公钥）互相认证
  • 静默丢弃无效包，不回复 oracle 反馈

握手（1-RTT）

  • Initiator 发 Handshake Initiation：ephemeral + 加密的静态公钥 + TAI64N 时间戳
  • Responder 回 Handshake Response：ephemeral + 空负载 + MAC
  • 双方派生 transport key，后续用 ChaCha20-Poly1305 加密数据包

密钥轮换

  • REKEY_AFTER_MESSAGES / REKEY_AFTER_TIME 自动更新 session key
  • 时间戳防重放（TAI64N + 窗口）

练习：阅读 WireGuard 白皮书 §5，列出与 IPsec/IKEv2 的复杂度对比。

Noise Protocol Framework

规范：Noise Protocol Specification · Noise Explorer（模式可视化）

核心抽象

  • 握手模式字符串：如 XX、IK、NK 描述消息方向与密钥交换顺序
  • 每个 e = ephemeral DH，s = 静态公钥，ee/se 等 = DH 组合
  • SymmetricState + CipherState 管理握手哈希与加密状态

常见模式

模式适用场景特点
NN完全匿名双方无静态密钥，无身份认证
XX互未知公钥双向认证，3 条消息
IK发起方已知响应方公钥2 条消息，适合客户端连已知服务器
NK响应方已知发起方公钥2 条消息
<h3>应用</h3>
<ul>
  <li>WireGuard 握手可视为 Noise 变体；WhatsApp、Lightning Network 等亦有 Noise 衍生设计</li>
  <li>设计自定义协议时，优先在 Noise Explorer 验证模式而非从零写状态机</li>
</ul>
<p class="kb-note-inline">练习：在 Noise Explorer 对比 <code>XX</code> 与 <code>IK</code> 的消息流。</p>

区块链密钥体系

规范：BIP-32 · BIP-39 · BIP-44 · EIP-155

BIP-32 分层确定性钱包

  • 从 master seed 派生子密钥树；路径 m/44'/coin'/account'/change/index
  • 扩展公钥（xpub）可派生只读子公钥，不泄露私钥

BIP-39 助记词

  • 128–256 bit 熵 + 校验位 → 12/24 个单词；PBKDF2 拉伸为 seed
  • 助记词即根秘密，备份与存储安全至关重要

交易签名

  • 比特币：secp256k1 + ECDSA（BIP-340 Schnorr 为新方向）
  • 以太坊：secp256k1 + ECDSA；EIP-155 在签名中编码 chain id 防跨链重放
  • 交易哈希结构：RLP / ABI 编码后 Keccak-256（以太坊）或双 SHA-256（比特币）

练习：用 BIP-39 词表验证一组助记词的校验位是否正确。

工程部署

配置硬化清单

  • 禁用 TLS 1.0/1.1、3DES、RC4；优先 TLS 1.3 + AEAD
  • 启用 HSTS、Certificate Transparency
  • 证书自动续期：Let's Encrypt / ACME

实现选型

场景推荐说明
Rust TLSrustls默认 aws-lc-rs；支持 PQC 混合握手
Python HTTPhttpx / aiohttp + 系统 ssl注意证书校验与 cipher 配置
VPNWireGuard内核态、配置简单
配置模板Mozilla SSL Config Generatornginx / Caddy 可复制配置
<p class="kb-note-inline">练习：用 testssl.sh 扫描站点并逐项修复。本站笔记 <span class="crypto-pending">待撰写</span>。</p>

WIZARD

© 2025