It is well-known that the CRC-32 algorithm doesn't meet cryptographic standards of a hash algorithm. Therefore cryptographic security can't be expected of the TrueCrypt keyfile algorithm. In fact, we discovered an attack by which any file can be manipulated so that it has no effect at all when added
as a keyfile. For this purpose we only need to append between 1524 and 2804 bytes to the file. There are many applications which don't mind the additional bytes at the end of such a manipulated file and present it's contents just as it was without those bytes. This is especially true for image viewers and image files (for example .jpg and .png files) and for PDF readers (such as the Adobe Acrobat Reader or Evince) and PDF documents.
...
It were three major weaknesses in the TrueCrypt keyfile algorithm which facilitated the attack. The
first weakness was the application of the cryptographically insecure CRC-32 algorithm. Its input
can easily be crafted to yield any desired output. The second weakness was the linearity of the
operations by which the pool bytes were changed, that is the additions. This made the attack a
simple application of linear algebra. The third weakness was the local nature of changes to the
pool. Every byte of the keyfile only changes four bytes of the pool. This enabled us to do the attack
successively making one byte of the pool after the other zero.
Holy crap. Any one of those weaknesses would be ridiculous from a security standpoint. The fact that all three exist is evidence of incompetence, at the very least. (Whether the incompetence is intentional or not is an open question.)
Not using CRC-32 is pretty much cryptography 101. Avoiding linearity is "preventing cryptanalysis 101". Avoiding local changes to the output (i.e. every byte of the keyfile should change the output completely) is called the avalanche effect and is, similarly, an incredibly basic requirement of cryptography. http://en.wikipedia.org/wiki/Avalanche_effect
Here is TrueCrypt's response to the attack:
“Hello,
First, thank you for reviewing our software–we really welcome and appreciate all inde-
pendent 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 con-
tent 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 key-
file before you create your volume, either. Otherwise, if you do that, you cannot reason-
ably 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 True-
Crypt 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 key-
file among the thousands or millions of keyfiles he crafted).”
... and here is the paper's response to their response:
This response is mistaken. It fails to differentiate between the secrecy of a password or key and
the inability of an attacker to modify the password or key. The secrecy of the password and keyfile
is indeed a basic prerequisite for the security of a TrueCrypt volume as it is in any other crypto-
graphic application. However, it is quite possible that an attacker is able to modify a keyfile to a cer-
tain extent while that keyfile at the same time remains perfectly secret and unknown to him. The
point to be considered here is that cryptography has means to provide security even in such a
weird situation.
As an example for such a situation consider an attacker who distributes an image editing software.
He might add our attack algorithm to his software so that it secretly manipulates any image it pro-
cesses to have no effect as a TrueCrypt keyfile. Our algorithm is even small enough to run on
embedded systems. Therefore, even a digital camera might process the pictures it takes and out-
put manipulated picture files. The pictures would nevertheless show what the user wanted and
would remain unknown the the vendor of the camera or the image editing software. So they may
be kept secret although they have been modified by an attacker.
In that situation a keyfile algorithm based on HMAC-SHA-512 would provide perfect security while
the TrueCrypt keyfile algorithm fails completely. A brute force attack would be impossible as the
attacker has not to find the correct keyfile among millions of keyfiles he crafted but among a practi-
cally infinite number of possible pictures which might have been taken with his camera or pro-
cessed with his image editing software.
...
It were three major weaknesses in the TrueCrypt keyfile algorithm which facilitated the attack. The first weakness was the application of the cryptographically insecure CRC-32 algorithm. Its input can easily be crafted to yield any desired output. The second weakness was the linearity of the operations by which the pool bytes were changed, that is the additions. This made the attack a simple application of linear algebra. The third weakness was the local nature of changes to the pool. Every byte of the keyfile only changes four bytes of the pool. This enabled us to do the attack successively making one byte of the pool after the other zero.
Holy crap. Any one of those weaknesses would be ridiculous from a security standpoint. The fact that all three exist is evidence of incompetence, at the very least. (Whether the incompetence is intentional or not is an open question.)
Not using CRC-32 is pretty much cryptography 101. Avoiding linearity is "preventing cryptanalysis 101". Avoiding local changes to the output (i.e. every byte of the keyfile should change the output completely) is called the avalanche effect and is, similarly, an incredibly basic requirement of cryptography. http://en.wikipedia.org/wiki/Avalanche_effect
Here is TrueCrypt's response to the attack:
“Hello,
First, thank you for reviewing our software–we really welcome and appreciate all inde- pendent 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 con- tent 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 key- file before you create your volume, either. Otherwise, if you do that, you cannot reason- ably 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 True- Crypt 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 key- file among the thousands or millions of keyfiles he crafted).”
... and here is the paper's response to their response:
This response is mistaken. It fails to differentiate between the secrecy of a password or key and the inability of an attacker to modify the password or key. The secrecy of the password and keyfile is indeed a basic prerequisite for the security of a TrueCrypt volume as it is in any other crypto- graphic application. However, it is quite possible that an attacker is able to modify a keyfile to a cer- tain extent while that keyfile at the same time remains perfectly secret and unknown to him. The point to be considered here is that cryptography has means to provide security even in such a weird situation.
As an example for such a situation consider an attacker who distributes an image editing software. He might add our attack algorithm to his software so that it secretly manipulates any image it pro- cesses to have no effect as a TrueCrypt keyfile. Our algorithm is even small enough to run on embedded systems. Therefore, even a digital camera might process the pictures it takes and out- put manipulated picture files. The pictures would nevertheless show what the user wanted and would remain unknown the the vendor of the camera or the image editing software. So they may be kept secret although they have been modified by an attacker.
In that situation a keyfile algorithm based on HMAC-SHA-512 would provide perfect security while the TrueCrypt keyfile algorithm fails completely. A brute force attack would be impossible as the attacker has not to find the correct keyfile among millions of keyfiles he crafted but among a practi- cally infinite number of possible pictures which might have been taken with his camera or pro- cessed with his image editing software.