this table was published by (Ubuntu Privacy Remix Team ), in an analysis document, anyway i was quite skeptical.
On file based containers as well as on completely encrypted partitions or drives TrueCrypt applies a header with a size of 64 kilobytes in front of the volume. A second header with identical structure follows for a possible hidden container within the outer container. If there is no hidden container this second header is filled with random values. Moreover, there are two backup headers of the same size and structure at the end of the volume. For system encryption the second header for the hidden volume and the two backup headers are ommited. Also in this case the header has only 512 bytes. In TrueCrypt versions before 6.0 there were no backup headers and the header size was only 512 bytes.
The first 64 bytes of a TrueCrypt header are a salt value selected at random which is stored unencrypted. From this salt value and the password the key is derived by which the remainder of the header is encrypted. Owing to these facts a TrueCrypt header just as the following volume can't be distinguished from random values. Since version 4.2a the format of TrueCrypt headers changed three times with the versions 5.0, 6.0 and 7.0. The following table specifies the format of a TrueCrypt header in version 7.0 and 7.0a.
As remarked in this table the Windows version of TrueCrypt 7.0a deviates from the Linux version in that it fills the last 65024 bytes of the header with random values whereas the Linux version fills this with encrypted zero bytes. From the point of view of a security analysis the behavior of the Windows version is problematic. By an analysis of the decrypted header data it can't be distinguished whether these are indeed random values or a second encryption of the master and XTS key with a back door password. From the analysis of the source code we could preclude that this is a back door. For the readability of the source code this duplication of code which does the same thing in slightly different ways was however a great impediment. It certainly must also hamper the maintainability of the code.
its quite of a shame for a backdoor presence to be correct, Ive been using this software for like a year. can any one make a point by "denying" or "approving" the above claims.