直接调用 AES_cbc_encrypt 会失败是因为它不处理填充且要求明文长度为16字节整数倍；传入未填充数据（如"hello"）将导致读越界、解密乱码或崩溃，必须先做PKCS#7填充、确保密钥32字节、IV 16字节且每次随机唯一。
为什么直接调用 AES_cbc_encrypt 会失败？
因为 AES_cbc_encrypt 不做填充，也不检查长度。它只处理已对齐的数据块（必须是 AES_BLOCK_SIZE 即 16 字节的整数倍）。如果你传入 "hello"（5 字节），函数不会报错，但会读越界或加密结果不可逆——解密后前几个字节是乱码，后面全是零或垃圾值。
常见错误现象：AES_cbc_encrypt 返回后密文长度和明文一样，但解密出来只有部分正确；或者程序崩溃在 memcpy 或内存访问异常。
- 明文必须先做 PKCS#7 填充（不是零填充，也不是自己随便补）
- 填充后长度 = 原始长度 + (16 - 原始长度 % 16) % 16，结果一定是 16 的倍数
- 密钥必须是 32 字节（
AES-256要求），IV 必须是 16 字节，且不能复用 -
AES_set_encrypt_key失败时返回负值，不检查就直接调用AES_cbc_encrypt会导致未定义行为
如何安全生成和管理 IV？
IV 不是密码，但必须随机、不可预测、每次加密都不同。硬编码或重复使用 IV 会让 CBC 失去语义安全性——相同明文会生成相同密文前缀，攻击者可识别模式。
OpenSSL 提供 RAND_bytes，别手写 rand() 或时间戳生成：
立即学习“C++免费学习笔记（深入）”；
- 调用
RAND_bytes(iv, AES_BLOCK_SIZE)，失败需重试或报错 - IV 必须和密文一起保存/传输（通常拼在密文前面），解密时取前 16 字节即可
- 不要把 IV 当作密钥的一部分混入密钥派生逻辑里
- 如果用
EVP接口（如EVP_EncryptInit_ex），IV 会被内部复制，但原始 IV 缓冲区仍需保持有效直到加密完成
AES_cbc_encrypt 和 EVP_EncryptUpdate 选哪个？
直接用 AES_cbc_encrypt 更轻量、无状态、适合已知长度的内存数据；EVP 接口支持流式处理、自动处理 padding（配合 EVP_EncryptFinal_ex），但需要管理上下文对象，出错路径更长。
-
AES_cbc_encrypt：适合小块数据（如 token、配置项）、嵌入式或性能敏感场景；你负责填充、对齐、错误检查 -
EVP_EncryptUpdate：适合文件加密、网络包分片等不确定长度的场景；它内部会缓存未满块，EVP_EncryptFinal_ex补齐并填充 - 两者密钥和 IV 格式一致，但
EVP要求显式调用EVP_CIPHER_CTX_new和EVP_CIPHER_CTX_free - 注意：
AES_cbc_encrypt会修改传入的 IV 缓冲区（CBC 模式特性），务必传副本，否则后续解密用错 IV
解密时最常忽略的三件事
解密不是加密的简单反向调用，尤其在边界处理上容易翻车：
- 密文长度必须是 16 字节倍数，否则
AES_cbc_encrypt(..., AES_DECRYPT)解出来的数据含非法填充，PKCS#7去除逻辑必须严格校验（比如最后字节值为n，则倒数n字节都得等于n） - IV 必须和加密时完全一致——哪怕只差一个字节，第一个块就全错，后续块也会连锁错误（CBC 的链式依赖）
- 密钥扩展失败（
AES_set_decrypt_key返回负值）比加密更隐蔽：有时解密函数“看似成功”返回了数据，但内容全错，因为轮密钥没生成出来
实际项目里，建议把填充验证和 IV 长度检查写成独立函数，别堆在加解密主逻辑里。CBC 模式本身不提供完整性校验，密文被篡改后解密可能不报错，只是输出乱码——这点常被忽略。
