关于加密算法

概述

“加密”这个词在日常开发里经常被说得很宽，宽到什么都能往里塞：散列、签名、证书、编码、压缩，有时甚至 Base64 也会被误叫成加密。这样一来，术语一乱，代码里的设计也容易乱。

更稳妥的做法，是先分清每种技术到底解决什么问题。加密主要解决保密性，散列主要解决内容摘要，数字签名主要解决完整性和身份认证。这些能力都属于密码学工具箱，但不是同一把锤子。

加密到底在解决什么

加密的核心目标，是让不该看见数据的人看不懂内容。

最常见的使用场景包括：

• 网络传输时保护明文
• 数据落盘时保护敏感信息
• 密钥交换时避免中间人直接看到会话密钥

如果一个方案只能“验证有没有被改过”，却不能隐藏内容，那它不叫加密；如果它只能“变成另一种表示方式”，例如十六进制或 Base64，那也不叫加密。

对称加密

对称加密使用同一把密钥完成加密和解密。

明文 --加密(key)--> 密文 --解密(key)--> 明文

它的特点很直接：

• 速度快，适合大量数据
• 算法实现成熟，硬件加速普遍
• 难点不在算法本身，而在密钥怎么安全分发

常见算法有：

• AES
• ChaCha20
• 早期的 DES、3DES 已不建议继续使用

在 HTTPS、磁盘加密、数据库透明加密里，真正负责大批量数据加解密的，通常都是对称加密。非对称算法负责把钥匙递过去，对称算法负责真正干活。

非对称加密

非对称加密使用一对相关联的密钥：公钥和私钥。

• 公钥可以公开
• 私钥必须保密

常见说法是：

• 用公钥加密，私钥解密
• 用私钥签名，公钥验证

这组密钥并不是任意两把钥匙，而是数学上成对生成的。拿错一把，解不开，也验不过。

常见算法有：

• RSA
• ECC
• SM2

非对称算法的优势是便于密钥分发，劣势是速度慢、负载高，所以通常不直接拿来加密大块数据。

为什么实际系统会混合使用

真实系统里，对称和非对称通常一起上。

以 TLS 为例，常见流程大致是：

1. 服务端先提供公钥相关材料，通常放在证书里。
2. 客户端验证证书可信后，协商出一把会话密钥。
3. 后续大部分业务数据用对称加密传输。

这样做的原因很现实：

• 非对称算法适合建立信任和交换密钥
• 对称算法适合高效传输数据

两者各干自己擅长的事，系统性能和安全性都更平衡。

加密、散列、签名不要混说

这几个词很容易一起出现，但职责不同：

名称	主要目标	能否恢复原文	常见用途
加密	保密性	可以，前提是有正确密钥	传输和存储保护
散列	生成摘要	不可以	完整性校验、索引、去重
数字签名	身份认证和完整性	不是恢复原文的问题	证明“谁签的”以及“内容没被改”

例如：

• 给接口报文做 SHA-256，这叫散列，不叫加密。
• 给报文再附一个私钥签名，这叫签名，不叫加密。
• 把报文内容用 AES 变成密文，才叫加密。

代码里常见术语

很多项目里函数名和配置名都混着英文缩写出现，先认清这几个词，读代码会轻松很多。

crypto

crypto 通常泛指密码学相关能力，是个总称。库里叫 crypto，不代表它只做加密，也可能同时包含散列、签名、证书解析和随机数生成。

cipher

cipher 更接近“密码算法”或“加密套件”，常用于表示某种具体加密算法，比如 AES-256-GCM。

encrypt / decrypt

• encrypt：加密
• decrypt：解密

这对动作只和“把明文变密文，再还原回来”有关。

digest / hash

• digest：摘要值
• hash：散列计算

它们通常描述的是“输入一段数据，得到固定长度结果”。

sign / verify

• sign：签名
• verify：验签

签名关注的是“这份内容是不是持有私钥的人发出来的”，以及内容在途中有没有被改。

选型时先看目标

技术选型前，先问自己想解决哪类问题：

• 要防止别人看到内容，用加密。
• 要快速判断内容是否变化，用散列。
• 要证明发送者身份并防篡改，用数字签名。
• 要保存密码，不要直接“加密存密码”，而要用专门的口令散列方案，例如 bcrypt、scrypt、Argon2。

术语对了，设计通常就不容易歪。很多安全问题的起点，并不是算法太弱，而是需求本身说错了。