本地文件加密实践：给敏感文件上一把锁

给文件加密这个话题，很容易滑向两端：一端是”我没什么要藏的”，另一端是”上军用级加密”。实际上大多数人的需求落在中间——笔记本丢了不要紧、别人借用电脑别乱翻、网盘同步上去的东西别被看光。把这个需求想清楚，方案反而简单。

一、先定威胁模型

动手之前先回答三个问题，这决定了后面所有的技术选择：

防谁？ 防的是”顺手翻看”（同事、家人、维修人员）还是”有预谋的攻击者”（拿到你的硬盘慢慢试）？前者口令加密就够，后者要考虑口令强度和离线爆破。

防什么？ 防误看、防丢失、防未授权访问，是三个不同的目标。防丢失靠备份，加密反而会让”数据找不回来”的风险变大——口令忘了，加密文件就是一堆随机字节。

代价是什么？ 加密必然带来摩擦：多输一次口令、工具链更复杂、分享文件更麻烦。摩擦要控制在”你能长期坚持”的程度，否则方案一定会被绕过——把文件解出来放桌面”临时用一下”，然后就再也没加密回去。

我的结论是分层处理：少量真正敏感的文件上强加密，大量”内部工作文件”用轻量口令加密挡误看，两者分开管理。

二、对称加密与口令派生

本地文件加密几乎都是对称加密：同一个口令（或密钥）加密和解密。AES-256、ChaCha20 这些算法本身没有实际的攻击面，安全性的真正战场在口令如何变成密钥，也就是密钥派生函数（KDF）。

直接把口令当密钥用是不行的。口令的熵值太低（人能记住的通常是 8~12 个字符），而 AES 的密钥需要 256 位随机性。KDF 的作用是把低熵口令”拉伸”成高强度密钥，同时故意把计算做得慢：

PBKDF2：迭代哈希，实现简单、到处都有，缺点是内存占用小，GPU 爆破友好。
bcrypt：老资格，有成本参数，但输出长度受限。
scrypt：引入内存开销，抬高硬件爆破成本。
Argon2：2015 年密码哈希竞赛的胜出者，同时调时间和内存开销，是当前的推荐选择。

选型上的实用建议：工具支持 Argon2 就用 Argon2；只支持 PBKDF2 就把迭代次数拉高（几十万次这个量级）；同时把口令本身弄长——12 位以上的随机口令或四个随机词组合，比任何 KDF 调参都管用。KDF 是补偿口令熵值不足的手段，不是替代品。

三、压缩包加密的强度边界

用 zip/7z 的口令加密是最大众的入口，它的定位要摆正。

传统 zip 的 ZipCrypto 是上世纪的设计，存在已知的结构性弱点（明文攻击），能抵抗的只是”随便试试”级别。7z 的 AES-256（含加密文件名选项）在算法层面是扎实的，强度基本等价于”口令的强度”。

压缩包加密的真实边界在于：

它是可离线攻击的。 拿到加密包的人可以无限次尝试口令，没有锁定、没有告警。所以口令强度是唯一的防线。

它不隐藏元数据（部分场景）。 zip 加密默认不加密文件名，对方能看到包里有什么，只是打不开内容。7z 可以勾选加密文件名，藏得更干净。

它不适合超长期归档。 十年后还能不能找到解压工具、口令有没有记录在可靠的地方，这些运维问题比算法问题更现实。

所以压缩包加密适合的场景是”传输一次、用完即弃”或”中短期归档”，不适合做机密的最终防线。

四、加密容器与整目录方案

比逐文件加密更工程化的做法是加密容器：创建一个大文件，内部是虚拟文件系统，挂载后像普通磁盘盘符一样读写，卸载后整体是密文。

容器方案的好处很直接：

文件级元数据一并隐藏——不加密时挂载着用，加密时别人看不到目录结构。
增删改是常态操作——不需要”解密→修改→重新加密”的往返。
可以做隐藏卷——一个容器两个口令，两层数据，用于胁迫场景（这个是进阶需求，多数人用不到）。

代价是使用习惯的改变：要记得挂载、记得卸载、杀毒软件对容器内文件的扫描会变慢或失效、云同步会把整个容器文件当一个大文件反复上传。

如果不想要”挂载”这个概念，还有一类整目录加密工具：输入口令后目录里的文件透明加解密，密文落在另一个目录里。适合”这个文件夹不许别人看”的朴素需求，交互比容器轻。

我自己对”批量文件上锁”这种需求，是在 7AA7工具箱的文件加密功能里做的——选一批文件、设口令、输出加密件，用完解密回原位。它属于上面说的”轻量口令加密”层，防误看和防未授权够用，真正机密的东西我会再套一层专业加密容器。

五、密钥与口令管理

加密体系里最脆弱的永远是人这一环。几条实践中总结的原则：

口令不要”发明”，要”生成+记录”。 用密码管理器生成 16 位以上随机口令，记在管理器里。加密文件的口令丢了等于数据丢失，这比弱口令更常见也更致命。

口令和加密文件不要放一起。 明文写在同目录的 密码.txt 里，等于没加密。至少分开放：文件在本地，口令在密码管理器或另一台设备。

重要口令要有传承方案。 急病、意外时家人拿不到口令，加密就成了数据的坟墓。可以考虑把主口令封存在可信的物理位置（信封、保险柜），或者使用管理器的应急访问机制。

定期验证。 半年做一次演练：按记录的方式真的解密一个测试文件。很多”记录完好”的口令，实际是记错的、或者工具版本变了派生参数不匹配。

六、加密之后，备份不能停

一个容易被忽略的事实：加密不防损坏，也不防丢失。磁盘坏了，密文一样找不回来；手滑删了，加密解不了这个问题。

正确的姿势是加密和备份两条腿走路：

加密文件照常进备份（加密件本身是安全的，可以放心落到任何备份介质）。
口令的备份单独管理（见上一节的传承方案）。
备份要验证可恢复——备份里存的加密件能不能解出来，不试一次是不知道的。

还有个反直觉的点：加密会放大误操作的代价。明文文件删了还能从回收站、从编辑器缓存、从备份历史里捞；加密件解密后散落的临时明文，才是最需要清理的。解密操作后检查临时目录、回收站、云同步目录有没有明文残留，是加密流程的收尾动作。

加密是手段，数据可用性是目的。方案要让”安全”和”拿得到数据”同时成立，缺一边都不叫好的实践。