密码学基础回顾：非对称加密体系、哈希函数与数字签名标准
做硬件加速这行，有个坎儿你绕不过去——密码学基础。我见过不少工程师，上来就撸 Verilog 实现 RSA 模幂，结果连公钥私钥怎么配对的都说不清楚。嗯，这不行。今天咱们把三个核心模块掰开揉碎讲清楚：非对称加密、哈希函数、数字签名标准。这些都是后面硬件加速的基石。
非对称加密体系：RSA 与 ECC
非对称加密，说白了就是两把钥匙——公钥公开，私钥自己藏好。你用它加密，我用它解密，中间人就算拿到公钥也白搭。
RSA：大数分解的硬骨头
RSA 的安全性建立在「大整数分解」这个数学难题上。给你两个大素数 p 和 q 的乘积 n，想反推出 p 和 q，计算量是指数级的。我当年做第一个 RSA 协处理器时，踩过一个坑：密钥生成时随机数质量不够，导致 p 和 q 的差值太小，被 Fermat 分解法秒破。嗯，从那以后我再也不敢用库函数默认的随机数生成器了。
RSA 的核心运算就两个：
- 加密/验签：\( c = m^e \mod n \)（公钥指数 e 通常取 65537）
- 解密/签名：\( m = c^d \mod n \)（私钥指数 d 保密）
硬件加速的重点就在模幂运算上。我建议你重点关注 Montgomery 模乘算法，它能避免除法，在硬件里特别好实现。
关键参数对比
| 参数 | RSA-2048 | RSA-4096 |
|---|---|---|
| 模数 n 长度 | 2048 bit | 4096 bit |
| 安全等级 | 112 bit | 128 bit |
| 签名速度（软件） | ~2000 次/秒 | ~500 次/秒 |
| 硬件加速后 | ~50000 次/秒 | ~15000 次/秒 |
ECC：椭圆曲线上的优雅
ECC 用更短的密钥达到同等安全强度。256 位的 ECC 密钥，安全性和 3072 位的 RSA 差不多。为什么？因为 ECC 依赖的是椭圆曲线离散对数问题（ECDLP），破解难度比大数分解高得多。
ECC 的签名算法主要有 ECDSA 和 SM2（国密标准）。我个人习惯在资源受限的场景优先选 ECC，比如物联网芯片、智能卡。你想想看，一个 256 位的点乘运算，硬件面积比 RSA 的 2048 位模幂小太多了。
我的经验：ECC 的标量乘法（kP）是硬件加速的核心。用 Montgomery 阶梯算法可以抵抗简单功耗分析（SPA），我在一个金融安全芯片项目里就用过，效果不错。
哈希函数：SHA-256 与 SM3
哈希函数把任意长度的消息压缩成固定长度的摘要。签名验签里，我们不会直接签原始消息，而是签它的哈希值。为什么？因为哈希运算快，而且能保证消息完整性。
SHA-256：国际标准
SHA-256 输出 256 位摘要，属于 SHA-2 家族。它的核心是 64 轮压缩函数，每轮用 6 个逻辑函数和 8 个工作寄存器。硬件实现时，我建议你注意两点：
- 消息调度：16 个 32 位字扩展到 64 个，这个扩展逻辑可以流水线化
- 加法器链：每轮有 4 个 32 位加法，用进位保存加法器（CSA）能减少关键路径
我曾经在一个项目里把 SHA-256 的吞吐做到 10 Gbps，秘诀就是展开 4 轮并行计算。当然，面积也翻了一倍——这就是典型的面积换速度。
SM3：国密标准
SM3 是中国国家密码管理局发布的哈希标准，输出也是 256 位。它的结构和 SHA-256 类似，但细节不同：
| 特性 | SHA-256 | SM3 |
|---|---|---|
| 消息分组 | 512 bit | 512 bit |
| 摘要长度 | 256 bit | 256 bit |
| 压缩轮数 | 64 | 64 |
| 逻辑函数 | 6 个 | 8 个（含置换函数 P₀/P₁） |
| 硬件面积 | 基准 | 约 +15% |
SM3 的置换函数 P₀ 和 P₁ 是它和 SHA-256 最大的区别。硬件实现时，这些置换其实就是异或和循环移位，组合逻辑就能搞定，不费什么资源。
注意：国密标准要求 SM3 必须通过国家密码管理局的认证。如果你的产品要进政府采购清单，千万别用开源库的「兼容实现」——我见过有人因为这个被驳回，重新流片损失惨重。
数字签名标准：PKCS#1 v1.5 与 PSS
有了非对称加密和哈希，怎么把它们组合成签名方案？这就是数字签名标准干的事。RSA 的签名标准主要有两个：PKCS#1 v1.5 和 PSS。
PKCS#1 v1.5：老当益壮
PKCS#1 v1.5 是最早的 RSA 签名标准，结构简单：
签名值 = (0x00 || 0x01 || PS || 0x00 || DigestInfo) ^ d mod n其中 PS 是填充字节（全 0xFF），DigestInfo 包含哈希算法标识和摘要值。这个方案在硬件里实现特别快，因为填充逻辑就是简单的拼接和比较。
但是，v1.5 有个著名的攻击——Bleichenbacher 攻击。攻击者利用格式检查的漏洞，通过选择密文逐步恢复明文。嗯，这里要注意：如果你的硬件实现里对填充格式的检查太「宽容」，就可能被利用。我建议你在硬件里做严格的格式校验，不要偷懒只检查首尾字节。
PSS：概率签名方案
PSS（Probabilistic Signature Scheme）是 PKCS#1 v2.0 引入的，安全性有严格证明。它的结构复杂一些：
签名值 = (0x00 || maskedDB || salt || bc) ^ d mod n其中 maskedDB 是经过掩码处理的哈希值，salt 是随机数，bc 是固定边界字节。PSS 引入了随机性，同样的消息每次签名结果都不同——这能防止某些选择消息攻击。
我个人习惯在新项目里优先用 PSS。虽然硬件实现比 v1.5 多 20% 左右的逻辑，但安全性提升是值得的。尤其是做金融、政务这类高安全场景，PSS 几乎是必选项。
签名方案对比
| 特性 | PKCS#1 v1.5 | PSS |
|---|---|---|
| 随机性 | 无 | 有（salt） |
| 安全证明 | 无 | 有（ROM 模型） |
| 硬件面积 | 基准 | +15%~25% |
| 适用场景 | 兼容旧系统 | 新设计、高安全 |
知识体系总览
下面这张图把本章的核心脉络串起来了。你仔细看，从原始消息到最终签名，每一步都对应一个硬件加速模块。
你看，从消息进来，先过哈希，再过签名方案，最后用非对称加密的私钥运算。硬件加速的切入点就在这三个模块里。哈希函数可以流水线并行，签名方案的填充逻辑可以硬连线，非对称加密的模幂/点乘可以用专用乘法器阵列加速。
我的建议：做硬件加速方案时，先搞清楚你的瓶颈在哪。如果是签名吞吐不够，优先优化非对称运算单元；如果是验签延迟太高，看看哈希和签名方案能不能合并流水线。我曾经在一个项目里把哈希和 PSS 的掩码生成合并成一个模块，省了 10% 的面积。
好了，密码学基础就回顾到这儿。这些概念后面会反复用到——尤其是做硬件架构设计时，每个模块的接口定义、时序约束、面积预算，都离不开今天讲的这些底层原理。