加密-互联网安全的基石
加密是互联网安全的基石。无论是你登录网站、刷银行卡，还是两个服务之间传数据，背后都离不开加密技术。本文用大白话讲清楚：对称加密、非对称加密、哈希摘要的区别，以及 HTTPS、JWT、SSO 这些实际场景中的加解密是怎么玩的。
1. 加密到底是什么：先讲个故事
想象你要给朋友寄一封情书，但又怕被别人看到。你和朋友约定了一个暗号：把每个字母往后挪 3 位。比如 A → D，B → E，HELLO 就变成 KHOOR。
- 原文：你想说的话（HELLO）
- 密文：加密后的乱码（KHOOR）
- 密钥：约定的规则（往后挪 3 位）
- 加密：用规则把原文变成乱码
- 解密：用规则把乱码还原成原文
这就是加密的本质：让没有密钥的人看不懂内容。
2. 对称加密：一把钥匙开一把锁
2.1 什么是对称加密
大白话：你和朋友用同一把钥匙，你用它锁门（加密），朋友也用它开门（解密）。
graph LR
A[原文: HELLO] -->|密钥 K| B[加密算法]
B --> C[密文: Xk9@#]
C -->|同一个密钥 K| D[解密算法]
D --> E[原文: HELLO]
style A fill:#fecaca,stroke:#ef4444
style C fill:#fef3c7,stroke:#f59e0b
style E fill:#d1fae5,stroke:#10b981
2.2 常见的对称加密算法
| 算法 | 密钥长度 | 安全性 | 使用场景 |
|---|---|---|---|
| AES | 128/192/256 位 | 极高（目前无法破解） | HTTPS 数据传输、文件加密、数据库加密 |
| DES | 56 位 | 低（已被淘汰） | 历史遗留系统 |
| 3DES | 112/168 位 | 中等 | 金融行业（逐步被 AES 替代） |
| ChaCha20 | 256 位 | 极高 | 移动端（比 AES 更省电） |
2.3 对称加密的优缺点
优点
- 速度快：加解密效率高，适合大数据量
- 算法成熟：AES 经过多年验证，安全可靠
致命问题
密钥怎么给对方？如果你们从没见过面，怎么安全地把钥匙交给对方？
- 网络传输？万一被截获，对方就能解密所有内容
- 线下交换？成本太高，不现实
这就是对称加密的密钥分发难题，也是非对称加密要解决的问题。
3. 非对称加密：两把钥匙配合用
3.1 什么是非对称加密
大白话：你有两把钥匙——公钥（可以公开）和私钥（绝对保密）。它们是一对，用公钥锁的东西，只有私钥能开。
graph LR
subgraph 发送方
A[原文] -->|用对方的公钥| B[加密]
end
B --> C[密文]
subgraph 接收方
C -->|用自己的私钥| D[解密]
D --> E[原文]
end
style A fill:#fecaca,stroke:#ef4444
style C fill:#fef3c7,stroke:#f59e0b
style E fill:#d1fae5,stroke:#10b981
3.2 公钥和私钥的关系
| 特性 | 公钥（Public Key） | 私钥（Private Key） |
|---|---|---|
| 谁持有 | 任何人都可以有 | 只有自己持有，绝对保密 |
| 用途 1 | 加密数据（发给私钥持有者） | 解密数据 |
| 用途 2 | 验证签名 | 生成签名（证明身份） |
| 类比 | 邮箱地址（公开的） | 邮箱密码（只有你知道） |
3.3 常见的非对称加密算法
| 算法 | 密钥长度 | 特点 | 使用场景 |
|---|---|---|---|
| RSA | 2048/4096 位 | 应用最广，兼容性好 | HTTPS 证书、SSH 密钥、数字签名 |
| ECC（椭圆曲线） | 256 位（等效 RSA 3072 位） | 密钥短、效率高 | 移动端、物联网、区块链 |
| Ed25519 | 256 位 | 签名速度快 | SSH 密钥、API 签名 |
3.4 非对称加密解决了什么问题
密钥分发问题完美解决
你把公钥贴在网上，任何人都能用它给你加密信息。但只有你有私钥，只有你能解密。
全程不需要交换私钥，黑客截获公钥也没用，因为公钥只能加密不能解密。
缺点
- 速度慢：比对称加密慢 100-1000 倍
- 不适合大数据：通常只用来加密"密钥"或"签名"
4. 哈希/摘要：不可逆的"指纹"
4.1 什么是哈希
大白话：把任意长度的数据，压缩成固定长度的"指纹"。这个过程不可逆——你无法从指纹还原出原文。
graph LR
A["任意长度数据
（1KB 或 1GB）"] --> B["哈希算法
（SHA-256）"] B --> C["固定长度指纹
（256 位 / 32 字节）"] style A fill:#fecaca,stroke:#ef4444 style C fill:#d1fae5,stroke:#10b981
（1KB 或 1GB）"] --> B["哈希算法
（SHA-256）"] B --> C["固定长度指纹
（256 位 / 32 字节）"] style A fill:#fecaca,stroke:#ef4444 style C fill:#d1fae5,stroke:#10b981
4.2 哈希的特性
| 特性 | 说明 | 大白话 |
|---|---|---|
| 固定长度 | 无论输入多大，输出长度固定 | 1KB 文件和 1GB 文件，指纹都是 32 字节 |
| 不可逆 | 无法从哈希值还原原文 | 知道指纹，推不出是谁的 |
| 雪崩效应 | 原文改一点，哈希值完全不同 | 改一个字，指纹面目全非 |
| 抗碰撞 | 几乎不可能找到两个不同输入有相同哈希 | 不同的人，指纹不会一样 |
4.3 常见哈希算法
| 算法 | 输出长度 | 安全性 | 使用场景 |
|---|---|---|---|
| MD5 | 128 位 | 已破解，不安全 | 仅用于文件校验（非安全场景） |
| SHA-1 | 160 位 | 已破解，不推荐 | 历史遗留 |
| SHA-256 | 256 位 | 安全 | JWT 签名、区块链、密码存储 |
| bcrypt | 可变 | 专为密码设计 | 用户密码存储（有盐值、慢哈希） |
4.4 哈希的典型用途
- 密码存储：数据库只存密码的哈希值，验证时比较哈希是否一致
- 文件校验：下载文件后算哈希，和官方公布的比对，确认没被篡改
- 数字签名：先对内容算哈希，再对哈希值加密（见下文）
5. 三种加密技术的对比
| 维度 | 对称加密 | 非对称加密 | 哈希/摘要 |
|---|---|---|---|
| 密钥数量 | 1 把（双方共享） | 2 把（公钥 + 私钥） | 无密钥 |
| 可逆性 | 可逆（能解密） | 可逆（能解密） | 不可逆 |
| 速度 | 快 | 慢（100-1000 倍） | 快 |
| 典型用途 | 大数据加密 | 密钥交换、数字签名 | 完整性校验、密码存储 |
| 代表算法 | AES、ChaCha20 | RSA、ECC | SHA-256、bcrypt |
核心理解
实际场景中，这三种技术通常配合使用：
- 非对称加密：交换对称密钥
- 对称加密：加密实际数据
- 哈希：保证数据完整性
6. HTTPS：三种加密的完美配合
当你访问 https:// 网站时，浏览器和服务器之间发生了什么？
6.1 HTTPS 握手流程（TLS 1.2）
sequenceDiagram
participant 浏览器
participant 服务器
Note over 浏览器,服务器: 1. 建立安全通道
浏览器->>服务器: ClientHello（支持的加密算法列表）
服务器->>浏览器: ServerHello（选定的算法）+ 证书（含公钥）
Note over 浏览器: 2. 验证证书真实性
浏览器->>浏览器: 用 CA 公钥验证服务器证书
Note over 浏览器,服务器: 3. 交换对称密钥
浏览器->>浏览器: 生成随机对称密钥（会话密钥）
浏览器->>服务器: 用服务器公钥加密会话密钥
服务器->>服务器: 用私钥解密，得到会话密钥
Note over 浏览器,服务器: 4. 使用对称加密通信
浏览器->>服务器: 用会话密钥加密数据
服务器->>浏览器: 用会话密钥加密响应
6.2 每个阶段用了什么加密
| 阶段 | 加密技术 | 具体作用 |
|---|---|---|
| 验证证书 | 非对称加密（RSA/ECC） | 用 CA 公钥验证服务器证书的签名 |
| 交换密钥 | 非对称加密（RSA/ECDHE） | 安全地把对称密钥传给服务器 |
| 传输数据 | 对称加密（AES/ChaCha20） | 加密实际的网页内容 |
| 完整性校验 | 哈希（SHA-256） | 确保数据没被篡改（MAC） |
为什么这么设计？
- 非对称加密解决"密钥怎么传"：用公钥加密对称密钥，安全传输
- 对称加密解决"传输效率"：速度快，适合大数据量
- 哈希解决"数据被篡改"：保证完整性
7. JWT Token：签名的典型应用
登录成功后，服务器给你一个 JWT Token，里面装着你的身份信息。但怎么防止有人伪造 Token？
7.1 JWT 的结构
eyJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOjEyMywiZXhwIjoxNzA5MDAwMDAwfQ.X7dKxY2Z9Q8w3V1mNpRqT5a6bC0fJWT 由三部分组成，用 . 分隔：
| 部分 | 内容 | 是否加密 |
|---|---|---|
| Header | 算法类型（如 HS256、RS256） | Base64 编码，不加密 |
| Payload | 用户数据（userId、过期时间等） | Base64 编码，不加密 |
| Signature | 签名 | 加密（保证前两部分没被篡改） |
7.2 签名是怎么生成的
graph LR
A[Header + Payload] --> B["哈希算法
（HMAC-SHA256）"] C[密钥] --> B B --> D[Signature 签名] style A fill:#fecaca,stroke:#ef4444 style C fill:#fef3c7,stroke:#f59e0b style D fill:#d1fae5,stroke:#10b981
（HMAC-SHA256）"] C[密钥] --> B B --> D[Signature 签名] style A fill:#fecaca,stroke:#ef4444 style C fill:#fef3c7,stroke:#f59e0b style D fill:#d1fae5,stroke:#10b981
// 签名生成过程
Signature = HMAC-SHA256(
base64(Header) + "." + base64(Payload),
密钥
)7.3 两种签名算法对比
| 算法 | 类型 | 密钥 | 适用场景 |
|---|---|---|---|
| HS256 | 对称加密 | 同一个密钥签名和验证 | 单体应用（后端自己签、自己验） |
| RS256 | 非对称加密 | 私钥签名、公钥验证 | 微服务/SSO（认证中心签、各服务验） |
JWT 的安全注意事项
- Payload 不加密：任何人都能 Base64 解码看到内容，不要放敏感信息（如密码）
- 签名只防篡改：别人能看，但改了就验签失败
- 必须用 HTTPS：防止 Token 被截获
8. SSO 单点登录：完整的加解密流程
SSO（Single Sign-On）让你只登录一次，就能访问多个系统（如登录淘宝后，自动登录天猫、支付宝）。
8.1 SSO 的核心角色
| 角色 | 说明 | 类比 |
|---|---|---|
| 认证中心（SSO Server） | 统一负责登录验证、签发令牌 | 公安局（发身份证） |
| 业务系统（Client） | 淘宝、天猫等具体应用 | 银行、酒店（验身份证） |
| 用户 | 你 | 你 |
8.2 SSO 登录流程（以 CAS 协议为例）
sequenceDiagram
participant 用户
participant 淘宝
participant 认证中心
participant 天猫
Note over 用户,天猫: 第一次访问淘宝
用户->>淘宝: 1. 访问淘宝
淘宝->>淘宝: 检查：没有登录态
淘宝->>用户: 2. 重定向到认证中心
用户->>认证中心: 3. 请求登录页
认证中心->>用户: 4. 返回登录页
用户->>认证中心: 5. 提交账号密码
Note over 认证中心: 6. 验证账号密码
哈希比对 认证中心->>认证中心: 7. 生成 ST（Service Ticket） Note over 认证中心: 用私钥签名 ST 认证中心->>用户: 8. 重定向回淘宝 + ST 用户->>淘宝: 9. 携带 ST 访问 淘宝->>认证中心: 10. 验证 ST Note over 认证中心: 用公钥验签 认证中心->>淘宝: 11. 返回用户信息 淘宝->>淘宝: 12. 创建本地会话 淘宝->>用户: 13. 登录成功 Note over 用户,天猫: 第二次访问天猫（已登录） 用户->>天猫: 14. 访问天猫 天猫->>天猫: 检查：没有本地登录态 天猫->>用户: 15. 重定向到认证中心 用户->>认证中心: 16. 请求（带全局会话 Cookie） 认证中心->>认证中心: 17. 已登录，直接签发 ST 认证中心->>用户: 18. 重定向回天猫 + ST 用户->>天猫: 19. 携带 ST 访问 天猫->>认证中心: 20. 验证 ST 认证中心->>天猫: 21. 返回用户信息 天猫->>用户: 22. 免登录成功
哈希比对 认证中心->>认证中心: 7. 生成 ST（Service Ticket） Note over 认证中心: 用私钥签名 ST 认证中心->>用户: 8. 重定向回淘宝 + ST 用户->>淘宝: 9. 携带 ST 访问 淘宝->>认证中心: 10. 验证 ST Note over 认证中心: 用公钥验签 认证中心->>淘宝: 11. 返回用户信息 淘宝->>淘宝: 12. 创建本地会话 淘宝->>用户: 13. 登录成功 Note over 用户,天猫: 第二次访问天猫（已登录） 用户->>天猫: 14. 访问天猫 天猫->>天猫: 检查：没有本地登录态 天猫->>用户: 15. 重定向到认证中心 用户->>认证中心: 16. 请求（带全局会话 Cookie） 认证中心->>认证中心: 17. 已登录，直接签发 ST 认证中心->>用户: 18. 重定向回天猫 + ST 用户->>天猫: 19. 携带 ST 访问 天猫->>认证中心: 20. 验证 ST 认证中心->>天猫: 21. 返回用户信息 天猫->>用户: 22. 免登录成功
8.3 SSO 中的加解密环节
| 环节 | 加密技术 | 具体说明 |
|---|---|---|
| 密码验证 | 哈希（bcrypt） | 数据库存的是密码哈希，登录时比对哈希值 |
| 令牌签发 | 非对称加密（RS256） | 认证中心用私钥签名 Token |
| 令牌验证 | 非对称加密 | 各业务系统用公钥验签 |
| 传输保护 | HTTPS（对称 + 非对称） | 防止令牌被截获 |
为什么 SSO 用非对称加密？
- 认证中心：持有私钥，负责签发令牌
- 各业务系统：只需要公钥，就能验证令牌
- 好处：业务系统无法伪造令牌（没有私钥），即使某个业务系统被攻破，也不会影响其他系统
9. 服务间通信的加密实践
在微服务架构中，服务 A 调用服务 B，怎么保证安全？
9.1 内网 vs 公网
| 场景 | 常见做法 | 说明 |
|---|---|---|
| 内网调用 | 可不加密，但建议 mTLS | 信任内网环境，但零信任架构建议加密 |
| 跨公网调用 | 必须 HTTPS + 身份认证 | 公网不可信，必须加密 + 验证身份 |
9.2 服务间身份认证方案
| 方案 | 原理 | 适用场景 |
|---|---|---|
| API Key | 固定密钥，放在请求头 | 简单场景、内部服务 |
| JWT Token | 签名令牌，包含调用方信息 | 微服务间调用 |
| mTLS（双向 TLS） | 客户端和服务端都验证证书 | 高安全场景（金融、政务） |
| OAuth 2.0 Client Credentials | 获取 Access Token 调用 | 第三方服务调用 |
9.3 mTLS 双向认证流程
sequenceDiagram
participant 服务A
participant 服务B
服务A->>服务B: 1. ClientHello
服务B->>服务A: 2. ServerHello + 服务B证书
服务B->>服务A: 3. 请求客户端证书
Note over 服务A: 验证服务B证书
服务A->>服务B: 4. 服务A证书 + 密钥交换
Note over 服务B: 验证服务A证书
服务A->>服务B: 5. 加密数据传输
服务B->>服务A: 6. 加密响应
mTLS 的优势
- 双向验证：不仅客户端验证服务端，服务端也验证客户端
- 证书管理：配合证书管理系统（如 Vault），可以自动轮换证书
- 零信任：符合"永不信任，始终验证"的安全理念
10. 总结：加密技术选型指南
| 场景 | 推荐技术 | 说明 |
|---|---|---|
| 用户密码存储 | bcrypt / Argon2 | 专为密码设计的慢哈希 + 盐值 |
| 数据传输加密 | HTTPS（TLS 1.3） | 对称 + 非对称 + 哈希组合 |
| API 身份认证 | JWT（RS256） | 非对称签名，公钥验证 |
| 文件完整性校验 | SHA-256 | 计算哈希，比对确认 |
| 大数据加密存储 | AES-256-GCM | 对称加密，带认证标签 |
| 服务间安全通信 | mTLS + JWT | 传输层加密 + 应用层身份 |
安全红线
- 不要自己造加密算法：用成熟的库（OpenSSL、libsodium）
- 不要硬编码密钥：用密钥管理服务（Vault、KMS）
- 不要用 MD5/SHA1 做安全用途：已被破解
- 不要明文存储密码：必须用慢哈希 + 盐值
- 不要忽略证书过期：配置自动续期