3. 加密算法基础：对称加密与非对称加密、哈希算法、数字签名原理、密钥长度与安全强度
说实话，很多做运维的兄弟一听到「加密算法」四个字就头大。觉得那是密码学家的事，跟自己没关系。
但你想过没有？你配 HTTPS 证书时选的 RSA 2048 还是 ECDSA P-256，背后就是加密算法的选择。你写脚本时用的 SHA-256 还是 MD5，直接决定了你的签名安不安全。
这一章，我把这些概念掰开揉碎了讲。不扯数学公式，只讲你配置证书时真正需要知道的东西。
3.1 对称加密：快，但有个麻烦
对称加密，说白了就是「一把钥匙开一把锁」。加密和解密用同一个密钥。
我最早接触对称加密是在做数据库备份加密的时候。当时用 AES-256 加密备份文件，速度确实快，几 GB 的文件几分钟就搞定了。
常见对称加密算法：
- AES（Advanced Encryption Standard）—— 目前最主流，密钥长度 128/192/256 位
- DES（Data Encryption Standard）—— 太老了，56 位密钥，现在一台普通电脑几小时就能暴力破解
- 3DES —— DES 的加强版，但效率低，已经不推荐了
- SM4 —— 国密标准，国内项目经常遇到
对称加密最大的问题是什么？密钥分发。你想想看，如果我和你要用同一个密钥加密通信，我怎么安全地把密钥给你？邮寄？快递？发？都不靠谱。
这就是非对称加密要解决的问题。
3.2 非对称加密：公钥私钥，各司其职
非对称加密有一对密钥：公钥和私钥。公钥可以公开，私钥必须保密。
用公钥加密的数据，只有对应的私钥能解密。反过来，用私钥签名的数据，任何人都可以用公钥验证签名。
我的经验：刚开始接触非对称加密时，我总搞混「公钥加密、私钥解密」和「私钥签名、公钥验签」这两组关系。后来我给自己编了个口诀：「加密用公钥，解密用私钥；签名用私钥，验签用公钥」。你记牢这个，后面配证书时就不会晕。
常见的非对称加密算法：
| 算法 | 密钥长度 | 特点 | 应用场景 |
|---|---|---|---|
| RSA | 1024 / 2048 / 4096 | 最广泛，兼容性好 | HTTPS 证书、SSH 密钥 |
| ECDSA | P-256 / P-384 / P-521 | 密钥短，性能好 | 现代 TLS 证书、区块链 |
| SM2 | 256 位 | 国密标准 | 国内政务、金融系统 |
| DSA | 1024 / 2048 | 仅用于签名 | 已逐渐被 ECDSA 取代 |
⚠️ 避坑指南：我曾经接手过一个项目，对方用了 RSA 1024 位的证书。当时 Chrome 已经报「不安全」了，但业务方觉得「能用就行」。我花了整整一周说服他们升级到 2048 位。结果呢？升级后第三天，安全扫描就发现了一个利用 1024 位弱密钥的中间人攻击尝试。嗯，有时候「能用」和「安全」之间，差的就是一次攻击的距离。
3.3 哈希算法：不可逆的「指纹」
哈希算法，也叫散列算法。它的特点是：输入任意长度的数据，输出固定长度的「摘要」。而且这个过程不可逆——你无法从摘要反推出原始数据。
我经常把哈希比作「数字指纹」。就像每个人的指纹是独一无二的，每个文件的哈希值也是唯一的。哪怕你只改了一个字节，哈希值就会完全不一样。
常见的哈希算法：
- MD5 —— 128 位输出，已经被攻破，别再用了
- SHA-1 —— 160 位输出，2017 年 Google 已经演示了碰撞攻击，淘汰
- SHA-256 —— 256 位输出，目前最推荐
- SHA-3 —— 新一代标准，兼容性还在普及中
- SM3 —— 国密哈希算法，256 位输出
哈希算法的典型用途：
- 文件完整性校验 —— 下载 ISO 镜像后，对比官方提供的 SHA-256 值
- 密码存储 —— 数据库里存的是密码的哈希值，不是明文
- 数字签名 —— 先对内容做哈希，再对哈希值签名，提高效率
- 证书指纹 —— 浏览器用哈希值验证证书的唯一性
3.4 数字签名原理：签名与验签
数字签名，本质上就是「用私钥对哈希值加密」。为什么不是对整个文件加密？因为非对称加密太慢了。你想想看，一个 100MB 的文件用 RSA 加密，得等到天荒地老。
所以实际流程是这样的：
- 发送方对文件做哈希，得到摘要
- 发送方用自己的私钥对摘要加密，生成数字签名
- 接收方用发送方的公钥解密签名，得到摘要 A
- 接收方对收到的文件做哈希，得到摘要 B
- 对比 A 和 B，一致则文件未被篡改
这就是 HTTPS 证书验证的核心逻辑。你浏览器访问一个网站时，服务器会发来它的证书，里面包含了服务器的公钥和 CA 的数字签名。浏览器用 CA 的公钥验证这个签名，确认证书是真实的。
我的习惯：每次配置完证书，我都会用 OpenSSL 手动验证一遍签名链。命令很简单：openssl verify -CAfile ca.crt server.crt。别嫌麻烦，我曾经就因为 CA 证书链没配全，导致线上服务 TLS 握手失败，排查了整整两个小时。从那以后，验证签名链成了我配置证书的「肌肉记忆」。
3.5 密钥长度与安全强度
密钥长度越长，暴力破解的难度就越大。但也不是越长越好——密钥越长，加解密性能就越差。
我整理了一个对照表，方便你选型时参考：
| 安全等级 | 对称加密 | 非对称加密 (RSA) | 非对称加密 (ECDSA) | 哈希算法 |
|---|---|---|---|---|
| 弱（不推荐） | DES (56位) | RSA 1024 | - | MD5, SHA-1 |
| 中（过渡期） | 3DES | RSA 2048 | P-256 | SHA-256 |
| 强（推荐） | AES-256 | RSA 4096 | P-384 | SHA-384 / SHA-512 |
| 超强（未来） | AES-256 | RSA 8192 | P-521 | SHA-3 |
⚠️ 注意：别盲目追求超长密钥。RSA 4096 比 2048 安全，但 TLS 握手时间可能增加 3-5 倍。对于大多数 Web 场景，RSA 2048 或 ECDSA P-256 已经足够。我见过有人给一个内部 API 网关配了 RSA 8192 的证书，结果每次握手要等 2 秒，业务方直接投诉「系统变慢了」。说白了，安全要和性能做 trade-off。
3.6 知识体系总览
下面这张图，把这一章的核心知识点串起来了。你保存下来，以后配证书时对照着看，思路会清晰很多。
这张图把对称加密、非对称加密、哈希算法和数字签名串在了一起。你仔细看中间的「数字签名流程」部分——这就是 HTTPS 证书验证的底层逻辑。理解了它，后面配证书时你就能明白每一步在做什么。
最后说一句：加密算法这东西，不需要你记住所有数学原理。但你要知道：什么场景用什么算法，什么密钥长度是安全的，什么算法已经淘汰了。这些知识，会在你配置证书、排查 TLS 问题、做安全审计时，一遍又一遍地用到。