只有通过代码审查和测试。

迭代中的更改确实可能使代码的这些区域对暴力破解更具弹性，但迭代只是需要考虑的整体架构的一部分。

来自项目维护者...（归功于此线程）

VeraCrypt 不仅通过增加迭代次数来增强原始 TrueCrypt 的安全性，而且还解决了迄今为止在源代码中发现的所有严重的安全问题和弱点。这些弱点的一个很好的列表可以在 https://opencryptoaudit.org/reports/iSec_Final_Open_Crypto_Audit_Project_TrueCrypt_Security_Assessment.pdf中找到

我们在 git 提交中记录了这些安全更改。重要的从“Windows 漏洞修复”和“静态代码分析”开始。如果 Open Crypto Audit 项目，我将使用该列表：

1. Weak Volume Header 密钥派生算法：自 VeraCrypt 诞生以来就已修复。从 2014 年起，任何安全专家都会告诉您，PBKDF2 应该与至少 10000 次迭代一起使用，以获得高安全性，并结合强密码。1000 计数来自 2004 年并且已经过时，这就是 Open Crypto Audit 将其列为第一个漏洞的原因。在 VeraCrypt 中，自 2013 年以来，我们选择了非常高的迭代次数来满足日益增长的安全要求，希望在未来 10 年内。

2. 引导加载程序解压器中的多个问题：已在 git 中修复，并将在 1.0f 版中发布。由于引导加载程序的大小要求，这非常具有挑战性。我们必须优化许多部分的代码大小，以便为解压缩器的修改腾出空间。

3. Windows 内核驱动程序使用 memset() 清除敏感数据：自 1.0e 版以来已修复 TC_IOCTL_GET_SYSTEM_DRIVE_DUMP_CONFIG 内核指针泄露：自 1.0e 版以来已修复

4. IOCTL_DISK_VERIFY 整数溢出：自 1.0e 版以来已修复

5. MainThreadProc() 整数溢出：自 1.0e 版以来已修复
6. MountVolume() 设备检查绕过：自 1.0e 版以来已修复
7. GetWipePassCount() / WipeBuffer() 可能导致 BSOD：自 1.0e 版以来已修复

此外，已经使用两个静态代码分析器工具检查了 VeraCrypt 源代码，它们报告了许多已解决的问题（以“静态代码分析”开头的提交）。最耗时的部分之一是完全重写字符串操作代码，以便使用安全字符串函数而不是易受攻击的 string.h 函数（在用户模式和内核模式下）。其他修复包括：

• 纠正内存泄漏
• 在解析可以利用的语言文件时修复潜在的溢出。
• 修复可被劫持的非绝对 DLL/进程负载（Microsoft 安全公告 2269637）。

虽然我们继承了 TrueCrypt 的大部分代码，但我们引入了许多修改和更正，大大提高了整体安全性。当然，大多数这些修改对普通用户来说是不可见的，但安全专家可以轻松检查代码的当前状态并验证我们的方法。

我借此机会宣布，我们已经能够为系统启动加密（200 000 次迭代）实施 SHA-256 密钥派生。TrueCrypt 一直只支持 RIPEMD-160 用于系统分区加密，这显然需要升级，因为老化的 RIPEMD-160 即使不存在针对它的公开攻击。由于引导加载程序的不同限制（代码大小、内存），这不是一件容易的事，我们必须在 VeraCrypt 格式化程序中引入优化和新的引导加载程序管理，以便能够支持 RIPEMD-160 和 SHA-256同时。

我们将很快发布包含此 SHA-256 的 VeraCrypt 1.0f 测试版，以便获得用户的反馈。

对于那些想知道为什么我们为引导加载程序实现 SHA-256 而不是 SHA-512 的人，答案是不可能在引导加载程序的 16 位环境中实现 SHA-512，因为它需要 64 位操作' 不能有效地分解为 16 位操作。另一方面，SHA-256 使用 32 位操作，即使我们失去性能，也很容易适应 16 位环境。

瞧瞧……我希望我能够回答您的问题并展示 VeraCrypt 如何成为 TrueCrypt 的安全替代品。

干杯，