2. 对称加密与非对称加密基础

加密这事儿，说白了就是两派天下。

一派是“对称加密”，快、简单、粗暴；另一派是“非对称加密”，慢、安全、优雅。

咱们在做参数配置、决定并发性能的时候，选哪一派，差别非常大。

为什么这么说？我早年踩过坑，后面慢慢聊。

2.1 加密的简单分类

先看一个全局框架，把这两兄弟的关系理清。

对称加密 vs 非对称加密 知识体系 对称加密 同一把密钥 速度快 算法：AES, DES, 3DES, ChaCha20 ▸ 加密/解密都用同一把钥匙 ▸ 适合大批量数据 ▸ 密钥分发是大麻烦 非对称加密 公私钥对 速度慢 算法：RSA, ECC, SM2, DSA ▸ 公钥加密、私钥解密 ▸ 适合少量数据、签名 ▸ 密钥分发简单、安全 混合加密：对称 + 非对称
核心结论：对称加密搞定“速度”，非对称加密搞定“安全分发”。你在工程化设计时，这两个往往是组合使用的。

2.2 对称加密：快，但钥匙怎么给？

对称加密的原理很简单：加密和解密用的是同一把密钥。

你想想看，就好像你往家里装了一把锁，自己留一把钥匙。你老婆也得有一把同样的钥匙，才能进门。钥匙怎么给她？直接递？万一路上被人复制了呢？

这就是对称加密的痛点。

常见对称算法

算法密钥长度分组大小特点
AES (高级加密标准)128/192/256 位128 位当今最主流，硬件加速支持好
DES (数据加密标准)56 位64 位已不安全，不再使用
3DES112/168 位64 位兼容老系统，性能差
SM4 (国密)128 位128 位中国国家标准，国内合规必选
ChaCha20256 位流密码无硬件加速时比AES快，移动端友好

我个人习惯，项目里只要允许，首选 AES-256-GCM。GCM 模式自带认证，能防篡改。嗯，这里要注意：别用 ECB 模式，那是给新手挖的坑。

实战技巧：对称加密速度极快，AES-256 在主流 CPU 上能达到 1GB/s+ 的吞吐。所以大量数据传输的场景，别无脑选非对称。

代码示例：AES-256-GCM 加密/解密

// Node.js 示例，使用 crypto 模块
const crypto = require('crypto');

const secretKey = crypto.randomBytes(32); // 256 位密钥
const iv = crypto.randomBytes(12); // 12 字节 IV

function encrypt(plaintext) {
    const cipher = crypto.createCipheriv('aes-256-gcm', secretKey, iv);
    let encrypted = cipher.update(plaintext, 'utf8', 'hex');
    encrypted += cipher.final('hex');
    const authTag = cipher.getAuthTag().toString('hex');
    return { encrypted, authTag, iv: iv.toString('hex') };
}

function decrypt(encrypted, authTag, ivHex) {
    const decipher = crypto.createDecipheriv(
        'aes-256-gcm',
        secretKey,
        Buffer.from(ivHex, 'hex')
    );
    decipher.setAuthTag(Buffer.from(authTag, 'hex'));
    let decrypted = decipher.update(encrypted, 'hex', 'utf8');
    decrypted += decipher.final('utf8');
    return decrypted;
}

// 使用
const result = encrypt('Hello, 我是敏感数据');
console.log(result);
// 记得安全保存 secretKey！
避坑提醒：我曾经接手过一个老项目，密钥写死在代码里，然后整个代码库放在 Git 上。我劝你一句：密钥永远不要硬编码。用密钥管理服务（KMS）或者环境变量注入。

2.3 非对称加密：慢，但分发不是问题

非对称加密解决了对称加密的“钥匙分发”难题。

它用了两把钥匙：一把公钥（公开），一把私钥（私密）。公钥加密的数据，只有私钥能解开。你完全可以把公钥贴在公司官网、发在邮件里，都不怕。

不过代价是什么？速度。

常见非对称算法

算法密钥长度安全强度（等效对称密钥）适用场景
RSA2048 / 4096 位112 / 128 位数字签名、密钥交换
ECC (椭圆曲线)256 / 384 位128 / 192 位移动端、IoT、高并发
SM2 (国密)256 位128 位国内合规、替代RSA
DSA1024 / 2048 位80 / 112 位仅签名，不加密（已淘汰）

为什么说非对称慢？我举个例子：RSA 2048 位加密，每秒钟能处理的请求数，大概只有 AES 的千分之一。你想想看，如果用非对称去加密一个大文件，用户得等多久？

我记得有一次做一个即时通讯系统，最初所有消息都用 RSA 加密，结果服务端 CPU 直接飙到 80%。换成混合加密后，CPU 降到 15%。这就是教训。

非对称的核心机制：公钥与私钥

# OpenSSL 生成 RSA 密钥对
# 生成私钥
openssl genrsa -out private.pem 2048

# 提取公钥
openssl rsa -in private.pem -pubout -out public.pem

# 用公钥加密（只能加密少量数据，通常 ≤ 密钥长度/8 - 11 字节）
echo "session_key_123" | openssl rsautl -encrypt -pubin -inkey public.pem -out enc.bin

# 用私钥解密
openssl rsautl -decrypt -inkey private.pem -in enc.bin
注意：RSA 直接加密的数据量极其有限（2048 位密钥最多加密 245 字节）。所以非对称从来不是用来加密正文的，它只用来加密“对称密钥”或者做签名。

2.4 实战对比：你到底该用哪个？

我把关键维度拉一张表，你一看就明白。

对比维度对称加密非对称加密
密钥管理难，需要安全通道分发密钥易，公钥可公开
加密速度极快（硬件加速后 + 微秒级）慢（毫秒级，差3-4个数量级）
数据量限制无限制，适合大体积数据有限制，仅适合小数据
安全性基础密钥保密性私钥保密性 + 数学难题
典型用途数据加密传输、静态数据加密密钥交换、数字签名、身份认证
算法举例AES, ChaCha20, SM4RSA, ECC, SM2
我的建议：别二选一。真正的工程方案是“混合加密”——用非对称加密传输对称密钥，再用对称密钥加密大块数据。HTTPS 的 TLS 握手就是这么干的。

2.5 混合加密：最佳实践

咱们把这个流程串起来，看看混合加密怎么工作：

  1. 客户端生成一个临时对称密钥（比如 AES 256 位随机数）。
  2. 客户端用服务器的公钥（RSA或ECC）加密这个临时密钥。
  3. 服务器收到后，用自己的私钥解密，得到临时对称密钥。
  4. 双方现在有了一个共享的对称密钥，后面所有通信都用它加密。

这样既解决了密钥分发的安全性，又保证了后续通信的高吞吐。

说白了，非对称加密是“桥梁”，对称加密是“高速公路”。

重要提醒：临时对称密钥必须每次会话都重新生成！我曾经见过有人复用同一个对称密钥加密所有会话，那你的私钥就算再安全，整个系统也等于裸奔。每次握手生成新密钥，这是铁律。

2.6 小结：你得记住什么？

我不会列什么“首先其次再次”，我只说三件事：

  • 对称加密：快，但密钥分发麻烦。用在大量数据的加密上。
  • 非对称加密：慢，但密钥分发安全。用在加密密钥、签名、认证上。
  • 混合加密：取长补短，绝大多数生产系统的默认选择。

下次你做应用加密参数配置的时候，先问自己三个问题：数据量大不大？密钥怎么安全交换？性能瓶颈在哪？答案自然就出来了。

← 上一章 📖 返回目录 下一章 →