第2章 加密技术基础：对称加密、非对称加密、哈希算法

说实话，很多初学者一听到「加密」两个字就头大。总觉得这是密码学专家才需要搞懂的事。其实不然。你只需要理解三个核心概念——对称加密、非对称加密、哈希算法。搞懂它们，你就能应付 90% 的日常开发场景。

我刚开始接触对象存储时，也踩过不少坑。有一次客户数据上传后，发现存储桶里全是明文。虽然内网用着没事，但合规审查那关死活过不去。嗯，从那以后，我养成了「先加密，再上传」的习惯。

2.1 为什么需要加密？

我们还是先说清楚这个根本问题。你想想看，数据在传输和存储过程中，到底面临哪些风险？

• 窃听：网络链路就像一根水管，谁都能接个监听器。
• 篡改：中间人可以在你眼皮底下改数据。
• 泄露：存储服务器被拖库，明文数据直接暴露。
• 抵赖：用户可以说「我没上传过这个文件」。

加密解决的不光是「防止偷看」这一个问题。它还解决「完整性验证」和「身份认证」——说白了，就是让别人既看不懂你的数据，也改不了你的数据，更没法冒充你。

2.2 对称加密：又快又简单

对称加密，顾名思义，加密和解密用的是同一把钥匙。就像你家里的大门，用一把钥匙锁门，也用同一把钥匙开门。

常见的对称加密算法：

对称加密最大的优点就是快。我在项目中加密一个 1GB 的大文件，用 AES-256-GCM 模式，基本能跑满磁盘 IO 的吞吐量。相比之下，非对称加密会慢好几个数量级。

但对称加密有个致命弱点——密钥分发。加密方和解密方怎么安全地拿到同一把钥匙？总不能直接发微信吧？这就是非对称加密要解决的问题。

2.3 非对称加密：解决密钥分发难题

非对称加密用一对密钥：公钥和私钥。公钥随便给，私钥自己藏好。用公钥加密的数据，只有私钥能解开。反过来，用私钥加密的数据，公钥也能验证。

常见的非对称加密算法：

• RSA：最经典，2048 位以上才安全。加密速度和密钥长度成反比。
• ECC（椭圆曲线）：相同安全强度下，密钥更短，速度更快。比如 ECC 256 位 ≈ RSA 3072 位。
• SM2：中国国密标准，基于椭圆曲线，合规场景必选。

你可能会问：「既然非对称加密这么安全，为什么不全用非对称？」

问题在于慢。RSA 加密 1KB 数据就要几毫秒，而 AES 加密 1MB 数据也才几微秒。差了上千倍。所以在实际项目中，我们通常把两者结合：

# 混合加密流程示意
#
# 1. 客户端生成一个随机的 AES 密钥（会话密钥）
# 2. 用 AES 密钥加密大文件内容
# 3. 用服务器的 RSA 公钥加密这个 AES 密钥
# 4. 将加密后的文件 + 加密后的密钥一起上传
# 5. 服务器用 RSA 私钥解密出 AES 密钥
# 6. 用 AES 密钥解密文件内容

这种模式叫「混合加密」。你想想看，它既发挥了对称加密的速度优势，又解决了密钥分发的难题。我在 SDK 对接中，几乎所有加密上传方案都采用这个思路。

2.4 哈希算法：指纹和验尸

哈希算法，也叫散列函数。它能把任意长度的数据，压缩成固定长度的「指纹」。而且这个指纹是单向的——你没法从哈希值反推出原始数据。

常见的哈希算法：

哈希算法在对象存储中的典型用途：

• 完整性校验：上传前计算文件的 SHA-256 值，服务器接收后重新计算，对比是否一致。确保传输过程中没被篡改。
• 去重检测：相同内容的文件会有相同的哈希值。服务器可以用这个做静态资源去重。
• 密码存储：绝不存明文密码，存的是「密码 + 盐值」的哈希结果。

这里要注意：哈希不是加密。加密是可逆的，哈希不可逆。你要是看到有人说「用 MD5 加密」，基本可以判断这个人还没入门。

2.5 三种技术的对比与选型

我们把这三兄弟放一起对比一下：

选型时，我一般遵循三个原则：

1. 加密内容选对称算法（AES-256-GCM）
2. 传递密钥选非对称算法（ECC 或 RSA）
3. 验证完整选哈希算法（SHA-256）

这张图展示的就是我在 SDK 对接中使用的标准流程。你注意看三个核心节点和它们的协作关系：对称加密处理大文件内容，非对称加密处理小密钥，哈希算法做最后的完整性兜底。缺一不可。