大文件加密不能一次性加载是因为内存不足,必须用EVP_EncryptUpdate分块处理,并仅在EOF后调用EVP_EncryptFinal_ex补PKCS#7填充;块大小建议16KB–64KB,IV需写入密文开头,解密时须严格匹配IV、填充和密钥派生参数。
EVP_EncryptInit_ex 一次性加载?因为内存扛不住。OpenSSL 的 EVP_EncryptInit_ex、EVP_EncryptUpdate 本身支持流式处理,但很多人误以为必须把整个文件读进内存再加密——结果 2GB 文件直接 OOM。真正的问题不在 API 不支持,而在没按块(chunk)调用 EVP_EncryptUpdate,且忽略了 padding 和 final 处理的边界条件。
EVP_EncryptFinal_ex 才补 PKCS#7 padding;若手动分块却在最后一块调用了 EVP_EncryptFinal_ex,会导致重复 padding 或解密失败EVP_EncryptUpdate 的输出缓冲区足够大:输出长度 ≤ 输入长度 + 16(AES-CBC 最大 padding)核心是循环读取、加密、写入三步闭环,且只在 EOF 后调一次 EVP_EncryptFinal_ex。别碰 EVP_CIPHER_CTX_set_padding —— 默认开启 PKCS#7,关了反而要自己算 padding。
EVP_EncryptInit_ex(ctx, EVP_aes_256_cbc(), nullptr, key, iv),key 和 iv 必须是 32 字节和 16 字节,不能靠字符串字面量硬编码(易截断)fread(buf, 1, chunk_size, in_fp) 后,用 EVP_EncryptUpdate(ctx, out_buf, &out_len, buf, read_len) 加密,out_len 是实际写出字节数fread 返回 0(即 EOF)且 read_len == 0 时,才调 EVP_EncryptFinal_ex(ctx, out_buf + out_len, &final_len) 补 paddingEVP_EncryptFinal_ex 返回 0 的常见原因不是算法错,几乎全是上下文状态或内存问题。最常踩的坑是:在非 EOF 时调了它,或者输出缓冲区不够大。
EVP_EncryptFinal_ex 需要最多 16 字节 padding,导致写越界返回 0EVP_EncryptUpdate 刚好把输入凑成整块(如 65536 字节),有人误以为“已对齐”就调 final,结果后续还有数据,解密时会多出一整块乱码EVP_CIPHER_CTX* 用于多个文件,忘了调 EVP_EncryptInit_ex 重置状态,内部计数器错乱加密看着跑通,解密失败十有八九栽在这三点上。
立即学习“C++免费学习笔记(深入)”;
EVP_DecryptUpdate,但 EVP_DecryptFinal_ex 才负责去掉 padding;如果密文末尾被截断(如网络传输丢包),它会返回 0 并清空输出缓冲区EVP_BytesToKey 从 password 生成 key/iv,解密时也得用完全相同的 salt、迭代次数和 digest(如 EVP_sha256()),差一个参数就全错流式加解密的麻烦不在代码行数,而在边界判断稍有偏差就会导致整个文件无法还原。尤其注意最后一次 fread 返回值和 EVP_EncryptFinal_ex 的触发时机——这里没有“差不多”,只有字节级精确。