Quantifying the TrueCrypt volume header weakness

[LOVEINT]

Can someone point me in the right direction on how to quantifying the TrueCrypt volume header weakness? VeraCrypt was one of the first to address this issue, however for existing TC volumes that are already "out there", has anyone (I see the audit didn't cover this) been able to quantify the weakness and how easily it can get brute force cracked?

[WaywardGeek]

I would be interested in this as well. I haven't looked at what VeraCrypt does, but it certainly makes it harder to open a volume when all the parameters a user selects to set up the volume are encrypted. The Phase I audit recommended adding plain-text parameters to the volume header. However, I think that goes against the TrueCrypt goal of hiding volumes, and being able to claim they are not TrueCrypt volumes.

The fields in the encrypted header may be a bit stale, but from a security point of view I haven't read about any issues. I think other projects have possibly improved their volume formats vs TrueCrypt, and we'll want to take a good look at what they've done. The Windows implementation does have an error in how it generates the pseudo-random data used in the header, and it is possible that a hidden volume might be detectable because of this, but there is currently no attack I know of that would result in detecting the hidden volume. The Phase I audit found this, and we'll fix it. There are some dumb things in the header. For example, it has a CRC-32 checksum rather than something stronger like SHA1 or better. There's a similar problem with the key files, which result in a CRC code rather than something stronger. For compatibility, we'll need to stay backwards compatible, but an update is warranted, I think.

[rocki]

For example, it has a CRC-32 checksum rather than something stronger like SHA1 or better. There's a similar problem with the key files, which result in a CRC code rather than something stronger.

CRC-32 is a good decision for the volume header hash.
We don't need a cryptographic secure hash here,
rather we need a checksum optimized for best error detection rate.

I mean in case of a cryptographic secure hash you cannot mathematically proof that e.g. H(0x00) and H(0x01) are not collisions which produce the same hash.
(the hamming distance is only 1, hence 1 bit was flipped in the plaintext...)
With crc32 you can be absolutely sure that you will detect this error (detects ~99,9999% of all errors and 100% of special cases).

It does not protect against intentional alteration of data, but it's stored encrypted so it's just fine...

Keyfiles:
It's a merkle damgard construction based on crc32!
TrueCrypt reads up to 1MByte then calculate a crc32 for each byte and fills the 64byte XTS keys with a crc32 cyclic cross sum.
I don't see a flaw in here...

https://github.com/CipherShed/CipherShe ... les.c#L261

[eaglgenes101]

I think maybe we can make it so if it's encrypted with a more secure key derivation function, the initial derived key fails but has a recognisable pattern that encodes a method of stronger key derivation and its parameters. Then Ciphershed 7.3+ can recognise this pattern, read it, and go on with the stronger key derivation method to decrypt the drive.

[rocki]

the initial derived key fails but has a recognisable pattern that encodes a method of stronger key derivation and its parameters. Then Ciphershed 7.3+ can recognise this pattern, read it, and go on with the stronger key derivation method to decrypt the drive.

We can't encode anything into the key! Even if we could, this would reduce the key strength!
The (header) key is derived through a KDF using a cryptographically secure hash algorithm.

bCrypt for example stores the number of rounds used for key derivation unencrypted like the salt.
This is okay for normal password hashing.

However, TrueCrypt also allows hidden (deniable) volumes so we can't store any non-random unencrypted data in the header.
TrueCrypt already supports multiple KDF's for backward compatibility, it's not a problem to add different parameters or new KDF's.

TrueCrypt also makes use of a async ThreadPool (if supported) to speed up the different KDF's.

https://github.com/CipherShed/CipherShe ... ool.c#L158

[WaywardGeek]

CRC-32 is fine for the volume header. However, it's use for 2nd factor authentication through keyfiles should be depriciated in favor of stronger cryptographic hashes. This paper is where I read about the keyfile weakness due to use of CRC-32:

https://www.privacy-cd.org/downloads/tr ... sis-en.pdf

It doe not appear to be a critical flaw. However, it belongs on the list of stuff to be fixed.

[rocki]

Read the answer from the TrueCrypt developer mentioned in the paper!
I fully support his opinion:

"No matter what keyfile processing algorithm is used, if the attacker can modify the content of your keyfile before you create your volume, he can reduce the entropy/strength
of the keyfile."

Code: Select all

“Hello,
First, thank you for reviewing our software–we really welcome and appreciate all independent reviews. It should be noted that when we designed the keyfile processing
algorithm, we had been very well aware of the properties of the CRC-32 algorithm that you mentioned in the document.
Below is our response to the attack you reported to us:
No matter what keyfile processing algorithm is used, if the attacker can modify the content of your keyfile before you create your volume, he can reduce the entropy/strength
of the keyfile. Just as you cannot allow an attacker to modify or prepare your password
when you create a volume, you cannot allow an attacker to modify or prepare your keyfile before you create your volume, either. Otherwise, if you do that, you cannot reasonably expect to have any security.
It is a basic security requirement that cryptographic keys (whether passwords, keyfiles,
or master keys) must be secret and unknown to attackers. Your attack violates this
requirement and is therefore invalid/bogus.
This is valid whether you use CRC-32 or HMAC-SHA-512, whether you use the TrueCrypt keyfile processing algorithm or something different.

Thank you again for taking the time to review our software. We hope that the mistakes
will be corrected before the review is published (publishing an invalid attack would be
misleading).

Sincerely,
David

PS - Even if the attack was valid (it is not) and a cryptographically secure hash
(such as HMAC-SHA-512) was used instead of CRC-32 (your suggested fix), the attacker
would still be able to 'crack' your keyfile by a comparatively short brute force attack
(it would only be slightly slower, as the attacker would merely have to find the correct keyfile among the thousands or millions of keyfiles he crafted).”


[WaywardGeek]

As I said, it does not seem to be a critical flaw. However, an attacker might lull you into using keyfiles that all have CRC32 0, and thus no contribution to the derived key. For example, if you are a wedding photographer for someone who you know has a fat bitcoin wallet, you could easily modify all the digital photos, in the hope that one or more of them will be used as key files. After getting a copy of the TrueCrypt encrypted wallet, you only need to do a single brute-force password guessing attack, rather than doing it once for each reasonable combination of wedding photos. If SHA256 had been used, there would be no way to cancel out the impact of key files on the derived key, and the photographer would have to try every reasonalbe combination of photos for each password guess.

There are various security models for evaluating attacks. David points out that he assumed the attacker has no access to *any* key material. That is a reasonable assumption, but we can do better. We should try to maximize security under the assumption that an attacker has access to some of the key material, and could even manipulate it. Obviously, if he has *all* the key material, we're not going to be able to derive a key with any security, but we should do our best to offer good security in the case of some compromised key material.

[rocki]

This is nonsense...

Assume you want to create a new truecrypt container
and I'm the attacker and I give you the plaintext password or keyfile.

Does it make a difference if the password or keyfile gets hashed by crc32, sha-256 hash or sha-512 hmac or a KDF that needs 100 petaflops per attempt?
*NO*, it doesn't make any difference as long as the attacker knows the plaintext password.
This attack is completely invalid/bogus!

You don't need to bruteforce anything if you know the plaintext password...
Even if the attacker is not exactly sure which prepared password / keyfile will be used,
all he needs to do is to try all passwords / keyfiles which he generated for you!

"That is a reasonable assumption, but we can do better."
Try to fix a invalid security model? ...

[eaglgenes101]

The thinking is if you can force them to spend longer on each password, it'll take longer for them to test each possible password. Because people are kinda predictable, but not enough that guessing a password is an easy task (we hope, at least, that people using ciphershed aren't just using 1234567890qwertyuiopasdfghjkl for their password)