1. 从对称加密说到公钥体系为什么我们需要非对称算法先直接说结论RSA、ECC、ECDH 这三样是当下互联网安全基础设施里最核心的非对称算法三件套。你每天用的 HTTPS、SSH、代码签名、网银 U 盾、甚至区块链钱包地址背后都是它们在干活。这篇内容就是把这三兄弟从数学原理到工程落地的全链路讲清楚适合正在做信息安全、网络通信、嵌入式安全模块或者单纯对密码学好奇、想搞明白“为什么 ECC 密钥比 RSA 短这么多还更安全”的人。要说清楚非对称算法得先回到对称加密的痛点上。所谓对称加密就是加密和解密用同一把钥匙。AES 是典型代表速度快、硬件实现友好几 GB 的数据瞬间就能加解密完。但问题来了通信双方怎么安全地拿到这把共同的钥匙你总不能在微信上明文发“我们的 AES 密钥是 123456”吧。早期方案是线下见面拷 U 盘或者用快递寄保险箱——这在互联网时代完全不可行。于是 1976 年 Diffie 和 Hellman 提出了公钥密码学的思想每个人生成两把钥匙一把公开分发公钥一把自己藏好私钥。用公钥加密的数据只有对应的私钥能解开而根据公钥反推私钥在计算上不可行。这套思想后来衍生出了两大流派一类是基于大整数分解难题的 RSA一类是基于椭圆曲线离散对数难题的 ECC。而我们常说的 ECDH本质上是把 ECC 算法用于 Diffie-Hellman 密钥交换解决的是“如何在不安全的信道上让双方协商出一把对称密钥”这个原始问题。所以要理解这三者的关系可以这样看RSA 和 ECC 是两套不同的公钥密码数学体系而 ECDH 是构建在 ECC 之上的协议。打个比方RSA 像一把传统的机械锁ECC 像一把电子指纹锁而 ECDH 是两人隔着墙喊话、最终却能把同一把钥匙对上的特殊方法。它们解决的问题不同适用的场景也完全不同搞混了就容易在工程选型上翻车。2. RSA 数学原理与工程实践大整数分解到底是咋回事2.1 从欧拉定理到密钥生成RSA 的全部核心就三步RSA 的数学基础是大整数分解难题两个大质数 p 和 q 相乘得到 n 很容易但反过来把 n 分解成 p 和 q 极其困难。n 的位数越大分解难度呈指数级上升。以当前的计算能力2048 位的 n 被普遍认为在可预见的未来无法暴力分解。具体的密钥生成流程是这样的随机选两个大质数 p 和 q计算 n p × q。实际应用中 p 和 q 都是 1024 位以上的质数n 就是 2048 位。计算欧拉函数 φ(n) (p-1) × (q-1)。选一个整数 e要求 1 e φ(n)且 e 与 φ(n) 互质。工程上 e 通常直接取 65537这个值选得好不好后面细说。计算 d使得 e × d ≡ 1 (mod φ(n))也就是 d 是 e 在模 φ(n) 意义下的乘法逆元。用扩展欧几里得算法可以高效求出 d。最后(n, e) 就是公钥(n, d) 是私钥。p、q、φ(n) 必须严格保密全部销毁。加密过程是密文 c m^e mod n其中 m 是明文对应的整数必须小于 n。解密过程是明文 m c^d mod n。这里面的核心就是欧拉定理m^φ(n) ≡ 1 (mod n)于是 m^(e×d) ≡ m^(k×φ(n)1) ≡ m (mod n)这就保证了加解密互逆。我见过不少人在实现的时候有个认知误区以为 RSA 加密是直接把字符串按字节拆开逐段计算。实际上 RSA 的输入是一个整数字符串需要先转成整数比如用 OAEP 填充前的字节拼接而且明文整数必须小于 n。如果是大文件正确做法是用 RSA 加密一个随机生成的 AES 密钥再用 AES 加密文件内容。这就是所谓的“混合加密”HTTPS 的 TLS 握手就是这么干的。2.2 为什么 e 取 65537指数选择的工程智慧很多人好奇为什么 RSA 的公钥指数总是 65537而不是 3 或者 17。这背后是一个效率与安全的折中。先说为什么不用 3。理论上 3 是合法的满足与 φ(n) 互质加密计算也快因为 3 只有两个二进制位。但问题在于如果同一明文被发送给三个不同的接收方各自有不同模数 n1、n2、n3攻击者可以用中国剩余定理直接从三个密文中恢复出明文这就是著名的低指数攻击。而且 3 作为指数时如果填充不当也容易受到 Coppersmith 攻击。65537 这个数二进制是 10000000000000001只有两个 1 位做模幂运算时只需要 17 次平方和 1 次乘法效率损失极小——相比随机选择 e 需要做完整的平方乘算法65537 的计算开销只有约 6% 的额外负担。同时它足够大有效规避了低指数的各种攻击路径。所以现在几乎所有主流安全库OpenSSL、Bouncy Castle、Java JCE在生成 RSA 密钥时默认的公钥指数一律是 65537。另外提一个生成质数时的细节工程上不会用普通的素性测试试除法而是先用 Miller-Rabin 做概率素性检验乘上多轮测试把误判概率压到 2^-80 以下再配合 Lucas 测试彻底排除 Carmichael 数。标准库的 p、q 还要求满足差值的绝对值大于 2^(n/2 - 100)防止用费马分解法从相近的质数推出来。这些细节都是标准文档里不会写、但真实攻击者会利用的点。2.3 RSA 工程落地的三个大坑填充、长度、侧信道RSA 裸的数学运算教科书式 RSA是不能直接拿来用的。因为没有填充的 RSA 是确定性加密同样的明文每次生成的密文都一样这给了攻击者频率分析的窗口。而且小明文存在可被枚举的风险。所以实际应用中必须加填充方案。目前主流是 OAEPOptimal Asymmetric Encryption Padding它在加密前对明文做随机化处理引入非确定性同时提供完整性校验。旧的 PKCS#1 v1.5 填充虽然兼容性好但存在 Bleichenbacher 攻击的风险——攻击者通过不断发送恶意密文、观察服务器是否返回 padding error逐步恢复出明文。这个攻击在 TLS 里被反复利用过。如果你是新建系统不要再用 PKCS#1 v1.5直接上 OAEPRSA-OAEP。第二个坑是密钥长度选择。1024 位 RSA 早在 2013 年就被 Google 明确废弃NIST 在 2023 年正式要求 2024 年后全面弃用 1024 位。目前底线是 2048 位安全性约为 112 位如果要长期保护数据比如到 2030 年以后建议 3072 位。但要注意不是越长越好密钥长度增加一倍加解密耗时增长约 8 倍。有一个简单的估算方法模幂运算的耗时与密钥位数成立方级关系2048 位单次 RSA 操作在普通 CPU 上大约 1~2 毫秒4096 位则可能到 10 毫秒以上这在物联网设备上会明显拖累握手延迟。第三个坑是侧信道。RSA 私钥操作里如果用了“简单平方乘”算法根据指数位是 0 还是 1乘法的执行次数不一样攻击者可以通过能耗曲线判断出私钥的每一位。所以工程实现里一定要用“蒙哥马利阶梯”或者“固定窗口”这类恒定时间算法保证任意时刻执行的操作序列与私钥内容无关。这个细节在你自己写 RSA 实现时极其重要而在用 OpenSSL 这类库时默认已经处理好了。3. ECC 的几何直觉与代数实现一条曲线解决的不只是密钥长度3.1 椭圆曲线的群结构为什么“点加法”可以构建密码学难题ECC 的数学对象不是我们中学学的那种椭圆方程图像而是满足特定方程的点集。最常用的是 Weierstrass 标准型y² x³ ax b其中要求判别式 4a³ 27b² ≠ 0保证曲线没有奇异点没有尖点或自交点。在这条曲线上定义一个“加法”运算两个点 P 和 Q 连线与曲线交于第三个点 R把 R 关于 x 轴对称得到 R记作 P Q R。如果 P 和 Q 是同一个点就做切线。这个运算构成一个阿贝尔群——有单位元无穷远点、有逆元关于 x 轴对称点、满足结合律和交换律。椭圆曲线密码学的核心困难问题叫做椭圆曲线离散对数问题ECDLP给定基点 G 和它的倍数 kG P要求出 k。在精心选取的曲线上这个问题目前只有指数级算法可以解。对比 RSA 的大整数分解——它有亚指数级的数域筛法——ECC 在同样的安全强度下需要的密钥位数大幅降低。可能有人会问为什么不直接像 RSA 那样用“乘法”而要用“加法”因为椭圆曲线上的点加法不直观、不满足普通数的乘法性质这意味着没有类似“分解质因数”的工具可以借用攻击者手里的武器更少。从另一个角度看ECC 是“在更难的数学难题上构建的密码系统”所以可以用更短的密钥达到同样的安全级别。3.2 密钥生成与标量乘法私钥就是一个随机数ECC 的密钥生成极其简单选一条曲线比如 NIST P-256 或 Curve25519曲线有一个公开基点 G一个曲线上的点通常用十六进制序列表示。私钥 d 就是一个随机生成的 256 位整数满足 1 ≤ d ≤ n-1其中 n 是基点 G 的阶一个大质数。公钥 Q dG就是私钥乘以基点得到的另一个点。这里要说清楚公钥是曲线上的一个点有 x 和 y 两个坐标。工程上通常只存 x 坐标加一个标识 y 奇偶性的比特压缩公钥格式这样可以把 256 位公钥压到 33 字节相比 RSA 2048 位公钥的 256 字节实际是模数 n 的长度体积优势明显。在区块链、物联网这种对存储和带宽敏感的领域这个优势尤其关键。标量乘法 kG 的实现也有大学问。简单粗暴的“逐个点加”是不可行的——k 是 256 位的大整数逐次相加要执行 2^256 次。工程上用“双倍与加”算法把 k 写成二进制从高位到低位扫描每扫描一位做一次倍点运算当前位为 1 再做一次点加。这样总复杂度是 O(log k)约 256 次倍点和约 128 次点加。这个算法在实现时同样有侧信道风险——目前主流的恒定时间实现是 Montgomery ladder确保任何 k 值下执行的操作序列完全一致。3.3 曲线参数的选择P-256 与 Curve25519 之争ECC 的安全性不只看密钥长度曲线参数本身就决定了安全性。NIST P-256也被称为 secp256r1是使用最广的标准曲线广泛用于 TLS 和数字签名。它的参数由 NIST 在 2000 年左右发布安全性经过了二十多年的检验。但有一个争议点P-256 的参数生成过程不透明有人怀疑可能存在后门尤其是 NSA 参与的那批曲线的生成机制一直存疑。Curve25519 是 Daniel J. Bernstein 设计的曲线参数生成完全透明可以用 NUMS 方式验证并且特别关注了实现层面的恒定时间问题。X25519 是基于 Curve25519 的 ECDH 实现它只使用 x 坐标做运算天然免疫一类针对 y 坐标的小子群攻击而且在设计上就规避了二进制扩展域——因为这类域的实现更容易出现侧信道漏洞。目前 TLS 1.3 里X25519 是默认且强推的密钥交换方案OpenSSL 1.1.1 对它的性能优化做得也极好。给一个参考建议新项目无脑选 X25519 作为 ECDH 曲线数字签名用 Ed25519基于 EdDSA 的 Curve25519 签名方案不要自己拍脑袋选小众曲线。如果因为合规原因必须用 NIST 曲线就用 P-256比 P-384、P-521 的兼容性更好性能也更快。选曲线时还要注意曲线的阶必须是大质数或者大质数乘以小余因子且余因子不超过 4否则容易受到小子群攻击。Protocol Buffers 的加密配置里Google 默认推荐的也是 X25519不是没有理由的。4. ECDH 密钥交换实战从握手原理到 PTP 时延补偿的延伸4.1 ECDH 的三步握手和一次性质数ECDHElliptic Curve Diffie-Hellman是 Diffie-Hellman 密钥交换的椭圆曲线版本解决的核心问题是在不安全的信道上如何让双方协商出一个共享密钥而不需要预共享任何秘密。过程非常简洁Alice 生成随机数 a计算 A aG把 A 发给 Bob。Bob 生成随机数 b计算 B bG把 B 发给 Alice。Alice 用自己私钥 a 和 Bob 的公钥 B 计算 S aB a(bG) (ab)G。Bob 同样计算 T bA b(aG) (ab)G。此时 Alice 和 Bob 得到相同的点 S。一般情况下取 S 的 x 坐标作为共享密钥再通过 KDF密钥派生函数如 HKDF生成最终的 AES 密钥。这里有个至关重要的安全细节这个协议本身不提供身份认证中间人攻击可以轻松破坏它。如果 Mallory 同时与 Alice 和 Bob 各跑一次 ECDH她就能分别与两人建立共享密钥而 Alice 和 Bob 还以为是彼此。所以真实世界的 ECDH 必须配合身份认证要么用数字签名ECDSA/EdDSA对临时公钥签名要么把公钥本身预先做认证比如证书体系。TLS 1.3 中密钥交换用 ECDHEE 表示 ephemeral临时每次会话生成新的临时密钥对同时用服务器的长期签名密钥对该临时公钥做签名这样才能同时实现前向安全和身份认证。另外每次 ECDH 最好用全新的随机密钥对不要复用长期密钥。复用的风险在于一旦私钥泄露之前所有用同一私钥协商的会话密钥全部能被还原——这就是所谓的“前向安全性”丧失。我在实际项目里见过把 ECDH 密钥对固定写死在设备里的做法这是非常不推荐的安全反模式。4.2 X25519为什么我强烈推荐你的下一个项目用它如果你的项目里需要做密钥交换你不应该手写 ECDH而是直接用 X25519。X25519 是基于 Curve25519 的 ECDH 函数实现输入是一个 32 字节的标量私钥和一个 32 字节的 u 坐标公钥输出 32 字节的共享密钥。它有以下值得注意的优点设计简单只使用 x 坐标公式最简不容易在坐标转换上出错。恒定时间原生设计就是常数时间运算天然抵抗时序攻击。无小子群问题Curve25519 的阶为 8×pp 是大质数攻击者只能把密钥限制在 8 的余因子内而协议会强制清除这些低阶位极大降低了恶意公钥攻击的风险。性能极佳在支持 ARM NEON 指令的嵌入式平台上X25519 一次运算可以在几十微秒内完成相比 RSA 2048 的手握传输过程动辄毫秒级优势明显。我在嵌入式项目中实测过在一颗主频 200MHz 的 Cortex-M4 内核上RSA-2048 公钥加密约 20ms私钥解密约 200ms而 X25519 的标量乘法只需要约 30ms。如果把功耗和证书体积一起算进去X25519 基本上是嵌入式安全通信的事实标准。4.3 工程延伸PTP over E1 场景中的非对称时延补偿从热搜词里注意到有不少人在搜索“通用 ptp 非对称时延补偿算法”和“可用于 ptp over e1 转换器端的软件伺服补偿”这样的关键词。这实际上是一个很经典的工程交叉场景PTP精确时间协议IEEE 1588依赖网络路径的时间对称性来做时钟同步——主从时钟之间通过交换 Sync、Delay_Req 等报文计算主到从的路径时延和从到主的路径时延然后取平均值作为路径时延。如果报文在主从方向的实际传输时延不对称这个平均值就会引入同步误差差值直接反映到时钟偏差上。在 PTP over E1 这种场景下E1 线路是一个时分复用链路上下行的物理通道是独立的而且 E1 转换器在 TDM 到分组网络的转换过程中会引入不同的排队延迟、抖动缓存深度所以非对称时延是常态。常规的 PTP 默认假设网络是对称的在这种链路上同步精度会大打折扣。这时候可以用“非对称时延补偿”来解决通过测量或预先校准得到主到从方向的时延 d_ms 和从到主方向的时延 d_sm两者不相等。那么 PTP 里的平均路径时延就不再取简单平均而是用加权公式offset (t2 - t1 - d_ms) 或者 (t2 - t1 d_sm)/2 的形式把已知的不对称差 d_asym d_sm - d_ms 代进去做修正。这里的“软件伺服补偿”就是在 E1 转换器端的局部时钟伺服器比如 PI 控制器里动态调整偏移量把非对称带来的固定偏差通过滤波算法实时消除掉。这个场景到非对称算法本身的关联在于在实际的 E1 转换器或者分组网络中如果在上层安全协议中引入了 IPsec 或 MACsec那么加密隧道也会引入额外的非对称处理时延因为加解密处理时间、分组头新增的字节数上下行可能不同进一步恶化了 PTP 的时间对称性。此时 ECDH 协商出来的密钥配合 AES-GCM 等认证加密算法加解密时延会被拉高而如果选用了 RSA 2048 做握手计算时延更是成倍增加。所以做 PTP 网络防护时密钥协商尽量用 ECC用更短的密钥运算时间给 PTP 校正留出更多预算——这是我在做时间同步网关时踩过坑后总结出来的经验。4.4 一个真实的 RSA 公钥报错场景rsa public key not find热搜词里有“navicat15激活 rsa public key not find”和“目标主机支持rsa密钥交换【原理扫描】”这两条本质上都和 RSA 公钥解析相关。前者的报错常见于软件授权激活流程中软件需要本地找到用于验签的 RSA 公钥文件来校验激活码但公钥缺失或路径配置错误就报这个错。后者则是安全扫描工具在探测目标主机是否支持 RSA 密钥交换这实际上是 TLS 协议参数的安全弱点因为 RSA 密钥交换不提供前向保密性按 PCI DSS 等标准应该禁用。从工程角度我可以针对性给出几个排查思路报错“rsa public key not find”时先确认公钥文件存在且格式正确PEM 或 DER用 openssl rsa -pubin -in pub.pem -text -noout 验证能不能正常解析。确认系统或应用读取公钥的路径是否有权限问题很多嵌入式 Linux 环境下/etc/ 目录下公钥文件被 SELinux 策略挡住会导致读取失败。如果报错发生在激活码校验阶段检查是不是把中文字符或者 BOM 头带进了公钥文件这类问题我用十六进制查看器xxd排过很多次。安全扫描报“支持 RSA 密钥交换”正确的处理是在服务端禁用 TLS_RSA_WITH_* 系列套件改用 ECDHE_RSA 或 ECDHE_ECDSA。这正好呼应非对称算法的选型趋势密钥交换用 ECDHE身份认证用 RSA/ECDSA而不是用 RSA 做密钥交换。5. 三张表看懂 RSA、ECC、ECDH 的差异与选型5.1 安全性、性能与体积的核心对比维度RSAECCECDH数学难题大整数分解椭圆曲线离散对数椭圆曲线离散对数乘法交换等效 AES-128 安全级别密钥长度3072 位256 位256 位公钥体积384 字节32~33 字节压缩32 字节签名/解密性能慢私钥操作最慢快私钥操作极快标量乘法快加密/验签性能较快比 RSA 慢一些但差别不大不适用抗量子计算能力弱Shor 算法弱Shor 算法变体弱数据结构复杂度简单容易实现较复杂易出错需要曲线参数处理这张表里最直观的点是密钥长度的差距ECC 256 位的安全性等效 RSA 3072 位但密钥只有后者的十二分之一。这带来的是存储、带宽、功耗的全方位优势。我实测过在 HTTPS 握手阶段证书链体积差 3~5 倍ECC 证书明显更快完成握手。RSA 在“验签”和“公钥加密”上其实性能不错因为公钥指数 e 是固定的 65537计算量小但私钥操作解密和签名要做大指数的模幂性能瓶颈明显。ECC 恰好相反公钥运算验证签名本质上是一次标量乘法和私钥运算相差不大整体性能曲线更平稳。所以在硬件条件受限的设备上ECC 的功耗优势非常突出。5.2 应用场景的匹配清单场景推荐算法原因HTTPS 证书签名ECDSAP-256 或 Ed25519体积小、握手快所有主流浏览器支持传统系统兼容老嵌入式RSA 2048已有软硬件实现成熟迁移成本低密钥交换/会话协商X25519ECDH恒定时间、小子群安全、性能顶级区块链地址与交易签名secp256k1 或 Ed25519依赖具体链secp256k1 是 BTC/ETH 的标准文件签名代码签名RSA 3072 或 ECDSA P-384合规要求需要长周期信任物联网设备安全启动ECDSA P-256公钥只存一次验证极快时间同步网络加密隧道X25519 AES-GCM时延预算紧张ECC 计算时延更可控5.3 到底选谁一个务实的决策框架我见过很多团队在选型上纠结很久其实核心就三条第一条看你的受信任根体系。如果你的上级机构或行业标准已经指定了 RSA 证书链你就用 RSA 配合 ECDHE 做密钥交换如果是从零开始直接用 ECCECDSA ECDHE就好不必迁就旧体系。第二条看硬件是否支持硬件加速。多数 x86 服务器和新款手机都有 AES-NI 和 PCLMULQDQ 指令但 ECC 的优化指令不如 RSA 普及部分老平台的 ECC 性能反而一般。老平台的 RSA 加速器比如某些安全芯片内置 RSA 引擎就是制约你换曲线的因素。实测后决定不要看理论参数。第三条看是长期数据保护还是短期会话。如果要保护的数据需要保密十年以上我建议直接上 RSA 3072 或 ECC P-384不推荐 2048 位 RSA 和 256 位 ECC 作为“长期档案级”保护——因为量子计算的发展虽然还没到实际威胁但密码学界的共识是“先收集后解密”的威胁模型已经成立。对抗量子计算的算法是 ML-KEM、SLH-DSA 这类后量子算法但那是另一个话题。6. 实操经验与避坑清单6.1 我踩过的三个真实的实现层面的坑先说一个我自己在嵌入式项目里踩过的坑使用 mbedTLS 做 ECDH 时忘记调用 mbedtls_ecdh_setup 初始化曲线参数导致后面协商出的共享密钥一直是错的。这种错非常隐蔽因为不是崩溃而是每次协商的密钥都不一样且全部错误。排查方法是打印中间结果逐项核对双方算出的共享密钥是否一致一旦不一致逐层回退检查坐标和曲线参数是否匹配。第二个坑和公私钥的格式有关。X25519 的 32 字节私钥在 RFC 7748 里定义了“clamping”操作——把最高字节的 bit 7 置 0、bit 6 置 1、最低三个字节的低 3 位清零。这个操作很多人实现时忽略导致直接拿随机数当私钥用结果在少数情况下会产生低阶点让共享密钥变成预定义的小集合之一攻击者可以暴力枚举。这个问题在标准库里通常已经处理了比如 libsodium 的 crypto_box_beforenm 会自动 clamp但如果自己用 OpenSSL 的原生接口必须手动调用。我见过一个做 IOT 设备的产品因为省了 clamp 步骤实测 5% 的设备协商出来的共享密钥是固定值直接报废了一批设备。第三个坑是密钥派生。ECDH 协商出来的共享点是 32 字节在椭圆曲线群里有约一半的 x 坐标可能不满足某些应用对“均匀随机串”的要求。直接拿它当 AES 密钥用有可能引入统计偏差。正确做法是经过 HKDF 或至少 SHA-256 做一次哈希派生。TLS 1.3 内部已经做了这一步但如果自己设计协议很容易忽略。6.2 标准库使用建议与性能基线语言/平台推荐库注意事项C/COpenSSL、mbedTLS、libsodiumlibsodium 的 crypto_box 和 crypto_sign 封装程度高不易误用JavaBouncy Castle、SunJCE内置注意 Provider 顺序低版本 JDK 的 ECC 支持不全Gocrypto/ecdh、crypto/ecdsaGo 1.20 内置 ECDH 支持API 简洁Pythoncryptography、PyNaClPyNaCl 即 libsodium 的 Python 绑定推荐Rustring、dalek-cryptographydalek 系列的 Curve25519 实现质量极高一个可参考的性能基线普通 x86 服务器单线程OpenSSL 的 X25519 约 10~20 万次/秒ECDSA P-256 签名约 5~8 万次/秒验签约 2~3 万次/秒RSA 2048 私钥操作签名/解密约 2000~5000 次/秒公钥操作验签/加密约 5~10 万次/秒。如果你的需求远超这个量级就该考虑硬件加速或者上后量子算法了。6.3 审计你的系统一张自查清单最后给你一份自查清单用来快速判断现有系统里非对称算法相关的配置是否健康是否还在使用 RSA 1024如果是立刻淘汰。TLS 套件里是否还有 TLS_RSA_WITH_*即 RSA 密钥交换如果有禁用换成 ECDHE_RSA 或 ECDHE_ECDSA。证书签名是否用的 SHA-1SHA-1 在 2017 年就被 Chrome 标记为不安全业界已经全面弃用换 SHA-256。自己的协议里ECDH 临时公钥是否有签名保护没有就存在中间人攻击风险。私钥文件是否用明文存储在设备里至少要做硬件安全模块保护或用 KEK 加密后存储。是否实现了恒定时间的比较函数比如比较认证标签或共享密钥时用 memcmp 会有时序泄露的风险建议用恒定时间的 equal 函数。ECDH 协商成功后是否做了 KDF 派生如果没有补上 HKDF。我在实际做安全审计时按这份清单能排查出 60% 以上的常见问题。密码学这个领域细节决定了安全性而安全性没有“差不多”只有“够不够好”。