OpenSSL加解密前必须初始化（如OPENSSL_init_crypto或加载default provider），否则EVP接口可能静默失败；使用后需调用EVP_CIPHER_CTX_free清理上下文；推荐AES-GCM而非CBC，因其兼具机密性与完整性，且需正确处理nonce、AAD和auth tag；密钥与IV必须用RAND_bytes安全生成，解密失败时须通过ERR_get_error定位具体原因。
OpenSSL加解密前必须初始化和清理
不调用 OPENSSL_init_crypto() 或旧版 OPENSSL_add_all_algorithms_conf()，后续的 EVP_CIPHER_fetch()、EVP_EncryptInit_ex() 很可能返回空指针或静默失败——尤其在 OpenSSL 3.0+ 默认禁用 legacy provider 的情况下。
常见错误现象：加密函数返回 1（成功），但输出长度为 0；或解密时 EVP_DecryptFinal_ex() 返回 0 并报错 error:00000000:lib(0):func(0):reason(0)。
- OpenSSL 3.0+ 推荐显式加载 default provider：
OPENSSL_init_crypto(OPENSSL_INIT_ATFORK | OPENSSL_INIT_ADD_ALL_CIPHERS | OPENSSL_INIT_ADD_ALL_DIGESTS, nullptr)，或更安全地调用OSSL_PROVIDER_load(nullptr, "default") - 使用完 EVP 接口后，不需要手动释放
EVP_CIPHER或EVP_CIPHER_CTX对象，但必须调用EVP_CIPHER_CTX_free(ctx)清理上下文 - 多线程环境下，避免复用同一个
EVP_CIPHER_CTX*，每次加解密应新建并初始化
对称加密选 AES-GCM 还是 AES-CBC？
AES-GCM 是当前推荐方案：它同时提供机密性与完整性校验，且无需额外 HMAC 计算；而 AES-CBC 本身不防篡改，必须配合 HMAC-SHA256 手动实现 Encrypt-then-MAC，否则易受 padding oracle 攻击。
实操差异明显：
- GCM 模式需设置 nonce（IV）和 auth tag（通常 16 字节），且 nonce 绝对不可重用；CBC 只需 IV，但 IV 必须随机且不可预测
- GCM 的
EVP_EncryptFinal_ex()会把 auth tag 写入输出缓冲区末尾，需预留空间；CBC 则只输出密文，padding 由 OpenSSL 自动处理 - 性能上 GCM 在支持 AES-NI 的 CPU 上显著更快；CBC 若用软件实现，ECB 模式垫片还可能引入侧信道风险
示例关键步骤（GCM）：EVP_EncryptInit_ex(ctx, cipher, nullptr, key, iv) → EVP_EncryptUpdate(ctx, nullptr, &outlen, aad, aad_len)（设附加数据）→ EVP_EncryptUpdate()（加密正文）→ EVP_EncryptFinal_ex() → 最后用 EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_AEAD_GET_TAG, 16, tag) 提取 tag。
如何安全生成和管理密钥与 IV
硬编码密钥、用时间戳当 IV、或从 rand() 取字节，都会让加密形同虚设。OpenSSL 提供了专用的 CSPRNG 接口，必须用它。
- 密钥生成：用
RAND_bytes(key, key_len)，而非std::random_device或time(nullptr)；AES-256 要 32 字节，别少写 - IV/nonce 生成：同样走
RAND_bytes(iv, iv_len)；GCM 建议 12 字节（96 bit），CBC 至少 16 字节；生成后必须随密文一起保存或传输，但绝不能和密钥混在一起硬编码 - 密钥派生（如用户口令转密钥）：用
EVP_KDF_CTX+EVP_KDF_fetch(nullptr, "pbkdf2", nullptr)，参数设迭代次数 ≥ 100000、盐值 16 字节随机
注意：RAND_status() 返回 0 表示熵不足，此时 RAND_bytes() 可能失败——Linux 下通常没问题，但嵌入式或容器环境需确认 /dev/urandom 可访问。
解密失败时怎么定位是密钥错、IV错还是数据损坏？
OpenSSL 解密失败几乎都返回 0，但错误堆栈里藏着线索。直接忽略 ERR_get_error() 就只能靠猜。
- 先检查
EVP_DecryptUpdate()返回值：若为 0，大概率是密钥/IV 不匹配，或 GCM 下 AAD 不一致 - 再看
EVP_DecryptFinal_ex()：若为 0，GCM 场景下极可能是 auth tag 校验失败（密文或 tag 被篡改/截断），CBC 场景则可能是 padding 错误（IV 错或密文不完整） - 务必用
ERR_print_errors_fp(stderr)或循环调用ERR_get_error()+ERR_error_string()打印完整错误链，例如看到error:04091077:rsa routines:RSA_padding_check_PKCS1_OAEP_mgf1:encoding error就知道是 OAEP 解密失败，不是密钥问题
一个容易被忽略的点：GCM 解密前必须先设置 tag（用 EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_AEAD_SET_TAG, tag_len, tag)），否则 EVP_DecryptFinal_ex() 总是失败，且错误信息毫无提示。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
