应优先使用AES-GCM加密配置文件，它天然提供认证标签防篡改；密钥须通过环境变量或系统密钥库管理，IV需12字节随机生成并前置存储，tag为16字节追加末尾，解密时必须手动注入tag并验证返回值。
加密保存配置前，先确认密钥和校验方式是否真有必要自研
直接用 AES-256-CBC 加密配置文件 + SHA-256 校验头，看似安全，但多数场景下反而引入了密钥管理漏洞：硬编码密钥、未保护 IV、忽略 padding 填充一致性。真正需要的不是“加密”，而是“防止明文泄露+篡改可检出”。AES 本身不提供认证，必须搭配 HMAC 或用 AES-GCM；而校验头若只是简单拼接 SHA-256，攻击者仍可截断重放旧包——所以校验必须绑定加密上下文（如对密文计算 HMAC，或用 GCM 的 tag）。
实操建议：
- 优先考虑
AES-GCM（OpenSSL 1.1.1+ 或 libsodium），它天然带认证标签，无需手动拼校验头 - 密钥绝不能写死在代码里；改用环境变量注入或系统密钥库（Windows DPAPI / macOS Keychain / Linux keyring）
- IV 必须每次随机生成，且与密文一起保存（通常前置 12 字节）
- 不要自己实现 PKCS#7 填充逻辑，用成熟库的
EVP_EncryptUpdate自动处理
用 OpenSSL EVP 接口生成 .enc 包（含 GCM tag 头）
以 OpenSSL 为例，生成格式为：[IV(12)][ciphertext][tag(16)]，其中 tag 即 GCM 认证标签，既是校验依据，也是解密前提——缺一不可，天然防篡改。
关键步骤：
立即学习“C++免费学习笔记（深入）”；
- 调用
EVP_CIPHER_CTX_new()后，必须用EVP_EncryptInit_ex(ctx, EVP_aes_256_gcm(), nullptr, nullptr, nullptr)初始化 - 设置密钥和 IV 前，先用
EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_SET_IVLEN, 12, nullptr)显式指定 IV 长度 - IV 需用
RAND_bytes(iv, 12)安全生成，不能用 time() 或 rand() - 加密完成后，用
EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_GET_TAG, 16, tag)提取 tag，追加到密文末尾
示例片段（省略错误检查）：
unsigned char iv[12], tag[16]; RAND_bytes(iv, sizeof(iv)); EVP_EncryptInit_ex(ctx, nullptr, nullptr, key, iv); EVP_EncryptUpdate(ctx, out, &outlen, plaintext, len); EVP_EncryptFinal_ex(ctx, out + outlen, &finalLen); EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_GET_TAG, 16, tag); // 写入文件：先写 iv（12字节），再写密文，最后写 tag（16字节）
读取 .enc 包时，IV、密文、tag 缺一不可且顺序固定
解密失败常见原因不是密码错，而是结构解析错误：把 IV 当作密文一部分送入解密，或忽略了 tag 验证步骤。OpenSSL 的 EVP_DecryptFinal_ex 在 GCM 模式下**不会自动校验 tag**，必须手动调用 EVP_CIPHER_CTX_ctrl 设置 tag，否则解密总成功，但结果不可信。
正确流程：
- 从文件头读取 12 字节作为
iv，接着读取中间全部字节作为密文（不含最后 16 字节），最后 16 字节为tag - 调用
EVP_DecryptInit_ex(ctx, nullptr, nullptr, key, iv)后，立即用EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_SET_TAG, 16, tag)注入 tag - 仅当
EVP_DecryptFinal_ex返回 1 时，才表示解密+校验全部通过；返回 0 意味着密文被篡改或 IV/tag 不匹配
注意：EVP_DecryptUpdate 对 GCM 模式不输出数据，所有明文都在 EVP_DecryptFinal_ex 中产出，这点和 CBC 不同。
为什么不用 base64 编码 .enc 文件？
因为 .enc 是二进制包，base64 会膨胀约 33%，增加 I/O 和内存压力，且无实际安全增益。配置文件本就不该被人工阅读，没必要可读性。如果部署环境强制要求文本（如某些配置中心只接受字符串），那应在传输层做 base64（如 HTTP body），而非把编码逻辑嵌入加密流程。
更隐蔽的风险点：
- 文件权限未设为 600（Linux/macOS）或 DACL 限制（Windows），导致其他用户可读
- 临时文件写入 /tmp 且未设 umask，造成密钥/明文残留
- 调试时用
std::cout 打印二进制，触发流异常或截断
真正的难点不在加密算法本身，而在于密钥生命周期管理和二进制 IO 的边界控制——哪怕 AES-GCM 调用完全正确，一个 fopen("config.enc", "w") 没加 O_CLOEXEC 或没检查返回值，整个防护就形同虚设。
