不能用std::ofstream直接写入密码保护文件，因其仅负责I/O，不提供加密功能；必须先用libsodium等库对明文加密（含密钥派生、AEAD加密、nonce写入），再将密文写入文件。
用 std::ofstream 直接写入密码保护文件？不行
密码保护不是文件系统功能，也不是 C++ 标准库职责。所谓“带密码保护的文件”，本质是加密后的二进制数据——你得先加密明文，再把密文写入文件。直接用 std::ofstream 写原始数据，不加任何加密逻辑，得到的只是普通文件，双击打开或用十六进制编辑器一查就全暴露。
常见误区是试图在 open() 时传入密码参数，但 std::ofstream::open(const char*, std::ios_base::openmode) 根本没有密码字段。它只管磁盘 I/O，不管加解密。
实操建议：
- 选一个轻量、无依赖、C++17 可用的加密库，如
libsodium（推荐）或Botan；OpenSSL太重且 C 风格 API 易出错 - 避免手写 AES-CBC 或 XOR 密码流——密钥派生、IV 管理、认证加密（AEAD）这些细节极易翻车
- 密码不能直接当密钥用，必须经
crypto_pwhash（libsodium）等 KDF 派生出 256 位密钥
libsodium 实现加密流写入：关键三步
以 libsodium 为例，实现“输入明文 + 密码 → 输出加密文件”需严格按顺序完成：密钥派生 → AEAD 加密 → 写入含 nonce 的密文。少一步，解密就失败。
立即学习“C++免费学习笔记（深入）”；
示例核心流程（省略错误检查，仅示意结构）：
// 1. 从密码派生密钥（使用 salt，salt 必须随密文保存）
unsigned char key[crypto_aead_chacha20poly1305_KEYBYTES];
crypto_pwhash(key, sizeof(key), password, strlen(password),
salt, 1ULL << 16, // 64 MiB memory, 16 rounds
crypto_pwhash_ALG_DEFAULT);
// 2. 生成随机 nonce（24 字节 for ChaCha20Poly1305）
unsigned char nonce[crypto_aead_chacha20poly1305_NPUBBYTES];
randombytes_buf(nonce, sizeof(nonce));
// 3. 加密并写入：nonce + 密文 + 认证标签
std::ofstream out("data.enc", std::ios::binary);
out.write(reinterpret_cast<char*>(nonce), sizeof(nonce));
crypto_aead_chacha20poly1305_encrypt(
ciphertext, &ciphertext_len,
plaintext, plaintext_len,
aad, aad_len, // 可选附加认证数据
nullptr, // no secret nonce
nonce, sizeof(nonce),
key
);
out.write(reinterpret_cast<char*>(ciphertext), ciphertext_len);
注意点：
-
crypto_aead_chacha20poly1305_encrypt输出的密文长度 = 明文长度 +crypto_aead_chacha20poly1305_ABYTES（16 字节标签），别漏写 -
salt必须随机生成并和密文一起写入文件头部（通常前 16 字节），否则无法复现密钥 - 不要重复使用同一
nonce加密不同数据，否则 ChaCha20 安全性崩塌
为什么不用 fstream 做“加密流”封装？
有人想继承 std::streambuf 实现透明加密流（类似 std::encrypt_ostream），理论上可行，但实际踩坑密集：
- 缓冲区边界与加密块对齐难处理：AES 是 16 字节块，ChaCha20 是流式，但 AEAD 标签只能在末尾生成，
sputn()中途无法输出认证标签 - 异常安全风险高：若加密中途抛异常，
streambuf析构时可能残留未刷新的明文缓冲 - 无法支持随机访问写入（
seekp）——加密后数据长度变化，偏移映射失效 - 调试困难：加密流行为与标准流不一致，
good()/fail()状态含义模糊
更稳的做法是分两层：上层业务代码生成完整明文内存块（或分块读取），下层调用加密函数批量处理，再用 std::ofstream 一次性写入。控制流清晰，错误点明确。
解密时最常被忽略的验证步骤
写入容易，读取+解密时最容易跳过认证验证，导致“看似解密成功，实则数据被篡改”。crypto_aead_chacha20poly1305_decrypt 返回 -1 表示认证失败，但很多人只检查返回值是否为 0，却忽略密文被恶意修改后仍可能输出垃圾明文。
正确姿势：
- 必须校验函数返回值 == 0；若为 -1，立刻丢弃所有输出缓冲，报错退出
- 解密前确保读取的
nonce和salt长度准确（如sizeof(nonce) == 24），短读会导致越界解密 - 密钥必须用和加密时完全相同的
password+salt+opslimit+memlimit派生，任意一项不同，解密必失败
真实项目里，90% 的“解密失败”问题出在 salt 读取错位、nonce 长度硬编码错误、或忘记把 salt 存进文件头——而不是算法本身。
