该表由（Ubuntu Privacy Remix Team）在分析文档中发布，无论如何我对此表示怀疑。

在基于文件的容器以及完全加密的分区或驱动器上，TrueCrypt 在卷前应用大小为 64 KB 的标头。具有相同结构的第二个标头用于外部容器内可能的隐藏容器。如果没有隐藏容器，则第二个标头填充随机值。此外，卷的末尾还有两个大小和结构相同的备份标头。对于系统加密，隐藏卷的第二个标头和两个备份标头被省略。同样在这种情况下，标头只有 512 个字节。在 6.0 之前的 TrueCrypt 版本中，没有备份标头，标头大小仅为 512 字节。

TrueCrypt 标头的前 64 个字节是随机选择的盐值，未加密存储。从这个盐值和密码导出密钥，通过该密钥对标头的其余部分进行加密。由于这些事实，TrueCrypt 标头就像以下卷一样无法与随机值区分开来。从 4.2a 版本开始，TrueCrypt 标头的格式在 5.0、6.0 和 7.0 版本中发生了 3 次变化。下表指定了 7.0 和 7.0a 版本中 TrueCrypt 标头的格式。

如本表所述，Windows 版本的 TrueCrypt 7.0a 与 Linux 版本不同，它用随机值填充标头的最后 65024 字节，而 Linux 版本则用加密的零字节填充。从安全分析的角度来看，Windows 版本的行为是有问题的。通过对解密的标头数据的分析，无法区分这些确实是随机值还是带有后门密码的主密钥和 XTS 密钥的第二次加密。从源代码的分析我们可以排除这是一个后门。然而，为了源代码的可读性，这种以稍微不同的方式做同样事情的代码重复是一个很大的障碍。它当然也必须妨碍代码的可维护性。

后门的存在是正确的，这真是太可惜了，我已经使用这个软件一年了。任何人都可以通过“否认”或“批准”上述主张来表明观点。