ProtectedData 不能用于加密文件路径，它加密的是数据块且绑定用户或机器，加密后二进制字节非合法路径字符串；应加密文件内容而非路径，推荐使用 AesGcm 并妥善管理密钥。
Windows 上用
做本地文件路径加密不靠谱
直接说结论：
不能用于加密文件路径本身，它加密的是数据块，且绑定用户登录会话或机器密钥。你试图“加密路径字符串”再拼进
，结果要么解密失败，要么路径非法——因为加密后是二进制字节，不是合法路径字符。
真正该加密的，是文件内容；路径只是定位器，应保持可读、可管理。强行加密路径只会让日志、调试、备份全乱套。
路径加密混淆 ≠ 安全：攻击者拿到磁盘镜像后，只要能执行同用户进程，
立刻解密
、
这类 API 都要求输入是合法 UTF-16 字符串，加密后的
转成 Base64 后虽“看起来像字符串”，但长度爆炸、含斜杠/加号，极易触发
或路径遍历误判
跨机器、跨用户迁移文件时，
加密的内容基本不可恢复
文件静止态加密：用
加密内容，别碰路径
静止态（at rest）加密，核心是让文件内容即使被复制走也无法解密。.NET 5+ 推荐用
——它自带认证，防篡改，比手搓
更安全。
关键点不是“怎么藏路径”，而是“怎么让加密密钥不硬编码、不存明文”：
密钥必须来自外部：用 Windows DPAPI（
）加密主密钥，再把加密后的主密钥存配置文件；或由 Azure Key Vault / HashiCorp Vault 提供运行时密钥
每次加密生成新
（12 字节），和密文一起写入文件头（前 12 字节），解密时原样读取
不要复用
：同一密钥下重复
= 密文可被破解
示例片段（简化）：
传输中加密：HTTPS 或 TLS 就够了，别自己实现文件流加密
如果文件通过网络传输（比如上传到 Web API），加密责任不在 C# 文件 IO 层，而在传输协议层。自己在
上套一层 AES，反而可能破坏 HTTP 分块、断点续传、代理缓存等机制。
C知道
CSDN推出的一款AI技术问答工具
下载
正确做法是：
服务端用 HTTPS（TLS 1.2+），客户端用
直接发原始
，由 TLS 底层加密整个 TCP 流
若必须走 HTTP（如内网无 TLS），则用
：先用
加密文件内容，再 POST 到 /upload —— 此时服务端需配套解密逻辑，且密钥协商必须独立于文件流（比如 JWT Header 带加密后的密钥 ID）
避免在
上手动包装
：容易卡死、缓冲区错位，且 .NET 的
不支持异步流式加密（
可能阻塞）
路径本身要“可控”，不是“不可见”
真正需要保护的，从来不是路径字符串，而是路径所指向的访问权限。Windows ACL 和 .NET 的
才是正解。
例如，敏感文件放
，然后：
用
移除 Users 组默认继承权限，只保留 SYSTEM 和指定服务账户
禁用共享，关闭 SMB 签名弱策略
日志里记录所有
失败事件（配合 Windows 审计策略），而不是靠路径“看不出名堂”来蒙混
路径中避免硬编码敏感信息：
比
更安全——前者无法反推身份，后者一目了然
最常被忽略的一点：加密密钥的生命周期管理比算法选择重要十倍。一个被遗忘在
里的 AES 密钥字符串，比用
加密的文件更危险。
ProtectedDataProtectedDataFile.OpenReadProtectedData.UnprotectDirectory.GetFilesPath.Combinebyte[]ArgumentExceptionProtectedDataAesGcmAesGcmAes.Create().CreateEncryptor()ProtectedDatanoncenoncenoncevar key = GetKeyFromVault(); // 返回 32 字节 key
var gcm = new AesGcm(key);
var nonce = new byte[12];
RandomNumberGenerator.Fill(nonce);
var ciphertext = new byte[data.Length + 16]; // 16 字节 tag
gcm.Encrypt(nonce, data, ciphertext, out _);FileStreamHttpClientFileStreamApplication-Level EncryptionAesGcmNetworkStreamCryptoStreamCryptoStreamWriteAsyncFile.SetAccessControlC:\ProgramData\MyApp\Secrets\DirectorySecurityFile.Openuser_12345.datalice_pswd_backup.encappsettings.jsonDES