4. 对称加密算法工程实践
对称加密是OpenSSL中使用频率最高的密码学能力。它的特点是加密与解密使用同一把密钥，速度快、适合处理大块数据，因此被广泛用于文件加密、数据库字段保护、通信会话密钥封装以及国密合规场景。工程实践中，真正困难的部分并不是“调用一次加密函数”，而是围绕算法选型、工作模式、填充策略、密钥与IV管理、性能与安全边界做出一致决策。本章围绕AES与SM4，结合OpenSSL命令行与典型参数，梳理一套可落地的对称加密实践方法。
一、算法选型：AES与SM4的定位
AES（Advanced Encryption Standard）是国际通用分组密码，分组长度固定为128位，密钥长度支持128、192、256位。工程上最常用的是AES-128与AES-256：前者性能更好，后者安全裕度更高。SM4是我国商用密码标准分组算法，分组长度同样为128位，密钥长度固定为128位，常用于需要国密合规的系统。两者在OpenSSL中都可以通过EVP接口或命令行调用。
选型时建议遵循以下判断：如果系统面向国内监管或需要国密合规，优先选择SM4；如果面向国际互操作、依赖通用硬件加速或已有AES生态，优先选择AES。若同一系统需要同时满足两类要求，可以采用“双算法”策略：对外使用AES，对合规数据使用SM4，但必须避免把两种算法的密钥材料混用。
二、OpenSSL命令行加解密：AES与SM4
OpenSSL的enc子命令是最直接的对称加解密入口。下面给出AES-256-CBC与SM4-CBC的典型用法。示例中的密钥与IV仅用于教学演示，实际部署必须使用安全随机源生成并妥善保管。
# 生成32字节随机密钥与16字节IV（示例）
openssl rand -out aes.key 32
openssl rand -out aes.iv 16
# AES-256-CBC 加密
openssl enc -aes-256-cbc -in plain.txt -out cipher.bin \
-K $(xxd -p -c 32 aes.key) -iv $(xxd -p -c 16 aes.iv)
# AES-256-CBC 解密
openssl enc -d -aes-256-cbc -in cipher.bin -out plain.out \
-K $(xxd -p -c 32 aes.key) -iv $(xxd -p -c 16 aes.iv)
# SM4-CBC 加密（密钥16字节，IV16字节）
openssl rand -out sm4.key 16
openssl rand -out sm4.iv 16
openssl enc -sm4-cbc -in plain.txt -out sm4.bin \
-K $(xxd -p -c 16 sm4.key) -iv $(xxd -p -c 16 sm4.iv)注意-K与-iv接收的是十六进制字符串，因此需要用xxd -p把二进制密钥转成十六进制。若使用口令派生方式（-pass），OpenSSL会走EVP_BytesToKey，默认迭代次数较低，不建议用于新系统。更规范的做法是使用PBKDF2或直接由KMS/HSM下发密钥。
三、工作模式选择：CBC、CTR与GCM
CBC模式将明文分块后与前一块密文异或再加密，需要IV且必须填充。它的优点是兼容性好、实现成熟；缺点是串行加密、不能并行，且不提供完整性保护。CTR模式把分组密码变成流密码，加密与解密都使用同一套计数器运算，天然支持并行，且不需要填充。GCM是在CTR基础上增加GMAC认证的模式，同时提供机密性与完整性，是现代协议的首选，但Nonce绝不能重复。
工程建议：新系统优先选择AES-256-GCM或SM4-GCM；若必须使用CBC，应配合HMAC做“先加密后MAC”或使用EtM结构；CTR适合对性能敏感且能自行保证完整性的场景。对于SM4，OpenSSL支持sm4-cbc、sm4-ctr、sm4-gcm等模式，选型逻辑与AES一致。
四、填充策略：PKCS#7与NoPadding
分组密码要求输入长度是分组长度的整数倍。CBC等模式需要填充，OpenSSL默认使用PKCS#7填充：若缺少n字节，则填充n个值为n的字节；若正好对齐，则额外填充一个完整分组。解密时OpenSSL会自动去除填充，若填充不合法会报错，这也是CBC填充预言攻击的根源之一，因此必须配合完整性校验。
CTR与GCM属于流式模式，不需要填充，应使用-nopad关闭默认填充。若在流式模式下误用填充，会导致密文长度异常或解密失败。对于需要与其它系统互操作的场景，必须明确双方使用的填充方式，不能默认“OpenSSL会处理好”。
五、性能考量与工程参数
性能主要受算法、模式、硬件加速和数据处理方式影响。AES在支持AES-NI的x86平台或ARM Crypto扩展上吞吐可达数GB/s；SM4目前主要依赖软件实现，吞吐通常低于AES，但在国密合规场景不可替代。GCM由于可并行，通常比CBC更快；CBC加密串行，解密可并行。
实际工程中还应关注：密钥长度与轮换周期、IV/Nonce的随机性与唯一性、大文件的分块流式处理、以及错误处理是否泄露敏感信息。下面给出一份可直接参考的参数决策表。
| 场景 | 推荐算法 | 推荐模式 | 填充 | 关键注意点 |
|---|---|---|---|---|
| 国密合规数据保护 | SM4 | GCM 或 CBC+HMAC | GCM免填充；CBC用PKCS#7 | 密钥16字节，Nonce/IV唯一 |
| 国际互操作、通用文件加密 | AES-256 | GCM | 免填充 | Nonce禁止复用，标签需校验 |
| 兼容旧系统 | AES-128/256 | CBC | PKCS#7 | 必须额外做完整性校验 |
| 高吞吐流式数据 | AES-256 或 SM4 | CTR | 免填充 | 自行保证完整性与计数器唯一 |
常见误区：把CBC当作“安全默认值”而不加MAC；在GCM中复用Nonce；用固定IV加密多条数据；把口令直接当密钥使用。这些都会让对称加密在实际攻击面前迅速失效。
实践建议：优先使用EVP接口而非低层AES_*或SM4_*函数；密钥与IV由安全随机源生成并独立存储；对密文做完整性校验；大文件采用分块流式处理；在性能测试中同时观察吞吐、延迟和CPU占用，而不是只看单次加密耗时。
对称加密的工程实践，本质上是把“算法、模式、填充、密钥、IV、性能”六个变量放在同一张决策表里权衡。AES与SM4各有适用边界，CBC、CTR、GCM对应不同的安全与性能取舍。只有把这些参数与真实业务场景绑定，才能既满足合规要求，又保证系统在高并发和大数据量下稳定运行。