1

I am currently working on a project where I am trying to replicate the header encryption and decryption logic of TrueCrypt in Java. I have some uncertainties regarding the key generation, distribution, and usage of the XTS mode. Notice that my understanding so far is based on the documentation, which in my opinion can be quite ambiguous at times.

Further Background (Technical specifications)

File Format Structure: https://www.andryou.com/truecrypt_orig/docs/volume-format-specification/

Encryption: https://www.truecrypt71a.com/documentation/technical-details/encryption-scheme/

Header Key Derivation: https://www.truecrypt71a.com/documentation/technical-details/header-key-derivation-salt-and-iteration-count/

Cascades: https://www.truecrypt71a.com/documentation/encryption-algorithms/cascades/

XTS-mode: https://www.truecrypt71a.com/documentation/technical-details/modes-of-operation/

My understanding so far:

  1. Assuming there are no key files the PBKDF2 function (Password-Based Key Derivation Function 2) uses the user password and a salt to generate a header key. Depending on the chosen hash algorithm (HMAC-SHA-512, HMAC-RIPEMD-160, HMAC-Whirlpool), PBKDF2 is executed either 1000 or 2000 times.
  2. For the simple cascade (e.g., just AES), I understand that a 512-bit key is generated, which is then split into two 256-bit keys. The primary and secondary keys respectively.
  3. Notice XTS mode, means for each algorithm a primary and secondary key of 256-bit each are needed.

My questions:

  1. For triple cascades (e.g., AES-Twofish-Serpent) in XTS mode: Is a single 1536-bit key generated by PBKDF2 and then split into two 768-bit keys (primary and secondary key) which are further divided into three 256-bit keys per algorithm? Or are two separate 768-bit keys (primary and secondary key) independently generated by PBKDF2 and then those two are split into three three 256-bit keys per algorithm? I would appreciate any help or pointers

  2. Furthermore, based on the file structure specification in the documentation listed above, the 64-byte salt is not encrypted but the rest of the header (which goes up to and including byte 511) is. But the XTS mode says that it always works on a 512-byte data unit. If it starts after the salt, the encryption will cut into the middle of the reserved field, which could be encrypted or not (but this refers to the entire field, not just a part of it). So does encryption and decryption work on the first 512 bytes, including Salt or does it start after Salt. In other words, at what offset (0 or 64 or something else) is the first plaintext block encrypted and until when (511 or 576 or something else) is encryption done?

Improve this question
2
  • Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Commented Nov 16, 2024 at 8:47
  • Please specify what you mean. The problem is clearly defined and is header key generation in TrueCrypt and the Encryption procedure. Commented Nov 16, 2024 at 11:14

1 Answer 1

Reset to default
2

If you want to replicate how TrueCrypt works, then the best reference is the actual source code. The documentation may be a good starting point, but it isn't nearly detailed enough to really understand the exact steps.

To answer your questions based on the code:

  1. All key material is generated in a single PKBKD2 invocation. TrueCrypt calculates the maximum key size of all encryption algorithms which support the selected mode (like XTS) and then doubles it to have enough key material for the concatenated primary and secondary key (if XTS is used). Cascaded encryption counts as a single encryption algorithm, so the primary and secondary key each include all the subkeys for the individual ciphers like AES, Twofish and Serpent.
  2. Header encryption covers 448 bytes (512 − 64), starting at offset 64 (just after the salt) and ending at offset 512 (after the concatenated primary and secondary master keys). Note that AES-XTS supports arbitrary input lengths: If the plaintext length isn't a multiple of the block size, then a sufficiently long part of the previous ciphertext block is “stolen” and appended to the plaintext. Hence the name “XEX Encryption Mode with Tweak and Ciphertext Stealing”.
Improve this answer
3
  • Thanks a lot. I will have a look at source code. However, regarding answer two, how would it cover 448 Bytes of encryption, if the XTS modes operates on data units of 512 Bytes which are divided in 128 Bytes block. (source: truecrypt71a.com/documentation/technical-details/…) Commented Nov 16, 2024 at 8:06
  • @BinomialBear: AES-XTS supports arbitrary input length, and that’s really the whole point of the mode. The “S” stands for “Ciphertext Stealing”: If the last plaintext block is shorter than the block size, then XTS “steals” part of the previous ciphertext block and appends it to the plaintext, so that the plaintext length is always a multiple of the block size. See this diagram for a good visualization. Commented Nov 16, 2024 at 8:52
  • Ok, thanks a lot for pointing that out. I really struggled understanding it before. Finally, I can continue working on my project and incorporate what you just taught me. Have a good day then. Commented Nov 16, 2024 at 11:19

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.