对称加密算法在SDK中的实现与选型
对称加密，说白了就是一把钥匙开一把锁。加密和解密用同一个密钥。在加密SDK里，这是最基础、最核心的模块。你想想看，无论是存个配置文件，还是传个网络消息，只要涉及到数据机密性，基本都得靠它。
今天咱们聚焦两个算法：AES 和 SM4。面试官问起“对称加密选型怎么考虑”，你要是能把这俩的差异吃透，再结合实现细节讲清楚，基本就过关了。
为什么需要对称加密？
我刚开始写SDK时，总觉得非对称加密更“高级”。直到有一次，性能压测死活过不了，调了半天发现是RSA加密单条大数据块把CPU打满了。那个教训就是：大量数据的加密，一定用对称加密。非对称只用来协商对称密钥或做签名。
AES vs. SM4：关键差异对比
AES是国际标准，SM4是国家标准。很多公司出海就得同时支持这两套。我做过的一个区块链钱包SDK，就是两边都要兼容。
| 特性 | AES (Rijndael) | SM4 |
|---|---|---|
| 分组长度 | 128 bit | 128 bit |
| 密钥长度 | 128/192/256 bit | 128 bit |
| 轮数 | 10/12/14 | 32 |
| 结构 | Substitution-Permutation Network | Feistel 网络 |
| 性能（软件实现） | 现代CPU有AES-NI指令加速 | 纯软件实现，无原生加速指令 |
AES在SDK中的实现细节
AES有几种关键模式，选错了就是安全漏洞。我见过太多人拿ECB模式去加密用户身份证号，结果同一号码产生的密文完全相同，连统计攻击都不用，直接暴露信息。
下面这张图展示了AES在SDK内部的核心流程和模式选择逻辑：
模式选择与安全考量
模式选型这块，我可以给你个非常直接的建议：能用GCM就用GCM。GCM是认证加密模式，同时提供了机密性、完整性和真实性校验。我在一个支付SDK里全面转向GCM后，连之前手动算HMAC的代码都省了。
- ECB模式： 千万别用在SDK的对外接口里。同一个明文块产生同一个密文块，毫无语义安全性。
- CBC模式： 需要随机IV，而且不能并行处理。如果允许用户指定固定IV，那就是个坑。
- GCM模式： 内置认证标签，防篡改。每次加密必须生成唯一的Nonce（96 bit最优）。
- CTR模式： 可以并行，但本身不提供完整性。通常需要外加MAC。
SM4的落地要点
SM4在国内合规场景是必须的。金融、政务、关键基础设施，很多地方要求只用国密。它的Feistel结构实现起来更直接，但要注意几点：
- S盒查表实现： 查表法速度快，但要注意抵抗缓存时间攻击。我习惯在初始化时就把S盒展开到内存，避免运行时计算。
- 密钥扩展： SM4的密钥扩展和加解密过程共享同一套轮函数。这与AES不同，AES的密钥扩展是独立的。
- 模式选用： SM4也有GCM模式（即SM4-GCM）。如果SDK需要同时支持合规和性能，最好提供SM4-GCM。
实现中的关键考量
写对称加密代码，不只是调个OpenSSL或Bouncy Castle就完事了。在实际的SDK里，你得考虑这些：
| 考量点 | 说明 |
|---|---|
| 密钥生命周期管理 | 密钥不能硬编码在代码里。SDK应该从密钥管理模块或硬件安全模块导入密钥。用完及时擦除内存中的密钥痕迹。 |
| IV/Nonce生成 | 必须使用加密安全的随机数生成器。不要用时间戳或自增计数器当Nonce，除非你非常清楚自己在做什么。 |
| 填充模式 | 如果选用了CBC等需要填充的模式，PKCS#7是最常用的。但在GCM这类流模式里不需要填充。 |
| 错误处理 | 不要泄漏解密失败的具体原因。比如“MAC校验失败”和“填充错误”应该返回同一个错误码，防止侧信道攻击。 |
| 性能与内存 | 对于大文件加密，应采用流式处理（分块加密），避免一次性加载整个文件到内存。 |
避坑指南：我曾经踩过的雷
我最早做加密SDK时，犯过一个低级错误——在加密完成后没有将密钥从栈上清零。C++里栈变量出了作用域还在内存里，后来被一个恶意进程通过核心转储把密钥读走了。从那之后，我要求所有SDK都必须做到：
- 使用安全内存分配（如mlock防止swap，mprotect防止读取）
- 加密结束后立即memset清零敏感缓冲区
- 禁用写时拷贝优化，避免内存中的密钥副本
还有个坑是线程安全。对称加密的密钥上下文比如EVP_CIPHER_CTX，不能直接在多线程里共享。每个线程要么用独立的上下文，要么加锁保护。我在一个多线程SDK里就因为这个出了数据错乱，定位了很久才发现是上下文重入的问题。
总结要点
- 默认用AES-128-GCM，除非合规必须用SM4。GCM集成了认证，省心又安全。
- SM4优先走查表实现，无硬件加速时性能可控。如果SDK运行在国密硬件上，再考虑调用指令级优化。
- 密钥、IV、填充、错误处理，每个细节都可能导致安全漏洞。SDK接口设计要倾向于“安全而难用错”。
- 测试向量必须有。每个模式和每个算法组合，都要用NIST或国密标准的测试向量做回归。