常见加密SDK类型归纳总结
做移动端SDK兼容性排查那几年，我几乎天天跟这几种算法打交道。说白了，加密SDK分三大派：对称加密、非对称加密和哈希消息认证码。你把它们摸透了，索引冲突、初始化失败这类问题至少能解决七成。
对称加密：AES 是主角
对称加密，就是加密和解密用同一把钥匙。我习惯把它比作「一把钥匙开一把锁」。最常见的实现是 AES（Advanced Encryption Standard）。为什么选它？因为它在安全性和性能之间找平衡找得最好。
AES 核心参数
- 密钥长度：128位（常用）、192位、256位。我个人建议移动端用256位，虽然慢一点点，但兼容性更广。
- 工作模式：ECB（不推荐）、CBC（常用）、GCM（推荐，自带认证）。
- 填充方式：PKCS7、ZeroPadding。注意！老SDK和新SDK填充不一致会导致解密失败，我踩过这个坑。
举个例子，调用 OpenSSL 或 Crypto++ 的 AES-CBC 加密：
# Python 示意（实际 SDK 用 C/C++）
from Crypto.Cipher import AES
key = b'16byte_secret!!' # 128位密钥
cipher = AES.new(key, AES.MODE_CBC, iv=b'16byte_initial_v')
ciphertext = cipher.encrypt(plaintext) # plaintext 需填充
避坑提示：我曾经在集成某国产加密SDK时，发现它内部用了自定义的零填充，而应用层用了PKCS7。结果双方跑不通。解决方案是统一填充方式，或者在SDK初始化时显式设置参数。
非对称加密：RSA 仍是老大哥
非对称加密有一对钥匙：公钥加密、私钥解密。RSA 是这里的老牌选手，基于大整数分解难题。你想想看，公钥随便发给别人，私钥自己藏着，这设计多优雅。
实际项目中，RSA 很少用来加密大量数据——太慢了。它主要做两件事：
- 密钥交换：客户端用服务器公钥加密AES密钥，服务器私钥解密。
- 数字签名：私钥签名，公钥验签。
| 密钥长度（位） | 安全强度 | 签名/解密速度 | 常见场景 |
|---|---|---|---|
| 1024 | 已不安全 | 快 | 老旧系统兼容（不建议） |
| 2048 | 安全（推荐） | 中等 | 移动支付、政企 |
| 4096 | 极高 | 慢 | 金融核心、CA证书 |
踩坑实录：我曾经遇到过一台 Android 设备使用 RSA 2048 解密时报“invalid key length”。查了三天发现是系统底层 Crypto Provider 把私钥的 PKCS#8 格式当成了 PKCS#1 解析。解决办法是在 SDK 初始化时强制指定 key format。
哈希与消息认证码：HMAC 才是你想要的
很多人混淆哈希（Hash）和 HMAC。纯粹的哈希（比如 SHA-256）没有密钥，任何人都能计算。而 HMAC（Hash-based Message Authentication Code）则基于共享密钥和哈希算法，用于验证数据完整性和身份。
做 SDK 时，我推荐用 HMAC-SHA256 或 HMAC-SHA1（SHA1 虽旧但兼容性很广）。它的特点：
- 输入：密钥 + 消息
- 输出：固定长度 MAC 值（如 32 字节）
- 安全性：只有知道双方密钥才能伪造
// C++ 伪代码（带常见的 HMAC 调用）
#include <openssl/hmac.h>
unsigned char* result = HMAC(
EVP_sha256(),
key, key_len,
data, data_len,
md, &md_len
);
调试经验：HMAC 的索引问题大多出在 key 编码上——比如服务端用 Base64 解码，SDK 却传了原始字符串。代码里加一行打印密钥长度和内容（注意不要泄漏到日志），问题就豁然开朗。
三种类型的对比：一张表说清
| 类型 | 代表算法 | 密钥 | 主要用途 | 性能 | 典型 SDK 依赖 |
|---|---|---|---|---|---|
| 对称加密 | AES | 单密钥，需安全分发 | 数据加解密 | 快 | OpenSSL, BoringSSL, mbedTLS |
| 非对称加密 | RSA | 公钥/私钥对 | 密钥交换、签名 | 慢 | OpenSSL, Crypto++ |
| 消息认证码 | HMAC | 共享密钥 | 完整性校验、身份认证 | 较快 | OS 原生 Crypto API, OpenSSL |
注意上面的「密钥」列：对称加密的密钥分发是老大难，非对称加密把密钥分为公开和私有两部分，HMAC 的密钥则要求双方在通信前协商好。这三种 SDK 在索引兼容问题中根本原因常常是：密钥格式不兼容、算法模式不匹配、底层加密库版本差异。
我的一个归纳模型：你在排查索引冲突时，先定位 SDK 属于哪一类，然后检查参数（模式、填充、密钥编码、初始化向量）。这个思路帮我解决了至少十几个线上工单。
总结：怎么快速定位问题？
遇到索引兼容问题，你先问三个问题：
- 用的是哪类加密？——对称/非对称/HMAC
- 密钥是怎么传的？——直接字节流？Base64？Hex？
- 底层什么库？—OpenSSL 1.0 vs 1.1 差别很大，BoringSSL 更激进