HTML5不支持原生Diffie-Hellman密钥交换，需依赖Web Crypto API实现ECDH（如P-256曲线），且必须在HTTPS/localhost安全上下文中运行；手动JavaScript实现DH存在精度、侧信道和中间人等严重风险。
HTML5 本身不直接支持 Diffie-Hellman（DH）密钥交换，因为它是前端运行的标记语言和 API 集合，不具备原生密码学协议实现能力。真正的 DH 密钥交换需依赖浏览器提供的加密 API（如 Web Crypto API），且仅限于支持的算法和上下文（如 TLS 已在传输层自动完成 DH，前端通常无需手动实现）。
Web Crypto API 是实际可用的途径
现代浏览器通过 Web Crypto API 提供了有限但安全的密钥协商能力。目前（截至 Chrome/Firefox/Edge 稳定版），仅支持 ECDH（Elliptic Curve Diffie-Hellman），不支持传统的有限域 DH（FFDH）。ECDH 是 DH 的椭圆曲线变种，更高效、密钥更短、安全性相当。
- 必须使用
EcKeyAlgorithm（如"namedCurve": "P-256"或"P-384"） - 双方需各自生成 ECDH 公私钥对，交换公钥后调用
deriveKey()或deriveBits()计算共享密钥 - 全过程必须在安全上下文（HTTPS 或 localhost）中进行，否则 API 被禁用
不能在纯 HTML5 页面里“手写 DH 数学公式”
有人尝试用 JavaScript 手动实现模幂运算（如 (g^a mod p)）来模拟 DH，这存在严重风险：
- JavaScript 数值精度有限，大素数（如 2048 位）会丢失精度，导致密钥错误或可预测
- 无恒定时间运算，易受计时攻击
- 缺乏侧信道防护，私钥可能被推测
- 未绑定身份，无法抵御中间人攻击（需额外签名或证书机制）
典型 ECDH 前端流程（简化示意）
假设 Alice 和 Bob 协商共享密钥：
立即学习“前端免费学习笔记（深入）”；
- Alice 调用
crypto.subtle.generateKey("ECDH", {name: "ECDH", namedCurve: "P-256"}, false) - Alice 导出公钥（
exportKey("spki", keyPair.publicKey)），发送给 Bob - Bob 同样生成自己的密钥对，导出公钥发回 Alice
- 双方分别用对方公钥 + 自己私钥调用
deriveKey({name: "ECDH", public: otherPublicKey}, privateKey, {name: "AES-GCM", length: 256}, true, ["encrypt", "decrypt"]) - 得到相同的 AES 密钥，用于后续对称加密通信
更现实的选择：交给 TLS 处理
绝大多数场景下，前端无需自己做密钥交换：
- HTTPS 连接已由浏览器与服务器在 TLS 握手中自动完成 ECDH 或 FFDH 密钥协商
- 前端只需通过
fetch()、WebSocket等安全 API 发送数据，加密由底层保障 - 若需端到端加密（如聊天消息不被服务器解密），应在应用层用 Web Crypto 加密明文，但密钥分发仍需可信通道（如用服务器中转公钥 + 签名验证）
不复杂但容易忽略：ECDH 只生成共享密钥材料，还需用 HKDF 等密钥派生函数处理成可用密钥；且必须配合身份认证，否则毫无安全性可言。
