VeraCrypt：从 TrueCrypt 走来的成熟开源全盘加密

学习目标

读完本文你应该能够：

• 说清 VeraCrypt 与 TrueCrypt 的传承关系，以及它在审计发现之上补了哪些安全增强
• 解释卷头（Volume Header，即数据卷的头部）、主密钥（Master Key）和 PBKDF2 三者如何配合，隐藏卷为什么能成立
• 判断什么场景适合 VeraCrypt、什么场景它其实不合适
• 说清「为什么普通用户应该从官网下二进制、而不是自己编译」这条看似啰嗦的建议背后是什么
• 在 Linux / macOS / Windows 三端大致知道它的形态差异与编译门槛

目录

• 它解决什么问题
• 相对 TrueCrypt 的核心安全增强
• 平台矩阵与二进制分发
• 它是怎么工作的
• 源码编译的门槛
• 适用与不适用
• 落地时的三个注意点
• 常见问题与排查
• 自测题
• 练习
• 继续深入
• 相关资源

它解决什么问题

「全盘加密」（Full Disk Encryption，FDE）要防的是一个很具体的威胁：设备丢了、被偷了、送去维修了，盘里的数据不能被人直接读走。操作系统里的文件权限挡不住物理接触——把盘拆下来挂到另一台机器上，权限形同虚设。FDE 在更底层解决这件事：数据落盘前就加密，开机时由用户密码解开，没密码的人拿到盘也只能看到密文。

veracrypt/VeraCrypt 是这类方案里少有的开源实现。它从 TrueCrypt 7.1a fork（派生）出来，在 TrueCrypt 2014 年突然停更后由 IDRIX 接手并持续演进，目标很克制：「在保留 TrueCrypt 7.1a 全部能力的基础上，修复已公开的安全问题」。这种偏底层的 C / C++ 系统软件不会有 ML（机器学习）/ Agent（智能体）类仓库的曝光度，但凡是要在多平台上正经做 AES（Advanced Encryption Standard，高级加密标准）加密卷、隐藏卷、系统盘加密的人，VeraCrypt 都是绕不开的参考实现。

相对 TrueCrypt 的核心安全增强

TrueCrypt 7.1a 停更后，社区做了一次官方审计（2014 年的 Quarkslab 审计），结论是「未发现 NSA（美国国家安全局）后门」，但仍指出若干要修的问题。VeraCrypt 从 TrueCrypt fork（派生）之后重点补的就是这些：

• PBKDF2（Password-Based Key Derivation Function 2，基于密码的密钥派生函数 2）迭代次数大幅提升：TrueCrypt 时代只有 1000 次，VeraCrypt 的官方默认基准约为系统盘加密 200000 次、普通卷 500000 次（实际随所选哈希算法和 PIM 调整）。迭代次数直接决定对密码暴力破解的抵抗强度——次数越高，每次试密码的成本越大。
• 引导加载器修复：替换旧版 Boot Loader，补齐若干启动路径上的潜在弱点。
• 卷格式演进：在 TrueCrypt 卷格式之上引入更现代的哈希选项（如 SHA-512、Whirlpool）和若干边信道缓解。
• Windows 驱动签名：64 位 Windows 上 .sys 驱动必须签名才能加载，VeraCrypt 的官方二进制由 IDRIX 使用的代码签名证书签名。README 里有一条常被忽略的细节：官方二进制总会比你自己编出来的体积大约 10 KiB，多出来的就是完整的签名链。

平台矩阵与二进制分发

三端能力基本等价：

三端共享同一套卷格式（.hc，以及旧 .tc 后缀的 TrueCrypt 文件），跨平台可读——你在 Linux 上开的加密卷，挂到 macOS 上照样能读，反过来也一样。这正是它作为「可移植加密容器」的价值：加密卷是个文件，U 盘一插，换平台不换格式。

它是怎么工作的

VeraCrypt 在内核层做的是「设备级透明加密」：

• 加密卷以「虚拟设备」形式出现，例如 Windows 上的 \\.\VeraCryptVolumeX，macOS / Linux 上的 /dev/mapper/veracrypt_xxx；
• 所有读写都经过 AES、Serpent、Twofish（三种都是对称分组密码）或其级联组合。VeraCrypt 最多支持三种算法级联，而 TrueCrypt 只支持两种；
• 卷头（Volume Header）保存主密钥（Master Key）的密文形式，用「用户密码经 PBKDF2 派生出的密钥」解开主密钥。主密钥本身在写卷时不会以明文出现在磁盘上——这正是隐藏卷（Hidden Volume）能成立的前提：存在「正常」和「隐藏」两个卷头，挂载时输入哪个密码，就解开对应的那个卷头；
• 隐藏操作系统（Hidden OS）则把第二套启动分区藏进加密容器，用不同密码对应「诱饵系统 / 隐藏系统」两层身份。

这些机制本身与 TrueCrypt 一脉相承，VeraCrypt 的增量改进主要在 PBKDF2 强度、加密算法选项和若干边信道缓解上。理解「卷头存的是主密钥的密文、而非你的密码」这一点，很多设计就顺了：你改密码只是换了解开主密钥的那把钥匙，主密钥本身可以不变，所以不用重新加密整个卷。

源码编译的门槛

README 第二段就写明：「你可以使用本仓库的源码，但必须接受 License.txt 中的条款。」其中一条关键限制：派生作品不得继续使用 “TrueCrypt” 或 “VeraCrypt” 名称——这是项目自我保护的法律边界，想拿代码做二开得另起名字。

跨平台编译大体遵循类似流程：

# Linux
make           # 默认目标
make WXVERSION=3.2
sudo make install

# macOS
make SYSCTL=0

# Windows
# 需 Visual Studio + 把 WSDK81 环境变量指向 Windows 8.1 SDK
# 详见仓库 doc/html/en/CompilingGuidelineWin.html

其中 Windows 端难度最高：必须正确配置 WSDK81 环境变量和数字签名——这也是「Windows 用户应当从 veracrypt.fr 直接下官方二进制、而不是自己编译」的根本原因。自己编能跑，但你要自己搞定签名链，否则 64 位驱动加载不了。

适用与不适用

适合

• 跨多 OS 的机器需要统一加密体验；
• 内部分发场景里，只在少数几台受信任的机器间交换加密卷；
• 对「全盘加密 + 隐藏卷」有合规 / 取证对抗需求的安全团队；
• 想研究「经典 FDE 工程实践」的学习者。

不适合

• 期望企业级集中管理：VeraCrypt 不带集中控制台，企业 IT 想下发策略要么靠 GPO 这类外部手段，要么换 BitLocker + MBAM 这类偏企业生态的方案；
• 期望云原生：它解决的是「本地设备物理丢失」问题，对象存储 / SaaS（软件即服务）不在它的射程内；
• 把「自己编译」当信任根：README 已经把「二进制签名」的必要性写得很清楚，官方签名链足以验证可信度，普通用户没必要重复造轮子。

落地时的三个注意点

第一，备份卷头。 卷头里存着解开主密钥所需的材料，卷头损坏等于整个卷打不开。VeraCrypt 提供「备份卷头」功能，存一份到安全的地方，比备份密码本身更关键。

第二，密码强度决定一切。 PBKDF2 迭代次数再高，也救不了 123456。FDE 的抗暴力破解上限就是你的密码熵，弱密码下再多的迭代也是纸糊。

第三，隐藏卷要提前规划。 隐藏卷是事后往「正常卷的空闲区」里塞的，如果正常卷已经写得很满，就没有空间藏隐藏卷了。要做隐藏卷，正常卷得留出足够的「看起来没用」的空闲空间。

常见问题与排查

Q1：VeraCrypt 是 Apache 2.0 吗？

不是。它用的是「VeraCrypt 许可证」（VeraCrypt License），由 TrueCrypt License 衍生而来，既不是 Apache 2.0，也不兼容 OSI 批准的通用开源许可证。这条许可证里明确限制：派生作品不得使用 “TrueCrypt” 或 “VeraCrypt” 名称。商用或二开前务必读 License.txt。

Q2：为什么普通用户不该自己编译 Windows 版本？

64 位 Windows 加载 .sys 驱动要求有效签名。自己编译出来的二进制没有 IDRIX 的签名链，要么加载不了，要么你得自建签名体系。官方二进制已经签好，下载即用，还能用签名验证完整性。除非你有特定的合规或审计理由，否则从官网下更稳。

Q3：加密卷能在不同系统间互读吗？

能。三端共用同一卷格式，.hc / .tc 文件跨平台可读。这也是它作为可移植加密容器的核心价值。

Q4：忘了密码还能恢复吗？

不能。没有后门、没有重置入口，这是 FDE 的设计前提。能做的只有用卷头备份 + 正确密码。所以「卷头备份」和「密码管理」是两件必须提前做好的事。

Q5：隐藏卷会被发现吗？

隐藏卷的设计目标是「 plausible deniability（可否认性）」：从外部看它只是一块正常卷里没用到的空闲区，没有独立特征能证明隐藏卷存在。但它成立的前提是正常卷确实留有空闲空间，且你从未把正常卷填满到暴露「还有空间」的程度。

Q6：系统盘加密会影响性能吗？

有开销，但通常落在可用范围内。加解密在磁盘 I/O 路径上做，现代 CPU 的 AES-NI 指令集能把对称加密加速到接近裸盘。真正的瓶颈更常出现在老硬件、满载 I/O 或机械盘上，而不是算法本身。

自测题

概念题

1. FDE 要防的威胁到底是什么？为什么操作系统层的文件权限挡不住这个威胁？
2. 卷头里保存的是主密钥的明文、还是主密钥的密文？「改密码」时到底改了什么，为什么不用重加密整个卷？
3. VeraCrypt 的许可证和 Apache 2.0 是一回事吗？派生作品在命名上有什么限制？

场景题

4. 你手里有一块 VeraCrypt 加密卷，密码记得，但盘体磕了一下之后挂载失败。请判断最可能丢的是什么、有没有救、日常该怎么做才能避免这种局面。
5. 你打算给团队做隐藏卷方案，用于应对「设备被收缴时被迫交出密码」的取证场景。请说明隐藏卷成立的前提条件，以及正常卷使用上要注意什么才不会露馅。
6. 一个 Windows 用户坚持「自己编译更可信」。请指出这句话在 64 位驱动加载这件事上错在哪，并给出正确做法。

选型题

7. 下面哪个场景该用 VeraCrypt，哪个该换方案：公司 5000 台笔记本要统一下发加密策略并接受集中审计；研究员在三台 Linux / macOS 机器间用 U 盘交换加密实验数据；创业团队想把对象存储里的用户文件加密。

练习

1. 在任一平台装好 VeraCrypt，新建一个小型测试加密卷（比如 50 MB），练习挂载、写入文件、卸载、再挂载，确认流程跑通。
2. 对同一个卷执行一次「备份卷头」，把备份文件存到别处；然后故意用错误密码挂载，观察报错，理解密码与卷头的关系。
3. 新建一个带隐藏卷的容器：先建正常卷并留足空闲空间，再在其中创建隐藏卷，验证两个密码分别打开的是不同内容。
4. 读一遍仓库里的 License.txt，把「派生作品不得使用 VeraCrypt / TrueCrypt 名称」这条限制记下来，思考如果你要二开它会怎么命名。
5. 用 veracrypt --text 命令行（Linux / macOS）挂载同一个卷，对比 GUI 与 CLI 的参数差异，写出一条可复用的挂载命令。

继续深入

能答对上面大部分自测题后，可以往这几个方向走：

• 读 VeraCrypt 官方文档里「Volume Format Specification」一节，搞清楚卷头结构、盐值（salt）和迭代次数在格式里怎么排布
• 理解 PIM（Personal Iterations Multiplier）如何抬升迭代次数，以及它和密码强度之间的权衡
• 对比 VeraCrypt 与 LUKS / BitLocker 的威胁模型差异：前两者面向「设备丢失 + 可否认性」，BitLocker 更贴企业集中管理
• 研究 AES-NI 等硬件加速指令对 FDE 吞吐的实际影响，判断你目标硬件上加密的开销是否可接受

相关资源

• 仓库：https://github.com/veracrypt/VeraCrypt
• 官方网站与二进制下载：https://www.veracrypt.fr
• 官方文档：https://documentation.veracrypt.fr
• 编译指南（仓库内）：https://github.com/veracrypt/VeraCrypt/tree/master/doc/html/en
• 许可证：仓库内 License.txt（VeraCrypt License，由 TrueCrypt License 衍生，非 Apache 2.0）