加密基础概念：对称加密与非对称加密的区别，常见算法与数据完整性
说到对象存储加密，加密基础概念是绕不开的坎。你可能听过对称加密、非对称加密、哈希这些词，但它们在 SDK 里具体怎么用、为什么选这个不选那个，才算真吃透了。今天咱们把这几个东西掰开揉碎了聊。
对称加密：快，简单，但有个大问题
对称加密，说白了就是加解密用同一把钥匙。你给我一把钥匙，我用它锁箱子，你用同一把钥匙开箱子。在对象存储场景里，你上传文件之前，SDK 直接用这把密钥把数据加密成密文，存到云端。下载的时候再用同一个密钥解密。
常见的对称加密算法，我最常用的是 AES-256-GCM。256 指的是密钥长度 256 位，GCM 是分组模式，自带完整性校验。为什么推荐 GCM？因为它在加密的同时还能生成一个认证标签，防止数据被篡改。说白了省了一步单独做哈希的麻烦。
另外得提一下 SM4，国密标准。如果你们公司做的是政务、金融这类合规要求很严的项目，SM4 是必修课。算法本身和 AES 类似，也是分组密码，密钥长度 128 位。性能上比 AES-256 略慢一点，但差距不大，硬件加速也做得越来越好了。
对称加密的适用场景：
- 加密大量数据块——文件分片后每片都用对称密钥加密，性能最优
- 本地缓存加密——客户端直接管理密钥，不依赖远程服务
- 服务端静态加密——像 AWS S3 的 SSE-S3 就是用 AES-256 自动加密
我个人习惯在 SDK 里默认使用 AES-256-GCM，而不是 Cipher Block Chaining (CBC) 模式。GCM 是 AEAD 模式，一次搞定加密和完整性校验，少写很多代码，也不容易踩初始化向量的坑。
非对称加密：慢，但能解决密钥分发
非对称加密用一对密钥：公钥加密，私钥解密。公钥可以随便发给别人，私钥自己保管。你想想看，对称加密的最大问题就是密钥怎么安全地传给对方。非对称加密正好解决了这个痛点。
对象存储里最常见的非对称算法是 RSA。通常我们用 2048 位或 4096 位密钥。RSA 的速度是真慢——加密 1KB 的数据就要好几毫秒，跟 AES 的纳秒级完全没法比。所以实际项目中从不拿 RSA 加密大文件。
那 RSA 在对象存储中干什么用？我总结三种典型场景：
- 信封加密：用一个临时生成的对称密钥去加密文件数据，然后用 RSA 公钥加密这个对称密钥。解密时先用 RSA 私钥解开对称密钥，再用它解密文件。
- 数字签名：用私钥对文件哈希签名，公钥验证签名是否来自可信来源。比如上传前对文件做一次签名，下载后验证，确保文件没被替换。
- 密钥协商：通过 Diffie-Hellman 或 RSA 密钥交换，在客户端和服务端之间安全地建立共享密钥。
| 特性 | 对称加密（AES-256） | 非对称加密（RSA-2048） |
|---|---|---|
| 密钥数量 | 1 个共享密钥 | 公钥 + 私钥 |
| 加密速度 | ～1 GB/s（硬件加速） | ～1 MB/s |
| 密钥分发难度 | 高（需要安全通道） | 低（公钥公开） |
| 典型密钥长度 | 128/256 位 | 2048/4096 位 |
| 对象存储典型使用 | 直接加密数据块 | 加密对称密钥 / 签名 |
我曾经踩过的坑：
直接拿 RSA 加密整个文件。一次上传 100MB，结果加密耗时超过 30 秒，把客户端搞超时了。后来改成信封加密——用 AES 加密文件，用 RSA 保护 AES 密钥，性能从 30 秒降到 100 毫秒。记住：非对称加密只适合加密小数据，上限也就几百字节。
哈希与 HMAC：保证数据没被偷偷改过
加密只能防偷看，不能防篡改。这事得靠哈希和 HMAC。哈希把任意长度的数据算成一个固定长度的摘要。哪怕文件只改了一个 bit，哈希值也会完全不一样。
对象存储里常用的哈希是 SHA-256，输出 256 位摘要。国密方案用 SM3，输出也是 256 位，算法细节不同，但使用目的一样。上传对象时算一次哈希，下载后再算一次，比对两次数值，就知道文件有没有在传输过程中损坏或被篡改。
但普通哈希有个问题：如果攻击者同时篡改文件和哈希值，你根本发现不了。嗯，这里就要用到 HMAC——带密钥的哈希。计算哈希的时候混入一个只有你和服务器知道的密钥。攻击者没有密钥，就算把文件和哈希一起改了，也算不出正确的 HMAC 值。
// 伪代码示例：HMAC 计算与验证
// 上传端
secretKey = "your-secret-key-256bit"
fileData = readFile("important.docx")
hmacTag = HMAC_SHA256(secretKey, fileData)
upload(fileData, hmacTag) // 把文件和数据标签一起上传
// 下载端
downloadedData, storedTag = download("important.docx")
computedTag = HMAC_SHA256(secretKey, downloadedData)
if computedTag == storedTag:
print("数据完整，未被篡改")
else:
print("数据可能被篡改，丢弃文件")
在 SDK 接口设计里，我建议把 HMAC 和对称加密捆绑成一个原子操作。比如用 AES-256-GCM 时，GCM 模式内部已经做了类似 HMAC 的事情——生成一个认证标签。如果你自己实现了“先加密再单独算 HMAC”，容易犯顺序错误，别问我是怎么知道的。
说到哈希，还有一点很重要：哈希冲突。理论上不同的输入可能产生相同的哈希值，SHA-256 的碰撞概率极低，但理论上存在。所以在金融级别的校验场景，光靠哈希可能不够，需要结合数字签名和版本号做多重校验。
调试阶段可以先用 MD5 做快速校验，但生产环境必须切换到 SHA-256 或 SM3。MD5 碰撞攻击早就是公开武器了。我自己维护的一个遗留 SDK 曾经用 MD5 做文件分片校验，后来被安全团队要求全部换成 SHA-256，改了三天才跑通回归测试。
三种技术怎么组合？
实际的对象存储加密 SDK，不会只用其中一种。我见过最稳妥的设计是三层结构：
- 对称加密层：AES-256-GCM 加密每个文件块，性能和安全性兼顾。
- 密钥保护层：用 RSA 或 ECC 公钥加密对称密钥，私钥放在服务端的硬件安全模块里。
- 完整性校验层：在传输层用 HMAC 或 GCM 认证标签，在存储层用哈希做定期校验。
说白了，对称加密管数据机密性，非对称加密管密钥安全，哈希和 HMAC 管数据完整性。三者缺一不可。我见过一些团队只做 AES 加密，忽略了 HMAC，结果数据在传输过程中被损毁，恢复出来的文件全是乱码。也见过只做哈希不做加密，敏感数据等于直接裸奔。
如果你们做的是多云或跨区域复制，一定要在 SDK 里内置算法协商能力。比如华东节点用 AES-256-GCM，华南因为合规要求必须用 SM4-GCM。SDK 需要能根据存储桶的元数据自动切换算法，而不是写死在代码里。
重点就这几个概念。把对称加密的速度、非对称加密的密钥管理、哈希的完整性校验，揉到 SDK 的接口设计里，才算完成了加密基础的一环。