密钥交换
密钥交换协议是现代密码学的重要基石，它解决了通信双方如何在不安全信道上安全地协商出一个共享密钥这一根本性问题。无论是你的 HTTPS 浏览器会话、SSH 远程登录、还是 Signal 端到端加密消息，背后都离不开密钥交换协议的支撑。
密钥交换的核心挑战在于：通信双方从未见过面，彼此之间可能有一个能够窃听甚至篡改消息的攻击者（通常称为 Mallory 或 中间人），但他们仍然需要达成一个共同的秘密。这个秘密随后可用于派生对称密钥，对后续通信进行加密和认证。
本文系统性地介绍从经典的 Diffie-Hellman 到后量子密钥封装机制（KEM）的主流密钥交换协议，并通过具体数值示例、协议流程图表和性能对比数据，帮助读者深入理解其数学原理与工程实践。
密钥交换的基本概念
问题定义
Alice 和 Bob 希望通过一条被 Eve（窃听者）监视的信道，协商出一个共享密钥 KKK。他们可以自由地交换消息，但 Eve 可以看到所有的消息内容。问题是：Alice 和 Bob 能否通过公开对话，在不被 Eve 知晓的情况下确定一个共同的秘密？
在 1976 年之前，密码学界的共识是不可能——因为所有已知的密码系统都需要通信双方事先共享一个密钥。Diffie 和 Hellman 在 1976 年发表的里程碑论文 New Directions in Cryptography 首次证明了这是可能的。
关键安全属性
安全属性描述重要性被动安全窃听者无法从公开消息中计算出共享密钥基本要求前向保密即使长期私钥泄露，历史会话密钥仍然安全高安全性通信必需中间人攻击抵抗主动攻击者无法冒充任意一方需要身份认证配合已知密钥安全一次会话密钥泄露不影响其他会话实用安全密钥确认双方确认对方确实持有相同的密钥可选但推荐
Diffie-Hellman 密钥交换
数学原理
Diffie-Hellman 协议（简称 DH）基于离散对数问题（Discrete Logarithm Problem, DLP）的计算困难性。其核心思想是利用模幂运算的单向性：
正向计算容易：给定 ggg、aaa 和 ppp，计算 ga mod pg^a \bmod pgamodp 很容易
逆向计算困难：给定 ggg、ga mod pg^a \bmod pgamodp 和 ppp，恢复 aaa 极其困难（当 ppp 足够大时）
协议流程
Alice Bob
| |
| 选择私钥 a（随机数） | 选择私钥 b（随机数）
| 计算公钥 A = g^a mod p | 计算公钥 B = g^b mod p
| |
|----------- A ----------------> |
| |
|<----------- B ---------------- |
| |
| 计算 K = B^a mod p | 计算 K = A^b mod p
| = (g^b)^a = g^{ab} | = (g^a)^b = g^{ab}
| |
| 双方得到相同的共享密钥 K |
协议参数：
ppp：一个大素数（通常 2048 位或更长）
ggg：模 ppp 的原根（生成元），一个 1 < g < p 的整数
aaa、bbb：Alice 和 Bob 各自随机选择的私钥（秘密随机数）
AAA、BBB：公开交换的公钥
完整数值示例
为了使计算过程直观可见，我们用一个小规模的例子来演示（注意：实际应用中使用的 ppp 远远更大）。
设置公开参数：
选择一个小素数 p=23p = 23p=23 和原根 g=5g = 5g=5。
协议执行过程：
步骤AliceBob公开可见的信息1选择私钥 a=6a = 6a=6选择私钥 b=15b = 15b=15—2计算 A=56 mod 23A = 5^6 \bmod 23A=56mod23计算 B=515 mod 23B = 5^{15} \bmod 23B=515mod23—3A=15625 mod 23=8A = 15625 \bmod 23 = 8A=15625mod23=8B=30517578125 mod 23=19B = 30517578125 \bmod 23 = 19B=30517578125mod23=19A=8A=8A=8, B=19B=19B=194计算 K=196 mod 23K = 19^6 \bmod 23K=196mod23计算 K=815 mod 23K = 8^{15} \bmod 23K=815mod23—5K=47045881 mod 23=2K = 47045881 \bmod 23 = 2K=47045881mod23=2K=35184372088832 mod 23=2K = 35184372088832 \bmod 23 = 2K=35184372088832mod23=2✓\checkmark✓
验证：双方都计算出了共享密钥 K=2K = 2K=2。
窃听者 Eve 看到的：p=23p=23p=23, g=5g=5g=5, A=8A=8A=8, B=19B=19B=19。她需要求解 5a≡8(mod23)5^a \equiv 8 \pmod{23}5a≡8(mod23) 或 5b≡19(mod23)5^b \equiv 19 \pmod{23}5b≡19(mod23) 来找到 aaa 或 bbb。当 ppp 很小时（如本例 p=23p=23p=23），她可以穷举 a=1a=1a=1 到 222222 轻松求解。但在实际应用中，ppp 是一个 2048 位的素数，穷举在计算上完全不可行。
DH 的重要补充：认证的必要性
DH 本身不提供身份认证，因此容易受到中间人攻击（Man-in-the-Middle, MITM）：
Alice Mallory Bob
| | |
|--- A ----> 记录 A --- A' ----> |
| | |
|<--- B' ---- 伪造 B' <--- B ---- |
| | |
| K_AM = g^{ab'} | K_AM = g^{ab'} | K_BM = g^{a'b}
| | K_BM = g^{a'b} |
| ← 用 K_AM 加密 → | ← 用 K_BM 加密 → |
解决方案：在 DH 中引入数字签名（认证式 DH，即 Signed Diffie-Hellman），如 TLS 中的 DHE 密钥交换，使用 CA 签发的证书对 DH 公钥进行签名以验证身份。
安全参数
DH 强度ppp 的位数等价对称强度安全性评估（2025年）传统1024 位80 位❌ 已不安全（可被国家级别攻击者破解）中等2048 位112 位✅ 可接受（2025年仍安全）强3072 位128 位✅ 推荐超强4096 位150 位✅ 过度但可用最高8192 位192 位✅ 过度（极少需要）
重要：2024 年，NIST 正式要求 2026 年起停止使用 1024 位 DH，所有新部署必须使用 2048 位以上。事实上，许多浏览器和服务早在 2018 年左右就已停止支持 1024 位 DH。
计算开销
以下是在 Intel Xeon Platinum 8375C 上测试的 DH 运算性能（使用 OpenSSL 3.2）：
DH 参数密钥生成共享密钥计算相对开销DH-20481.2 ms1.1 ms1×DH-30723.8 ms3.5 ms3.2×DH-40969.1 ms8.6 ms7.8×DH-819272 ms68 ms62×
由于 DH 的计算开销随模长呈立方级增长（O(n3)O(n^3)O(n3)），选择过大的 ppp 会严重影响性能。
椭圆曲线 Diffie-Hellman (ECDH)
椭圆曲线密码学基础
椭圆曲线密码学（ECC）在 1985 年由 Neal Koblitz 和 Victor Miller 独立提出。ECC 的安全性基于椭圆曲线离散对数问题（ECDLP），它被认为比传统整数域的 DLP 更难求解，因此在相同的安全强度下可以使用更小的密钥尺寸。
椭圆曲线方程（Weierstrass 标准形）：
y2=x3+ax+b,4a3+27b2≠0y^2 = x^3 + ax + b, \quad 4a^3 + 27b^2 \neq 0y2=x3+ax+b,4a3+27b2=0
在 ECC 中，我们在曲线上定义一个加法群：
点加法：给定曲线上两点 PPP 和 QQQ，P+QP+QP+Q 是过 PPP、QQQ 的直线与曲线的交点关于 x 轴的对称点
标量乘法：kP=P+P+⋯+P⏟k 次kP = \underbrace{P + P + \dots + P}_{k \text{ 次}}kP=k 次P+P+⋯+P
ECDH 安全性：已知 GGG（基点）和 kGkGkG（公钥），求 kkk（私钥）是计算上不可行的。
ECDH 协议流程
Alice Bob
| |
| 选择私钥 a（随机数） | 选择私钥 b（随机数）
| 计算公钥 A = a * G | 计算公钥 B = b * G
| |
|------------- A ----------------> |
| |
|<------------- B ---------------- |
| |
| 计算 K = a * B | 计算 K = b * A
| = a * (b * G) | = b * (a * G)
| = abG | = abG
| |
| 双方得到相同的共享点 K |
与 DH 的对比：
DH：K=gab mod pK = g^{ab} \bmod pK=gabmodp（模幂运算）
ECDH：K=abGK = abGK=abG（椭圆曲线标量乘法）
常用曲线对比
曲线名称密钥长度（位）等价 RSA 强度安全评价性能标准来源secp256r1 (P-256)2563072✅ NIST 标准良好FIPS 186-4secp384r1 (P-384)3847680✅ 更高级别较慢FIPS 186-4secp521r1 (P-521)52115360✅ 最高级别慢FIPS 186-4X25519 (Curve25519)2563072✅ 推荐极快RFC 7748X448 (Curve448)4487680✅ 极强较快RFC 7748secp256k12563072⚠️ 非标准良好比特币使用
为什么选择 X25519？
X25519（Curve25519 上的 DH 变体，由 Daniel J. Bernstein 设计）在现代密码学中备受推崇：
性能优势（OpenSSL 3.2 基准测试）：
操作X25519P-256DH-2048密钥生成0.08 ms0.15 ms1.2 ms共享密钥0.08 ms0.14 ms1.1 ms
设计与工程优势：
恒定时间实现：X25519 的数学设计天然避免侧信道攻击——没有"检查是否为 0"的分支
没有"无效曲线攻击"：所有 2255−192^{255} - 192255−19 域上的非零点都落在安全曲线上，不会因为恶意的无效公钥而泄露私钥
参数固化：基点和 aaa 参数都已固定，开发者无法误用不安全参数
实现简单：易于编写、审核和安全审计
ECDH 的实际应用
ECDH 在 X25519 的推广下已经无处不在：
应用使用的曲线协议版本TLS 1.3X25519（首选）/ P-256RFC 8446SSHX25519 / P-256OpenSSH 8.0+Signal 协议X25519端到端加密WireGuardX25519现代 VPNiMessageX25519苹果端到端加密WhatsAppX25519Signal 协议比特币/以太坊secp256k1数字签名（非密钥交换）
ECDH 的潜在风险：量子计算威胁
ECC 的安全性依赖于 ECDLP 的计算困难性。1994 年，Peter Shor 提出了 Shor 算法，可以在量子计算机上多项式时间内求解 ECDLP 和整数分解问题。这意味着：
一台足够大的量子计算机可以完全攻破 ECDH
理论上使用 kkk 个逻辑量子位和 O(log3N)O(\log^3 N)O(log3N) 的门操作即可完成
目前主流量子计算机仍远未达到这一规模（需要约 6000 个逻辑量子位才能破解 256 位 ECC），但这使得后量子密码学成为紧迫的研究课题。
前向保密与 Ephemeral DH
什么是前向保密？
前向保密（Perfect Forward Secrecy, PFS）是密钥交换的一个重要安全属性：如果服务器的长期私钥将来被泄露，之前记录的所有会话密钥仍然安全。
不满足 PFS 的方案（如传统的 RSA 密钥交换）：
1. 客户端生成随机对称密钥 K
2. 用服务器 RSA 公钥加密 K 并发送给服务器
3. 双方用 K 通信
❌ 如果 RSA 私钥以后泄露，攻击者可解密以前所有会话
满足 PFS 的方案（DHE / ECDHE）：
1. 服务器在每次会话中生成临时 DH 私钥（ephemeral）
2. 服务器的长期证书仅用于对临时 DH 公钥做签名
3. 会话密钥从临时 DH 协商结果派生
✅ 长期私钥泄露只能让攻击者伪造未来的握手，
无法解密过去记录的会话
DHE vs ECDHE
属性DHEECDHE数学基础有限域离散对数椭圆曲线离散对数密钥大小2048-4096 位256-521 位性能慢（大数运算）快（约 10-100 倍）前向保密✅ 是✅ 是TLS 1.3 支持❌ 不再支持✅ 唯一方案推荐用途仅兼容旧系统所有新部署
ECDHE 在 TLS 1.3 中的完整流程
TLS 1.3 简化并加速了握手。ECDHE 是 TLS 1.3 中唯一支持的密钥交换机制：
Client Server
| |
| 生成临时 ECDHE 私钥 a | 生成临时 ECDHE 私钥 b
| 计算临时公钥 A = a*G | 计算临时公钥 B = b*G
| |
|--- ClientHello --------------->|
| (支持的曲线, KeyShare=A) |
| |
|<--- ServerHello ---------------|
| (选定的曲线, KeyShare=B, |
| 证书, 证书签名) |
| |
| 验证证书签名 |
| 计算 shared = a*B |
| 派生会话密钥 |
| |
|--- Finished (加密) ----------->|
| |
| 计算 shared = b*A |
| 派生会话密钥 |
| |
|<--- Finished (加密) -----------|
| |
| 安全通信开始 |
TLS 1.3 的优势：
1-RTT 完成握手（之前需要 2-RTT）
0-RTT 模式甚至可以在首次连接时就发送加密数据
所有密钥协商使用临时密钥，天然提供前向保密
后量子密钥封装机制 (KEM)
量子威胁背景
Shor 算法可以指数级加速求解以下问题：
整数分解（破解 RSA）
离散对数问题（破解 DH）
椭圆曲线离散对数问题（破解 ECDH）
因此，DHE 和 ECDHE 在面对大规模量子计算机时都不安全。
时间线（行业共识估计）：
2025 年：NIST 发布首批后量子密码标准（已完成）
2030 年：首个破解 2048 位 RSA 的量子计算机出现（乐观估计）
2035 年：量子计算机可能成为实质性威胁（保守估计）
现在开始迁移的意义：现在记录的加密数据，可能在 10-15 年后被量子计算机批量破解（"先存储，后破解"攻击）
什么是密钥封装机制？
密钥封装机制（Key Encapsulation Mechanism, KEM）是一种特定的密钥交换形式，由三个算法组成：
KeyGen() →\to→ (pk, sk)：生成公钥和私钥
Encaps(pk) →\to→ (c, K)：用公钥封装随机密钥 K，生成密文 c
Decaps(sk, c) →\to→ K：用私钥解封密文 c，恢复密钥 K
相比传统 DH 风格（双方各自贡献随机性），KEM 更偏向于"非对称封装"模型：一方封装密钥，另一方解封。
ML-KEM (FIPS 203) — 前身为 Kyber
2024 年 8 月，NIST 正式发布了 FIPS 203：Module-Lattice-Based Key-Encapsulation Mechanism Standard，将 CRYSTALS-Kyber 标准化为 ML-KEM。
数学基础：基于模块格（Module Lattice）上的 Learning With Errors (LWE) 问题。简单理解：
格密码学利用高维格上的最短向量问题（SVP）和最近向量问题（CVP）作为安全假设
ML-KEM 使用 Module-LWE 变体，通过在小维度上使用环结构获得性能与安全的平衡
至少目前没有已知的量子算法可以加速解决格上的这些问题
ML-KEM 参数与性能
安全级别标准公钥大小密文大小共享密钥大小等效 AES 强度ML-KEM-512FIPS 203800 字节768 字节32 字节 (256 位)AES-128ML-KEM-768FIPS 2031184 字节1088 字节32 字节AES-192ML-KEM-1024FIPS 2031568 字节1568 字节32 字节AES-256
与经典算法的对比（Intel Xeon Platinum 8375C）：
算法密钥生成封装/协商公钥大小安全级别X255190.08 ms0.08 ms32 字节128 位ECDH P-2560.15 ms0.14 ms65 字节128 位DH-20481.2 ms1.1 ms256 字节112 位ML-KEM-5120.07 ms0.12 ms800 字节128 位ML-KEM-7680.11 ms0.18 ms1184 字节192 位ML-KEM-10240.18 ms0.27 ms1568 字节256 位
ML-KEM 的计算性能与 ECDH 相当甚至更快，主要代价是带宽——公钥和密文比 ECDH 大一个数量级。
混合 KEM：量子安全+经典安全
由于后量子密码学仍然是相对年轻的领域，密码学界的共识是采用混合方案，同时使用经典算法（ECDH）和后量子算法（ML-KEM）进行密钥协商：
共享密钥 = KDF(ECDH_shared || MLKEM_shared || context)
优势：
即使 ML-KEM 未来被破解，仍保留 ECDH 级别的安全性
即使 ECDH 被量子计算机破解，仍保留 ML-KEM 级别的安全性
两种算法的安全性非此即彼
Google 的实际部署经验：
Google 早在 2016 年开始在 Chrome 和 Google 服务中试验混合密钥交换（CECPQ1：X25519 + NewHope），后续升级到 CECPQ2（X25519 + HRSS 和 X25519 + Kyber-512）。2023 年起，Chrome 默认启用了 X25519 + Kyber-768 的混合 KEM 方案。
TLS 2.0 与 KEM
IETF 正在标准化的 TLS 2.0（目前为草案）将全面采用 KEM 模式替代 ECDHE，预计主要使用 ML-KEM。
密钥派生 (Key Derivation)
共享密钥交换完成后，通常不直接使用共享密钥进行加密，而是通过密钥派生函数（KDF）从中派生出会话所需的多个子密钥。
HKDF (RFC 5869)
HKDF 是 HMAC-based Key Derivation Function 的标准，分为两个阶段：
阶段一：提取（Extract）
从多方贡献的熵源（如 ECDHE 共享密钥 + 可能的前向随机数）中提取一个高熵的伪随机密钥（PRK）：
PRK=HMAC(salt,IKM)\text{PRK} = \text{HMAC}(\text{salt}, \text{IKM})PRK=HMAC(salt,IKM)
阶段二：扩展（Expand）
从 PRK 扩展出所需长度的多个子密钥：
T(0)=空字符串T(1)=HMAC(PRK,T(0)∣∣info∣∣0x01)T(2)=HMAC(PRK,T(1)∣∣info∣∣0x02)…T(0) = \text{空字符串} \\
T(1) = \text{HMAC}(\text{PRK}, T(0) || \text{info} || 0x01) \\
T(2) = \text{HMAC}(\text{PRK}, T(1) || \text{info} || 0x02) \\
\dotsT(0)=空字符串T(1)=HMAC(PRK,T(0)∣∣info∣∣0x01)T(2)=HMAC(PRK,T(1)∣∣info∣∣0x02)…
TLS 1.3 中的派生链：
ECDHE 共享密钥
↓ HKDF-Extract(salt=0)
↓
早前秘密 (Early Secret)
↓ HKDF-Expand(标签="derived")
↓
握手秘密 (Handshake Secret)
↓ HKDF-Extract(salt=ECDHE_shared)
↓
主秘密 (Master Secret)
↓ HKDF-Expand
↓
{客户端加密密钥, 服务器加密密钥, IV, ...}
参数推导示例（TLS 1.3 AES-128-GCM）：
派生密钥长度用途client_handshake_traffic_secret32 字节握手阶段客户端→服务器加密server_handshake_traffic_secret32 字节握手阶段服务器→客户端加密client_application_traffic_secret_032 字节应用数据：客户端→服务器server_application_traffic_secret_032 字节应用数据：服务器→客户端exporter_master_secret32 字节密钥导出（Key Exporter）resumption_master_secret32 字节会话恢复
协议安全对比总表
协议安全假设前向保密量子抵抗性能推荐场景DH-2048有限域 DLP✅ (DHE)❌慢仅旧系统兼容ECDH P-256ECDLP✅ (ECDHE)❌快标准现代应用X25519Curve25519 DLP✅ (X25519)❌最快首选经典方案ML-KEM-512Module-LWE✅✅极快量子安全入门ML-KEM-768Module-LWE✅✅快推荐后量子方案ML-KEM-1024Module-LWE✅✅快高安全需求
密钥尺寸对比
X25519: 公钥 32 字节━━━━━━━━━━━━━━━━━━━━━
ECDH P-256: 公钥 65 字节━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
DH-2048: 公钥 256 字节━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ML-KEM-512: 公钥 800 字节━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ML-KEM-768: 公钥 1184 字节━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
DH-4096: 公钥 512 字节━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
注：ML-KEM 的带宽成本是其主要工程代价。在物联网等低带宽场景中，X25519 的 32 字节公钥优势显著。
端到端通信延迟对比（模拟 TLS 握手）
方案握手延迟（1-RTT）密钥生成总耗时X25519~5 ms0.08 ms~5 msDH-2048~5 ms1.2 ms~7 msML-KEM-512~5 ms + 额外数据量0.07 ms~6-8 msDH-4096~5 ms9.1 ms~14 ms
极端场景：在 2G / 卫星链路等高延迟环境中，ML-KEM 的大公钥传输会带来可感知的额外延迟。
最佳实践与建议（2025-2026）
新系统部署推荐
┌─────────────────────────────────────────┐
│ 短期（2025-2027）： │
│ 首选：X25519 + ML-KEM-768 混合方案 │
│ 备选：X25519（若后量子KEM尚未就绪） │
├─────────────────────────────────────────┤
│ 中期（2027-2030）： │
│ 全面转向：ML-KEM-768 + 混合策略 │
│ 逐步淘汰：纯 ECDH 方案 │
├─────────────────────────────────────────┤
│ 长期（2030+）： │
│ ML-KEM-768/1024 为主 │
│ 可能需要结合多轨 PQ 算法 │
└─────────────────────────────────────────┘
具体建议
立即停止使用：DH-1024、RSA 密钥交换（TLS_RSA 密码套件）
始终启用 ECDHE：在 TLS 配置中优先使用 ECDHE 密码套件
选择 X25519 而非 P-256：性能更好、实现更安全
启用混合 KEM：TLS 1.3 支持 X25519Kyber768 混合方案（Chrome 已默认启用）
关注 NIST 标准化进展：FIPS 203 (ML-KEM) 已经发布；FIPS 204 (ML-DSA) 和 205 (SLH-DSA) 也已发布
迁移计划：在 2028 年前完成所有系统的后量子密钥交换支持
TLS 配置示例（OpenSSL）
# Nginx TLS 1.3 推荐配置
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384;
ssl_ecdh_curve X25519:prime256v1:secp384r1;
// AWS CloudFront / CDN 后量子支持配置
{
"TLS13": {
"supported_groups": ["x25519_kyber768", "x25519", "secp256r1"]
}
}
总结
阶段代表性协议核心特征当前状态经典 Diffie-HellmanDH (1976)基于模指运算和 DLP⚠️ 正被取代（P-2048 仍可用）椭圆曲线 ECDHECDH / X25519 (2006)更小密钥、更高性能✅ 当下标准前向保密 ECDHEECDHE / DHE (2008+)临时密钥+长期证书签名✅ TLS 1.3 必需后量子 KEMML-KEM (2024)抗量子计算攻击✅ NIST 已标准化混合方案X25519 + ML-KEM-768双重安全保证✅ 推荐的新部署方案
密钥交换作为一个已经发展了近 50 年的密码学领域，正处在从经典公钥密码向后量子密码过渡的历史转折点上。安全工程人员应当立即开始规划和实施后量子迁移，同时确保前向保密作为所有新系统的基本特性。
参考资料
Diffie, W. & Hellman, M. (1976). New Directions in Cryptography. IEEE Transactions on Information Theory.
NIST (2024). FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard.
IETF (2018). RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3.
IETF (2016). RFC 7748: Elliptic Curves for Security.
IETF (2010). RFC 5869: HMAC-based Extract-and-Expand Key Derivation Function (HKDF).
Bernstein, D.J. (2006). Curve25519: New Diffie-Hellman Speed Records.
Bos, J.W. et al. (2015). CECPQ1: Cloudflare and Google's post-quantum experiment.
NIST (2024). Transitioning the Use of Cryptographic Algorithms (SP 800-131A Rev. 3).
ETSI (2020). Quantum-Safe Cryptography: State-of-the-Art (TR 103 618).
Shor, P. (1994). Algorithms for quantum computation: discrete logarithms and factoring.
Wikipedia: Diffie–Hellman key exchange — https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
IETF Hybrid KEM Draft — https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
Cloudflare Blog: Post-Quantum Cryptography — https://blog.cloudflare.com/post-quantum-cryptography/