第3章：非对称加密算法——RSA与ECC实战
聊完对称加密，咱们进入另一个世界——非对称加密。说实话，我第一次接触这个概念时，觉得它像魔法一样。一把公钥加密，一把私钥解密，两把钥匙还不一样。这怎么做到的？
后来我明白了，它靠的是数学上的单向陷门函数。正向计算容易，逆向推导极难。RSA就是基于大整数分解难题，ECC则基于椭圆曲线离散对数问题。今天咱们把这两个家伙彻底讲透。
3.1 RSA算法原理——大数分解的硬骨头
RSA的名字来自三位发明者：Rivest、Shamir、Adleman。1977年提出，至今仍是应用最广的非对称算法之一。
它的核心思想很简单：两个大素数相乘容易，但把乘积分解回两个素数极难。你想想看，给你两个300位的素数，乘起来一秒搞定。但给你一个600位的合数，让你找出它的两个素因子……嗯，超级计算机也得算到天荒地老。
RSA的数学基础
- 欧拉函数 φ(n)：小于n且与n互质的正整数个数。对于两个素数p、q，φ(n) = (p-1)(q-1)
- 模反元素：e · d ≡ 1 (mod φ(n))，即d是e在模φ(n)下的乘法逆元
- 加密：c = m^e mod n
- 解密：m = c^d mod n
我在项目中遇到过一位同事，他直接用OpenSSL生成RSA密钥对，从不关心参数含义。结果有一次密钥长度设成了512位，被安全审计直接打回。记住：RSA密钥长度低于2048位，现在基本等于裸奔。
3.2 密钥对生成——手把手教你造钥匙
生成RSA密钥对，说白了就是走完下面这几步。我建议你至少手动走一遍流程，哪怕用脚本模拟也行，这样你对RSA的理解会深很多。
- 选两个大素数 p 和 q，长度相近，随机生成
- 计算 n = p × q，n的长度就是密钥长度（如2048位）
- 计算 φ(n) = (p-1)(q-1)
- 选公钥指数 e，常用65537（0x10001），它是个素数且计算效率高
- 计算私钥 d，满足 e · d ≡ 1 (mod φ(n))
- 销毁 p、q、φ(n)，只保留 (n, e) 作为公钥，(n, d) 作为私钥
# Python生成RSA密钥对示例
from Crypto.PublicKey import RSA
# 生成2048位密钥对
key = RSA.generate(2048)
# 导出公钥
public_key = key.publickey().export_key('PEM')
print(public_key.decode())
# 导出私钥（带密码保护）
private_key = key.export_key('PEM', passphrase='your-passphrase')
print(private_key.decode())
避坑指南
我曾经在生成密钥对时，直接用了系统默认的随机数生成器。结果在容器化部署时，多个实例生成了相同的密钥对——因为容器启动时的熵池不够。后来我强制使用硬件随机数或等待熵池充足，再也没出过问题。
另外，私钥导出时必须加密码保护。明文私钥等于把家门钥匙放在门口脚垫下。
3.3 数字信封技术——对称与非对称的完美联姻
RSA有个硬伤：慢。加密几百字节的数据还行，要是加密几兆的文件，CPU直接冒烟。所以实际项目中，没人会用RSA加密大量数据。
那怎么办？数字信封技术登场了。说白了就是：用对称密钥加密数据，用RSA加密这个对称密钥。
数字信封的工作流程
- 发送方随机生成一个对称密钥（如AES-256密钥）
- 用这个对称密钥加密原始数据
- 用接收方的RSA公钥加密这个对称密钥
- 把加密后的数据 + 加密后的密钥一起发给接收方
- 接收方先用RSA私钥解密出对称密钥
- 再用对称密钥解密出原始数据
你想想看，这样既解决了对称密钥分发的难题，又避免了RSA加密大数据的性能瓶颈。我在做金融支付系统时，所有敏感字段传输都用的数字信封。每次交易生成一个临时对称密钥，用完就丢，安全性拉满。
# 数字信封实现示例（伪代码）
# 发送方
session_key = generate_aes_key()
encrypted_data = aes_encrypt(plaintext, session_key)
encrypted_key = rsa_encrypt(session_key, receiver_public_key)
send(encrypted_data + encrypted_key)
# 接收方
session_key = rsa_decrypt(encrypted_key, receiver_private_key)
plaintext = aes_decrypt(encrypted_data, session_key)
3.4 ECC椭圆曲线加密——后起之秀
RSA用了四十多年，但它的密钥长度越来越长。2048位RSA还能撑一阵，但量子计算机一旦成熟，RSA基本就废了。ECC就是在这个背景下火起来的。
ECC的核心优势：更短的密钥，同等的安全强度。256位的ECC密钥，安全性和3072位的RSA差不多。你想想看，这对移动端、IoT设备意味着什么？省带宽、省存储、省算力。
| 安全等级 | RSA密钥长度 | ECC密钥长度 | 性能对比 |
|---|---|---|---|
| 80位 | 1024位 | 160位 | ECC快3-5倍 |
| 112位 | 2048位 | 224位 | ECC快5-8倍 |
| 128位 | 3072位 | 256位 | ECC快8-10倍 |
| 256位 | 15360位 | 512位 | ECC优势巨大 |
ECC的数学基础是椭圆曲线上的点群运算。公式是 y² = x³ + ax + b，配上一个大素数p构成有限域。在这个域上，给定基点G和私钥k，计算公钥K = kG很容易。但反过来，从K和G求k，就是椭圆曲线离散对数问题——难得很。
ECC vs RSA 选型建议
- 新项目优先ECC：性能好、密钥短、未来兼容性强
- 兼容旧系统用RSA：很多老设备、老协议只支持RSA
- 混合使用：ECC做密钥交换，RSA做数字签名（兼容性考虑）
- 警惕ECC专利：某些曲线有专利限制，推荐使用NIST标准曲线或Curve25519
我记得有一次做区块链项目，节点间通信需要频繁做签名验证。一开始用的RSA 2048，结果TPS死活上不去。换成ECC secp256k1后，签名验证速度提升了近10倍，CPU占用直接降了一半。这就是ECC的实战价值。
3.5 本章知识体系总览
下面这张图把非对称加密的核心脉络串起来了。我建议你保存下来，以后做方案设计时对照着看。
3.6 实战选型建议
说了这么多，到底怎么选？我直接给结论：
- Web服务API签名：用ECDSA with P-256，性能好，兼容性也够
- 移动端数据加密：用ECC + AES数字信封，省电省流量
- 金融交易签名：RSA 2048或3072，监管合规要求多
- 区块链钱包：secp256k1，行业标准，生态成熟
- IoT设备：ECC P-256或Curve25519，密钥短，算力要求低
千万别踩的坑
我曾经见过一个项目，为了"安全"自己实现RSA算法。结果素数生成有漏洞，密钥空间大幅缩小，被攻击者几分钟就破解了。记住：永远不要自己实现密码学算法，用成熟的库（OpenSSL、Bouncy Castle、libsodium）。
另外，ECC的曲线参数一定要用标准曲线。自定义曲线十有八九有后门，或者安全性根本没经过验证。
非对称加密这块，RSA和ECC各有千秋。RSA成熟稳定，ECC高效前沿。我的建议是：新项目直接上ECC，别犹豫。但如果你要对接银行、政务这些老系统，RSA还是绕不开的。两种都掌握，才是合格的架构师。