This project has moved. For the latest updates, please go here.

AES-NI instructions

Topics: Users Discussion
Aug 24, 2015 at 5:04 PM
If we assume that Intel cpu's AES-NI instructions are somehow back-doored and the hardware acceleration is not switched off via the settings menu, then:

If using double or triple cascading including the backdoored AES, ie AES-Blowfish, AES-Serpent, AES-Serpent-Blowfish, etc..... will that decrease the security model below the level of the unaffected remaining algorithm(s)? In other words, which will be stronger:
AES-Serpent or Serpent? AES-Blowfish or Blowfish?
Sep 6, 2015 at 10:25 PM
If you assume that AES-NI is backdoored, then using it in a cascade will not decrease the security below the level of the remaining algorithm(s), provided that AES is not in "direct contact" with the plain text: This means avoiding the two cascades Serpent(AES) and Serpent(Twofish(AES)).
Sep 10, 2015 at 12:47 AM
Why wouldn't Serpent(Twofish(AES)) be just as effective? An attacker would first have to compromise Serpent and then Twofish before getting to the backdoored AES.
Sep 10, 2015 at 4:43 PM
Edited Sep 10, 2015 at 5:01 PM
astrid92 wrote:
Why wouldn't Serpent(Twofish(AES)) be just as effective? An attacker would first have to compromise Serpent and then Twofish before getting to the backdoored AES.
Actually the correct cascade order for Serpent(Twofish(AES)) is plaintext -> AES -> Twofish -> Serpent

I know it looks confusing reading left-to-right. Mounir is using mathematical notation to improve the readability of the order of the cascade.
Sep 10, 2015 at 6:51 PM
Yeah, I understand that. What I'm saying is that an attacker would have to work in reverse, cracking Serpent and then Twofish in order to reach the backdoored AES. So I don't understand why idrassi / Mounir is saying to avoid that cascade to avoid potential AES backdoors.
Sep 10, 2015 at 8:33 PM
The original question was about backdoor in CPU's AES-NI instructions not AES in general.
In this context, the backdoored instructions should not be in direct contact with sensitive data.
Sep 10, 2015 at 8:59 PM
So suppose we use AES(Twofish) with backdoored AES-NI, but not touching the plaintext..... then we have the Twofish guarding our security... fine...... but what happens if bruteforcing the password, which (the password) has to be somehow divided for both AES and Twofish... right? so in other words, cascading, in case one of the algorithm fails (either backdoored or just weak), then cascading is trimming the security by trimming the password itself. Am i right?
Sep 10, 2015 at 9:30 PM
Edited Sep 10, 2015 at 9:35 PM
Each of the cascaded ciphers uses its own key. All encryption keys are mutually independent (note that header keys are independent too, even though they are derived from a single password – see the section Header Key Derivation, Salt, and Iteration Count).

The encryption key is not derived from your password. Only the header key. The header key contains your encryption key that is used for on-the-fly encryption/decryption. When you create a volume you are asked to randomly move your cursor. This is for the encryption key (master key) and the header key.

That is why you can change your password and you do not have to decrypt/re-encrypt the volume since the password change only affects the header key.
Sep 10, 2015 at 9:44 PM
Edited Sep 10, 2015 at 9:49 PM
yes, thats clear, but it makes no difference.... the key which is derived from your password is crippled if you are using cascading :) no matter how you call this key :)

nobody can make N independent keys from a single password and to retain the entropy of the original password in all of these "sub"keys.... call them independent if you want....
Sep 11, 2015 at 1:19 AM
Edited Sep 11, 2015 at 2:12 AM
Read at the bottom of Header Key Derivation link I provided on how TrueCrypt/VeraCrypt creates the header keys for cascade. The documentation provides an example of three cascades and how the header keys are created for each cascade that should alleviate your concerns. :-)

If this was an issue, I would have expected the audit of TrueCrypt that was performed in 2014 and 2015 to raise the alarm.
Sep 11, 2015 at 9:51 AM
Edited Sep 11, 2015 at 9:53 AM
excerpt from the documentation:

"...the header key derivation function is instructed to derive a 768-bit encryption key from a given password... The generated 768-bit header key is then split into three 256-bit keys..."

So lets say the user has chosen a 90 bit random/entropy password... fine, 90 bits is not that bad for a password, especially with the multiple iterations performed..... so in a SINGLE layer encryption.... this 90 bits password is mixed with salt and through hash function (iterated) is produced 256 bit key. So far so good.... but for bruteforce attack, the keyspace that has to be tried/exploited is still 90 bit.... (or 89 bit on average).... thats where the iteration effect comes handy as it increases the required attempts to bruteforce the PASSWORD (in our case 90 bit long)..... Bruteforcing the 256 bit RESULTING key is not feasible anyways so we dont talk about it..... 256 is simply way too much .....

So the question is: does the WHOLE initial password (all of its bits) take part in EACH of the derived sub-keys? or only part of the password produces each derived subkey? I am afraid, that either way, if cascading encryption is used, if one of the algorithms fails, this will definitely weaken the remaining layers for brute force attack. Because either the password needs to be split in 2 or 3 parts for use in the different cyphers (which would be catastrophic) or there will be mutual dependencies between the different subkeys (which is also bad thing).
Sep 11, 2015 at 4:50 PM
Just to make sure we are both understand the difference between hash and encryption keys, the password is not used in any form for the encryption key for AES, Twofish or Serpent. The purpose of the password, PIM and keyfiles only affects the header key which contains the encryption key for a specific encryption algorithm.

For a three cascade encryption algorithm, the one password, PIM and any keyfiles plus salt is put through the hash of your choice (SHA-512, SHA-256, Whirlpool) to create a 768-bit encryption key which is only used for the header keys.

For non-system volumes, using the same password, another different 768-bit key is generated for the embedded secondary header key which is then divided into the three secondary header keys.

Per the documentation, the 768-bit key is divided into 256-bit header keys for each of the cascade encryption algorithms. Meaning, the whole password created the 768-bit key that is divided into three header keys.

AES -> Has its own header key of 256-bits.
Twofish -> Has its own header key of 256-bits.
Serpent -> Has its own header key of 256-bits.
Hence, even when an adversary has one of the keys, he cannot use it to derive the other keys, as there is no feasible method to determine the password from which the key was derived (except for brute force attack mounted on a weak password).
Here is how the mounting takes place in the link below. Yes it is technical, however the documentation describes the process of elimination TC/VC performs to determine if it has the correct password, PIM and keyfiles (if used).

Hope this helps.
Sep 11, 2015 at 5:45 PM
Enigma2Illusion, if your initial password (= the password which the user enters) is say 90 bit "random"...... from that moment on.... whatever you do.... no matter how you hash it, split it, whatever magic you do with it..... the entropy/randomness of the password REMAINS 90 bit. No matter that all resulting header keys, encryption keys, etc are derived to be 256, 768, etc bits. I will give you an example, if my password is "A" it is 8 bits random.... then you can hash "A" through sha256, you can hash "A" with sha512 and you can hash "A" with Whirpool.... Assuming that all these 3 hash functions produce 256 bit output (not sure about that, but it doesnt matter), then you will get 3 hash results (completely different looking) and if you concatenate these 3 hash sums you will get 768 bit random looking result/key. But the resistance of the password itself, is only 8 bits. No matter what you do with it it will be no more resistant than 8 bits - thats it! You can design hash function that will take your "A" password and will produce 100000000 bit long output, but who cares..... :)

So now, suppose you use the above mentioned 768 bit key (derived from the simple "A") to separate it into 3 different cascades (how the separation is done doesnt really matter) and one of these 3 encryption fails..... then your 8 bits will sunk even further down.

Thats my point :)
Sep 11, 2015 at 8:22 PM
Edited Sep 11, 2015 at 9:44 PM
Hello Alex,

I was in complete agreement with your statements until the last paragraph. I agree with you that a deterministic hash cannot change the password entropy.

But then you said that if one of the three hashes fails, the entropy is lower. What is the nature of the hash failure that would change the password entropy?

Using your example of password "A" and cascade of three which results in one 768-bit header key being split into three 256-bit keys still has the same password entropy bits/letter since you need all three separate hash keys to tell you that the password is "A".

To make sure we are discussing the same issue. There is only one hash algorithm being used in the cascade versus the three encryption algorithms used in the cascade.

Kind Regards.

For those that might be interested, Mounir has posted on the topic of password length and its entropy that would be worth reading.
Sep 11, 2015 at 10:40 PM
Edited Sep 11, 2015 at 11:18 PM
Hi Enigma2Illusion,

What i mean is that if an adversary brakes one of the cascading algorithms, then he has obviously found the "plain text" (which is not really plain as it is encrypted by the other 1 or 2 layers of different ciphers), but if he does so, the bad guy will be in possession of the plaintext and the ciphertext so he will probably be able to calculate the key used for the broken layer of encryption (which is still not so easy, but is still feasible)... so in short, he will now know 1/2 (in case of double cascade) or 1/3 (in case of triple cascade) of the hash value of your initial password - the code braker's dream :)

So now, with some intelligent approach, bruteforcing your initial password will not require going the lenght of all available keyspace and in my opinion, may be very trivial..... and the question arises here: is multiple cascading for that reason as strong as the strongest cipher? or is as weak as the weakest cipher as i am trying to congesture?

I will give you another example to PROVE my point..... suppose you have 99 very bad encryption algorithms and one very good one (say AES)..... then you encrypt by cascading all these algorithms with one password which might be very good one, say 128 bits. So in our theory, you are safe right? even if all these 99 algorithms fail, your AES will still be guarding your secrets? No way...... the attacker will now know 99% of the hash value of your password.... bruteforcing it , with a little bit of brain, will be a peace of cake..... and there goes your AES.... decrypted with the correct password :)

in my opinion, the only guarantee to count on the strength of multiple encryption is to make the password X2 (X3) longer/stronger than we would usually use for single cipher...... otherwise it all hangs in the air :)

p.s. so my thoughts to the opening post, if AES NI (even if it does not touch the plain text, as Mounir suggests) is backdoored then a multiple encryption (i.e. AES-Serpent) is worse than a single one (i.e. Serpent) as AES NI will steal a chunk of your password's hash result and disclose it to the bad guy ....
Sep 12, 2015 at 1:32 AM
Hello Alex,
... even if all these 99 algorithms fail, your AES will still be guarding your secrets? No way...... the attacker will now know 99% of the hash value of your password....
This is where I differ with your analysis.

The password is protected by the hash algorithm, the number of iterations of the hash plus the salt and not the encryption algorithm(s). Hence in your example, breaking the 99 low security encryption algorithms means that the attacker acquired your encryption keys which does not expose the header key nor the password. Of course, once they have the encryption keys from the 99 bad encryption algorithms, they only need to focus on the remaining good one by trying to hack the password unless vulnerability exists in AES encryption. :-)

To get the password, the attacker would need to break the hash algorithm via brute forcing the password and/or keyfiles. Attempts to brute force the hash which includes the salt and possibly keyfiles would not be feasible due to the higher iterations that VeraCrypt performs for the hash in comparison to TrueCrypt and makes brute forcing very time consuming.

In summary using your example, the attacker would have to either break the hash algorithm with the high number of iterations plus salt or they find some way to grab the encryption keys from memory or swap file.

I agree with you that anything is possible if your hardware/software has been compromised on your system which is included in the documentation.

Kind Regards.

PS: Thanks for being courteous during the debate. :-)
Sep 12, 2015 at 10:04 AM
Edited Sep 12, 2015 at 10:27 AM
Hi Enigma2Illusion,

I disagree with you on your last post. Nothing has to be compromised in my theory (it might be, but is not prerequisite), i only say that IF one of the cascading algorithms is weak and is therefore broken, then the attacker will MOST PROBABLY be able to reveal that part of the hash value of the password which takes part in the encryption of the failed cipher. Once he has done so, he will now has a very serious clue and he will most probably be able to perform an attack on the other ciphers as he will know part of the hash (which part takes part in forming of the other part of the hash used for the other ciphers), which is a very, very serious security concern (as the different parts of the hash results are RELATED, and they have to be related as the resulting hash is 768bits, while we assume the feeding password is a "normal" one, about 80-90 bits). The iterations are only making the process a bit slower and the salt prevents using precomputed tables, so they will not stop the attacker. You are mentioning key files and indeed if keyfiles are use then the feed entropy is large enough so this is ok. My idea is however that if a "normal/usual" password is used with entropy of say upto 80-90 bits (which is ok for single layered encryption), then this presents a serious security risk if used in cascading and one or more of the ciphers (though not all) fail. To maintain the security of the multiple encryption model, the user should be forced (or at least advised) to either use keyfile(s) or use much longer/stronger password. When i was younger and used to go out, my grandma used to tell me that i cant feed all the girls with one salary (although i was also trying to "hash" my 80 bit salary and "derive" 768 bits out of it, but that didnt work at the end) :) Similarly, you cant feed 3 ciphers with one password and keep on believing that the model is as strong as the strongest cipher at least - i congesture this statement is wrong :)

p.s. i am not saying such an attack is trivial, but in cryptography, even the smallest weakness can be exploited to an unimaginable depths.....
Sep 12, 2015 at 10:46 AM
Edited Sep 12, 2015 at 10:49 AM
Enigma, after I read my post above, I also have hard times understanding exactly what I am trying to say..... so I fully understand your confusion :)
Let me try another visualization.... imagine you have a key for your door and it is 10 cm long (with all these bumps on the key blade that adjust the pins of the lock in order to open it). So in a single layer encryption (locking), you just insert these 10 cm in your lock and if the pins match, the door is opened. Now imagine, you want 2 doors instead of 1, so you put 2 doors, but in order to lock them you simply cut your 10 cm key in half and you make 2 keys 5 cm each (you can make some magic, hashing, whatever you want to call it, but as long as your original key is 10 cm long, there is little that can be done). And now the bad guy succeeds and opens your first door.... Do you think your second door is as safe as if it has been locked with your 10 cm key? :)

p.s. I will surrender to your logic if you can tell me a way where if you have 10 cm key for your door and you can make 2 keys out of it and each of those 2 keys is as secure as the original key and at the same time these 2 keys are totally independent! (And of course your way of making these keys is known to the thief (as is the encryption software open source or at least can be reversed engineered)
Sep 12, 2015 at 1:27 PM
Edited Sep 12, 2015 at 1:28 PM
Enigma is correct. The salt used is not something weak like the letter "A" - it is 64 bytes of randomness. 64 * 8 = 512 bits. Add to that the high number of VeraCrypt iterations, plus PIM, plus keyfile, and THEN add to all that whatever additional strength comes from the password... To extend Alex512's salary analogy, the VeraCrypt hashing process is the equivalent of receiving social benefit payments which are added to your salary, thus enabling you to feed all the girls even on a low salary!
Sep 12, 2015 at 1:31 PM
commenter8, the salt is used only to prevent precomputed hash results and to avoid similar hash results from equal passwords.... the salt itself is available to the attacker in its original form :) I am afraid you didnt get the core of the problem, cant blame you, i confuse myself as well, with my own thoughts..... but still, i insist on what i have said :)
Sep 12, 2015 at 5:57 PM
Alex512, your door key analogy fails because the user password (equivalent of the indentations on the key) is not used directly. If it were, then the strength of each encryption key would of course be less than the strength of the original key. The password is instead salted and then sent through the header key derivation algorithm, which then produces the header encryption key and secondary header key. This highly processed final result is what gets split. You cannot take only the first third of the header key and the first third of the secondary header key (the encryption passwords for a single algorithm) and use that to work backwards to the user password.

Your argument is essentially that there might be a way to use those fragments to work backwards to the user password, even though you seemingly haven't found any way to do that. So in order to prove your case, what you need to do is either post a comment or publish a paper which gives an algorithm for using these fragments to work backwards to the user password in significantly less time than would be necessary if those fragments were unavailable.
Sep 12, 2015 at 8:12 PM
Edited Sep 12, 2015 at 8:22 PM
commenter8, you are somewhat misunderstanding the basics with the salt and iterations.... salt is used only to make the hash output of each password unique. If no salt is used, and I and you chose the same password, then the resulting hash of our 2 identical passwords will be the same.... salt makes them different.... but salt does NOT provide any additional entropy to the password itself! The only small additional entropy is the user chosen number of iterations (introduced in VC 1.13, if password>20 characters), but this is really a minor entropy add on. The many iterations themselves, only slow the process of bruteforcing down, but they do NOT provide any more entropy to the password.....

My analogy above with the door key is absolutely correct i am afraid. To make it fit even your logic with the salt and iterations, let me give you some more options to solve the problem:) You are allowed now to modify the initial 10 cm key anyway you want, you can add more bumps and make some cutoffs, you can do whatever you want to enhance it you can extend the blade and add more bumps and cuts, the only condition is that everything you do HAS TO BE KNOWN TO THE THIEF..... (same as the salt, salt is known to the attacker as well as the algorithm the password derives the encryption key(s))..... so after you modify your 10 cm key, leave the instructions on how you have done it on the door for all to read and make from your modified and enhanced key another 2 keys..... and prove me they are BOTH as secure as the original one and at the same time totally INDEPENDENT :) Good luck, you might need it.....


P.S. The more I think the more confident i am in my conjecture and that is:

In multiple cascading block cipher, if the entropy of the user password is smaller than the entropy of the sum of the entropy of all encryption keys for each individual cipher together, then the strength of the cascading encryption is NOT as strong as if the encryption was done by the strongest cipher used alone with the same user password.
Sep 12, 2015 at 10:08 PM
Edited Sep 12, 2015 at 10:17 PM

A cryptographic hash function is a hash function which is considered practically impossible to invert, that is, to recreate the input data from its hash value alone. These one-way hash functions have been called "the workhorses of modern cryptography".[1] The input data is often called the message, and the hash value is often called the message digest or simply the digest.

The ideal cryptographic hash function has four main properties:
  • it is easy to compute the hash value for any given message
  • it is infeasible to generate a message from its hash
  • it is infeasible to modify a message without changing the hash
  • it is infeasible to find two different messages with the same hash.

Thus, the use of cryptographic hash functions, which are considered practically impossible to invert, provides the security. If you believe you can indeed invert, please exhibit your inversion algorithm. Without it, you have no case.