你在网上输密码、刷银行卡、连 Wi-Fi，背后都有密码学在默默保护：保证”只有该看的人能看""数据没被篡改""对方真是他本人”。但密码学常被妖魔化——有人觉得”加密就是加个密”，有人觉得”有 HTTPS 就万事大吉”。
这一篇我们拆开密码学的三大基石，搞清楚每种技术到底解决什么问题，不再混用。
先明确：密码学解决哪几件事
信息安全三目标（CIA）：
- 保密性（Confidentiality）：内容不被不该看的人看到 → 靠加密。
- 完整性（Integrity）：内容没被篡改 → 靠哈希/签名。
- 真实性（Authentication）：对方真是他声称的人/来源 → 靠签名/证书。
三大基石各管一摊：对称加密管保密、非对称加密管密钥分发与签名、哈希管完整性。下面逐个看。
基石一：对称加密（Symmetric）
对称加密就是加密和解密用同一把密钥（像一把锁的钥匙，锁门开门都用它）。代表算法：AES、DES（已淘汰）、3DES。
明文 + 密钥 ──加密──▶ 密文
密文 + 密钥 ──解密──▶ 明文优点：快，适合加密大量数据（如整个文件、数据库）。缺点：密钥分发难——你怎么把同一把密钥安全传给对方？如果通过网络发密钥，密钥被截获，加密就白费了。这就是”密钥分发问题”。
典型用途：加密本地文件、HTTPS 里真正传输数据用的就是对称密钥（会话密钥）。
基石二：非对称加密（Asymmetric）
非对称加密用一对密钥：公钥（公开）和私钥（保密）。用公钥加密，只能用私钥解密；反过来，用私钥”签名”，公钥能验证签名来自私钥持有者。
代表算法：RSA、ECC（椭圆曲线，更短密钥更强）。
A 用 B 的公钥加密 ──▶ 密文 ──▶ B 用自己私钥解密它完美解决了对称加密的”密钥分发难”：公钥随便公开，谁都能用它加密发给 B，只有 B 的私钥能解开。而且私钥还能做数字签名——B 用私钥对数据签名，任何人用 B 的公钥验证，确认”这数据确实是 B 发的且没被改”。
优点：解决密钥分发、能签名。缺点：慢，不适合加密大量数据。所以实战里它常和对称加密配合（下一节）。
基石三：哈希函数（Hash）
哈希不是加密，而是把任意长度输入”压缩”成固定长度的摘要（指纹）。代表：MD5（已破）、SHA-1（已破）、SHA-256、SHA-3。
"转账100元" ──SHA256──▶ 摘要(固定64位十六进制)哈希的关键特性：
- 单向：从摘要无法反推原文（所以叫”摘要”不是”密文”）。
- 雪崩效应：原文改一个字，摘要天差地别。
- 抗碰撞：很难找到两段不同原文得到相同摘要。
用途：验证完整性（下载文件后比对哈希看是否被篡改）、存密码（存哈希不存明文）、数字签名（对摘要签名而非对全文）。
三者怎么配合：一次安全通信
真实场景（如 HTTPS）是三者的合奏：
- 非对称加密解决”怎么安全交换密钥”：客户端用服务器公钥，加密一个对称会话密钥发过去。
- 对称加密接管后续：双方用这个会话密钥加密真正传输的大量数据（因为快）。
- 哈希保证完整：传输内容算摘要，任何篡改都会被察觉。
- 数字签名/证书证明”服务器公钥真是这家公司的”（防中间人冒充）。
这就是”用非对称安全地发对称密钥，再用对称加密干活”的经典组合——兼顾安全与性能。
常见认知误区
- “哈希就是加密，能解密”：错。哈希单向不可逆，用来验证而非还原。把哈希当加密存密码，撞库时明文就暴露。
- “对称比非对称安全/不安全”：安全性取决于密钥管理和算法强度，不是类型。两者用途不同，互补而非替代。
- “MD5/SHA1 还能用”：已被攻破（可人为制造碰撞），新系统禁用，用 SHA-256 及以上。
- “有 HTTPS 就绝对安全”：HTTPS 只保护传输过程，不防服务端本身漏洞、钓鱼网站、或证书被篡改。它不是万能盾。
- “自己发明加密算法更牛”：大忌。密码学算法要经过全球多年攻防验证，自创算法几乎必破，用标准算法（AES/RSA/SHA-256）即可。
分组加密模式：同样的算法也有坑
对称加密（如 AES）不是”一把数据丢进去就完事”，还要选加密模式和初始向量 IV：
- ECB（电子密码本）：把明文分块独立加密。致命缺陷：相同的明文块加密后密文也相同，攻击者能从密文图案反推结构（ famously，用 ECB 加密的 Linux 企鹅图，加密后还能看出轮廓）。绝对不要用 ECB。
- CBC（密码块链）：每个明文块与前一个密文块异或再加密，链起来，相同明文也不再相同。需要随机 IV（IV 不用保密，但要随机且不可预测）。
- GCM（伽罗瓦/计数器模式）：现代首选，不仅加密还自带完整性校验（认证），能发现密文被篡改。AES-GCM 是当前行业标准。
经验：用 AES-256-GCM，别碰 ECB，CBC 也要配随机 IV。很多”加密了却被破解”的案例，问题不在算法，而在模式/IV/密钥管理。
随机数：密码学的”隐形地基”
密码学里大量环节依赖密码学安全的随机数（盐、IV、密钥、nonce 都靠它）。如果用普通伪随机（如 rand()、没播种好的 Math.random），攻击者可能预测出来，整个安全崩塌。
- 盐、IV、密钥：必须用 CSPRNG（密码学安全伪随机数生成器），如 Node 的
crypto.randomBytes、Python 的secrets模块、Linux 的/dev/urandom。 - 切勿用时间戳、自增 ID、可预测种子当随机源。
一句话：算法再强，随机数弱了也白搭。
密钥长度与算法选择速查
强度取决于”算法 + 密钥长度 + 实现正确”。当前（2026）务实建议：
| 用途 | 推荐 | 备注 |
|---|---|---|
| 对称加密 | AES-256-GCM | 128 位也够，256 更稳 |
| 非对称加密/签名 | RSA-2048 以上 或 ECC P-256 | ECC 更短更强更快 |
| 哈希 | SHA-256 / SHA-3 | 禁用 MD5、SHA-1 |
| 口令哈希 | Argon2id / bcrypt | 见下篇 |
| 密钥交换 | ECDHE | 提供前向安全 |
**前向安全（Forward Secrecy）**值得记住：用临时密钥（ECDHE）协商，即使长期私钥日后泄露，历史通信记录也无法被解密——因为每次会话的对称密钥都不同且已丢弃。这是现代 TLS 的标配。
一个常见实现误区：自己拼密码学
新手最爱犯两类错：一是”用 base64 编码当加密”（base64 只是编码，谁都能解，不是加密）；二是”自己 XOR/移位当加密”（几行代码秒破）。编码 ≠ 加密，混淆 ≠ 密码学。真正要用加密时，调用标准库的高层 API（如 Node crypto、Python cryptography），用 AES-GCM 这类经过审计的组合，别手写底层原语。
小测验：看看你掌握了没
- 问题一：对称和非对称加密最大区别？答案：对称加解密同密钥（快、难分发），非对称用公钥+私钥对（解决分发、能签名、慢）。
- 问题二：哈希能解密还原原文吗？答案：不能，哈希单向不可逆，用于完整性验证而非保密。
- 问题三：HTTPS 为什么混用两种加密？答案：非对称安全交换对称会话密钥，对称加密后续大量数据，兼顾安全与性能。
这一篇你该记住的
- 三大基石：对称加密（保密、快、密钥分发难）、非对称（密钥分发+签名、慢）、哈希（完整性、单向不可逆）。
- 对称用 AES，非对称用 RSA/ECC，哈希用 SHA-256+，禁用 MD5/SHA1。
- 哈希非加密、不可还原；用于校验、存密码、签名摘要。
- 实战组合：非对称交换对称密钥 → 对称加密数据 → 哈希保完整 → 签名/证书证身份。
- 误区：哈希≠加密、HTTPS 非万能、别自创算法。
下一篇我们深入最常用的”存密码”场景：哈希加盐与口令安全，搞清楚为什么”md5(密码)“是最危险的写法。