3. 常见加密算法与SDK选型归纳总结

加密算法这件事，说起来挺绕的。我刚入行那会儿，面对一堆AES、RSA、ECC的名词，真是头大。后来在CI/CD流水线里集成加密SDK时踩过不少坑，才慢慢理清了头绪。今天咱们就把这些算法掰开揉碎，再聊聊SDK怎么选。

3.1 对称加密：快，但密钥是个麻烦

对称加密，说白了就是加密和解密用同一把钥匙。你想想看，这就像你和同事共用一个保险柜密码——方便是方便，但密码怎么安全地告诉对方？

我个人习惯在CI/CD流水线里用AES-256-GCM来处理构建产物加密。GCM模式自带认证，能防篡改，省去额外算MAC的步骤。记得有一次，我图省事用了ECB模式，结果加密后的包结构被攻击者猜出了部分明文……嗯，从那以后，我再也不敢碰ECB了。

3.2 非对称加密：慢，但解决了密钥分发

非对称加密有一对钥匙：公钥公开，私钥自留。这个设计很巧妙——别人用公钥加密数据，只有你能用私钥解开。

• RSA： 经典算法，但密钥越长性能越差。2048位以上推荐，4096位已经有些“笨重”了。
• ECC（椭圆曲线）： 用更短的密钥达到相同安全强度。比如256位的ECC≈3072位的RSA。我在移动端SDK签名时偏爱ECC，速度更快。
• Ed25519： 现代且极快，常用于SSH和TLS。我自己的SSH密钥就是Ed25519。

3.3 哈希算法：不可逆的“指纹”

哈希函数不是加密（因为它不能解密），但它是安全基础设施的基石。比如校验文件完整性、存储密码哈希。

算法	输出长度	碰撞抵抗	推荐等级
SHA-256	256 bit	强	推荐
SHA-3	可变	极强	推荐（新项目）
BLAKE2	可变	极强	性能优先场景

3.4 SDK选型：不是越多越好，是越合适越好

市面上加密SDK很多，怎么选？我一般看四个维度：

1. 标准兼容性： 是否支持FIPS 140-2/140-3？如果客户是政府或金融行业，这是硬门槛。
2. 语言绑定： Java项目用Bouncy Castle，Go项目用crypto库，C++项目用OpenSSL或libsodium。别强行跨语言。
3. 更新维护： 一个三年没更新的SDK，你敢用吗？我踩过的坑：某知名SDK在2018年停止维护，后来爆出CVE，我们紧急替换。
4. 性能开销： 在CI/CD流水线里，加密操作可能成为瓶颈。我建议用原生库（如OpenSSL的硬件加速）而不是纯Java实现。

3.5 一张图理清算法与选型

下面这张图我经常在团队内部分享，它把加密算法分类和选型决策串起来了。

这张图的逻辑很简单：先看你要解决什么问题——是加密传输（对称/非对称）、身份验证（非对称签名）还是完整性校验（哈希）。然后根据你的语言和性能要求，从推荐SDK里选。

3.6 一点实战反思

我曾经在一个微服务项目里，每个服务都用了不同的加密SDK：A服务用JavaScript的crypto-js，B服务用Python的PyCryptodome，C服务用Java的Bouncy Castle。结果密钥管理一片混乱，AES模式也不统一。后来我统一成libsodium作为全公司标准——所有语言都有绑定，且默认使用XChaCha20-Poly1305和Curve25519，几乎不会选错。

所以我的建议是：少即是多。选一个现代、安全、跨语言的加密库，然后在CI/CD流水线里把密钥管理和算法参数固定下来。你想想看，流水线不应该成为加密实验田——稳定、可审计才是第一位的。