DPAPI加密必须用CryptProtectData而非CryptProtectMemory；密文需Base64编码后存储，解密需严格匹配用户上下文、entropy及DATA_BLOB完整性，并管控文件权限与进程上下文。
DPAPI 加密必须用 CryptProtectData，别碰 CryptProtectMemory
Windows DPAPI 的本地加密能力集中在 CryptProtectData 函数上，它专为持久化敏感数据（如 API 密钥、密码、token）设计；而 CryptProtectMemory 只在内存中临时加密，进程退出即失效，不能用于配置文件存储。
调用前需链接 crypt32.lib，且必须在 Windows 平台（不跨平台）。常见错误是传入空 pszDataDescr 或忽略 pOptionalEntropy 参数——后者虽可为 nullptr，但若跳过，相同用户下任意程序都能解密，等同于裸加密。
-
CryptProtectData返回的密文是二进制DATA_BLOB，需序列化为 Base64 或十六进制字符串写入配置文件，不能直接写 raw bytes（易被截断或破坏） - 若需“同机器不同用户不可互通”，必须传入非空
pOptionalEntropy（比如硬编码 salt 字符串转为BYTE[]），否则仅靠用户凭据保护，域环境或管理员账户可能越权访问 - 返回的
pDataOut需手动LocalFree()，漏掉会内存泄漏
解密时 CryptUnprotectData 失败的三大主因
90% 的解密失败不是因为密钥丢失，而是调用上下文不一致：
— 进程以不同用户身份运行（比如服务跑在 LocalSystem，但配置由交互式用户加密）
— 加密/解密时 pOptionalEntropy 值不完全一致（大小写、BOM、末尾 \0 都算差异）
— 读取密文时未完整还原原始 DATA_BLOB（Base64 解码后长度不对、字节顺序错乱）
- 务必检查
CryptUnprotectData返回值，失败时调用GetLastError()— 常见错误码：ERROR_INVALID_DATA（blob 损坏）、ERROR_NOT_FOUND（用户凭据不可用，如离线域账户）、ERROR_ACCESS_DENIED（权限不足或 entropy 不匹配） - 解密后得到的
DATA_BLOB中pbData是LPBYTE，需按原始编码（如 UTF-8）转成std::string或std::wstring，别直接 reinterpret_cast - 不要在 DLL 的 DllMain 中调用 DPAPI，可能触发 TLS 初始化死锁
C++ 封装成 RAII 类时，DATA_BLOB 生命周期最易出错
DPAPI 接口全用 DATA_BLOB* 传参，内部内存由 Windows 分配（LocalAlloc），必须用 LocalFree 释放 — C++ 对象若把 pbData 直接存为 std::vector<byte></byte> 就断开了所有权链，导致解密后 LocalFree 调用失败或重复释放。
通过 SSH 隧道从 Android 设备在互联网上对 Windows PC 实现完整远程控制的设置与使用指南，适用于远程桌面访问、安全 RDP 等。
- 正确做法：类内只存原始
DATA_BLOB成员（非指针），构造时初始化为 {0}，析构时检查pbData != nullptr再调用LocalFree(pbData) - 加密函数返回
std::string（Base64 编码后的密文）而非裸DATA_BLOB，避免暴露 Windows 内存管理细节 - 若需支持多次加解密，每次调用
CryptProtectData前必须重置输出DATA_BLOB为 {0}，否则残留指针会导致LocalFree(nullptr)或野指针
配置文件明文泄露风险比加密逻辑更致命
DPAPI 本身安全强度足够，但实际落地时，95% 的密钥泄露来自配置文件权限失控：普通用户目录下的 JSON/INI 文件默认允许同组用户读取，而 DPAPI 不阻止这种读取 — 攻击者拿到密文后，只要在同一用户上下文启动进程就能解密。
立即学习“C++免费学习笔记（深入）”；
- 写入配置前，必须调用
SetFileSecurity锁定文件 ACL，至少禁用GROUP_WORLD和EVERYONE的读权限 - 避免把密文存在
%APPDATA%下的公开子目录（如MyApp\config.json），优先用%LOCALAPPDATA%+ 自定义子路径，并设为隐藏属性 - 如果应用以服务方式运行，DPAPI 默认不可用（无用户会话），此时必须改用
CryptProtectData的CRYPTPROTECT_LOCAL_MACHINE标志，但代价是本机所有用户均可解密 — 这种场景建议直接用证书+CAPI，而非 DPAPI
DPAPI 不是黑盒保险箱，它是把密钥托管给 Windows 登录凭据系统。真正决定安全边界的，是你有没有控制住密文的访问路径、进程执行上下文和文件系统权限 — 这些地方出问题，再正确的 CryptProtectData 调用也救不了。
