第四节 数据加密技术：对称加密、非对称加密、哈希与国密

加密这件事，说白了就是给数据上一把锁。你开门需要钥匙，解密也需要密钥。但不同的锁，开锁的逻辑完全不一样。我自己刚接触数据安全时，常被各种算法绕晕——AES、RSA、SHA-256，还有后来必须面对的国密。今天咱们把这些捋清楚。

本章核心逻辑：加密不是越复杂越好，而是场景匹配。传输用非对称，存储用对称，完整性校验用哈希，合规场景用国密。
数据加密技术全景结构 加密技术 对称加密 AES / DES / SM4 非对称加密 RSA / ECC / SM2 哈希算法 SHA-256 / SM3 国密算法 SM2/SM3/SM4 实际项目中往往混合使用：非对称加密传递对称密钥 对称加密加密数据，哈希做完整性校验

4.1 对称加密：一把钥匙开一把锁

对称加密，就是加密和解密用同一个密钥。你想想看，这就好比你和朋友共用一把家门钥匙，谁都能开，但钥匙不能丢。

我个人用得最多的对称加密是 AES（Advanced Encryption Standard）。它支持 128、192、256 位密钥。接口传输中，如果数据量大，我习惯用 AES-256-GCM 模式——自带认证，能检测数据是否被篡改。

经验之谈：我曾经把 AES 密钥硬编码在代码里，结果被安全审计打了个高危。切记密钥要独立管理，可以从 KMS 或配置文件加密存放，运行时解密加载。

AES 加密的 Python 示例（GCM 模式）：

from Crypto.Cipher import AES
from Crypto.Random import get_random_bytes

key = get_random_bytes(32)  # 256位密钥
cipher = AES.new(key, AES.MODE_GCM)
plaintext = b"这是敏感数据"
ciphertext, tag = cipher.encrypt_and_digest(plaintext)
# 存储 nonce、ciphertext、tag 用于解密

对称加密的优缺点其实很明显：

  • 优点：速度快，适合批量大数据加密。服务器之间通信常用。
  • 缺点：密钥分发难。A 和 B 通信前，怎么安全地把密钥传给对方？这是个鸡生蛋的问题。

4.2 非对称加密：公钥私钥分开

非对称加密解决了密钥分发问题。它有一对密钥——公钥公开，私钥自留。公钥加密的数据只有私钥能解开。反过来，私钥签名，公钥验证身份。

RSA 是最经典的非对称算法。我平时在接口签名验证里经常用。比如支付回调，服务端用私钥签名，客户端用公钥验签，防止伪造请求。

注意：RSA 加密有长度限制——密钥长度 2048 位时，一次最多加密 245 字节。别拿它直接加密大文件，那是找死。实际做法是：用 RSA 加密 AES 密钥，再用 AES 加密数据。

RSA 验签的 Java 示例：

import java.security.*;
import java.util.Base64;

// 公钥验签
Signature sig = Signature.getInstance("SHA256withRSA");
sig.initVerify(publicKey);
sig.update(data.getBytes());
boolean verified = sig.verify(Base64.getDecoder().decode(signature));

4.3 哈希算法：不是为了加密，而是为了“对指纹”

哈希算法不是加密——它是单向的。你输入任意长度数据，它输出固定长度的摘要。你不能凭摘要还原原文。这就是为什么密码存储要用哈希，而不是加密。

SHA-256 是当前主流哈希算法。我做过一个数据完整性校验系统：上传文件时计算 SHA-256，下载时再算一遍，对比一致则文件未被篡改。

核心区别：
  • 加密：可逆，有密钥就能还原明文。
  • 哈希：不可逆，用于校验完整性、存储密码、生成消息摘要。

实际存储密码时，别直接用 SHA-256，要用加盐的 bcrypt 或 PBKDF2。我曾经见过一个项目直接用 MD5 存密码——几乎等于明文。

4.4 国密算法：国内的必修课

如果你做政企项目、金融、关基系统，国密是绕不开的硬性要求。国家密码管理局发布了 SM 系列算法：

算法 类型 对标国际 常见用途
SM2 非对称加密 ECC（椭圆曲线） 密钥交换、数字签名
SM3 哈希算法 SHA-256 完整性校验、数字签名
SM4 对称加密 AES 数据加密，分组长度为128位

这三个算法在国密生态里经常组合使用。我做过一个接口安全改造：通信先用 SM2 交换 SM4 密钥，之后数据传输用 SM4 加密，消息加 SM3 摘要。方案过审时，审计问了一句“参数转义做了吗？”——嗯，细节决定成败。

避坑指南：国密算法的库不如 OpenSSL 成熟。我在项目中用过 Bouncy Castle 的国密扩展，但注意版本兼容性——某些旧版 SM2 签名 R、S 的顺序可能与标准不一致，验签前要确认。

4.5 混合加密：实际项目中的正确姿势

你不会在真实系统里只用一种加密。看看最典型的 HTTPS：

  1. 客户端用服务器公钥（非对称）加密一个临时生成的对称密钥。
  2. 服务器用私钥解密得到对称密钥。
  3. 之后双方用对称密钥加密通信内容。

这就是混合加密。非对称负责安全传递密钥，对称负责高效加密数据。我在接口设计中也是这个思路：支付敏感字段用对称加密，但对称密钥用非对称加密传输。

一句话总结：
  • AES —— 快，适合加密内容。
  • RSA —— 慢，适合加密“密钥”和签名。
  • SHA-256 —— 不可逆，适合校验、指纹、密码存储。
  • 国密 —— 合规场景，用法与国际算法一一对应。

最后提醒一句：永远不要自己设计加密协议。我刚开始工作时写过一套“自创”加解密流程，漏洞百出，幸好没上线。用标准库、标准模式、标准做法的组合，才是最安全的。

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