This project has moved and is read-only. For the latest updates, please go here.

Cascading Algorithms Possibly Pointless & More Insecure

Topics: Feature Requests, Technical Issues, Users Discussion
Apr 30, 2015 at 11:12 PM
I get the point of cascading algorithms in the sense that in the future an attack could be formulated on one of the algorithms but if the keys are all derived from one single password it defeats the point. Shouldn't it be possible to set a unique password for each layer of encryption? I also read that cascading can lead to a side-channel attack against any one of the algorithms in the cascade leading to the ineffectiveness of the encryption scheme. These problems would be avoided if we could set a password for each algo.
Apr 30, 2015 at 11:54 PM
From the manual below, each algorithm has its own independent encryption key derived from the password and each encryption key is unique for each algorithm in the cascade. Hence, any weakness for using a password would affect both single and cascade encryption algorithms.
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).
May 3, 2015 at 12:02 AM
What I'm getting at is that if the first layer encryption password is cracked using an ASIC or a massive array of parallelized computers in a giant building to get the password then the extra layers are useless whereas with separate passwords for each layer would make this much more difficult. This almost makes a cascade seem useless doesn't it?
May 3, 2015 at 1:14 AM
Thank you Tom. Now I understand what you are requesting and your reasons for making this request.
May 3, 2015 at 12:05 PM
I find the conclusions expressed in this discussion far fetched.
The documentation explains very well the security objectives behind cascading and how the keys are independent from each other, but the discussion in this thread is mixing two different things:
  • Using a password to derive a key stream
  • Cascading different algorithms that use independent keys.
You seem to consider that cascading algorithms is a meant to strengthen key derivation. This has never been mentioned anywhere and it is clearly not true: the cost of brute forcing a password doesn't depend on the used encryption mechanisms but on the password entropy and the PBKDF2 number of iterations (it is very easy to demonstrate this fact).

Cascading is meant to protect against any unknown vulnerability in one of the ciphers that may enable an adversary to retrieve the master key without knowing the password (this can be for example a vulnerability in the S-Box that leaks the key or a chosen plain-text attack). This is a realistic scenario for offline encryption where data is stored encrypted for many years and a breakthrough attack can be discovered during this long period. By layering 2 or 3 different ciphers using independent keys, cascading provides a protection against this type of attacks at the expense of performance.

Last point to clarify: even of the keys are generated from the same password, they are mathematically independent since they are copied from different parts of the key stream generated using PBKDF2: this is one of the foundation of the security of PBKDF2 and its proof is based on the security properties of the underlying hash algorithm.

It is important to define the attack model before evaluating the security of a design or a system. In this discussion, their was a confusion between two different elements of the design which led to the false statement about the strength of cascading ciphers.

As a conclusion, cascading is not pointless and it is not insecure. It is the best approach for the long term security of stored encrypted data.
May 3, 2015 at 7:15 PM
Cascading may also increase security by making it difficult to know when the password has been found. The attacker must not only guess the password correctly, but also either correctly guess or brute-force the algorithm combination. Suppose that AES is the outer shell of a triple-encrypted cascade and that the attacker thinks only AES is being used. Even when the attacker correctly guesses the password, the decrypted information is not plaintext but rather encrypted text. At this point the attacker can falsely conclude that the guessed password was incorrect, and move on to try the next possible password. Alternatively, the attacker could expand the brute-forcing to include all combinations of algorithms (AES, TwoFish, Serpent, AES-Serpent, AES-TwoFish, AES-Serpent-TwoFish, AES-TwoFish-Serpent, etc.), which will then increase the difficulty of the brute-forcing attack by a factor of about 20.
May 3, 2015 at 9:33 PM
Edited May 3, 2015 at 9:36 PM
Okay, that's all good information. It still leaves a couple of questions. Can it be assumed that a brute force attack against an outer layer where the correct password is used and underlying encrypted data is discovered that it would actually show as a false positive? Assuming that someone has physical access to my drive they will know that veracrypt is being used. Does this mean that they will be able to detect that they have guessed the password since if they use the correct password it will show them a new layer of encryption where they will be able to detect the next layer's algorithm? If that is possible they will know they've guessed the correct password so is that possible?

I do understand the benefits of cascading as defined in the context of Veracrypt but let's say the correct password is cracked on an outer AES layer (Either through brute force or a discovered weakness), they know I'm using Veracrypt, and they know I could be cascading. As I was eluding to before, wont they know if they've obtained the proper passphrase? Meaning can't they detect the difference between data encrypted with the algorithms used in Veracrypt? This would mean that if they try the correct password and then see Serpent encrypted data or plaintext data they will know they've found the correct password and can then just enter the password into veracrypt and mount the drive unencrypted.

Finally, even if some of the things I've described aren't possible, wouldn't the option of using a custom password for each layer in the cascade strengthen the encryption scheme regardless? In my mind this would greatly increase the security...

Imagine a scenario where there's a building with an enormous array of computers like I mentioned before. They take an image of my drive and load it into their system. They know that Veracrypt is being used so they use their systems to simply brute force the password prompt or image until they see plantext data since the password leads to the decryption of each layer in the cascade.

I know that you can argue the cascade will increase security in a scenario where one algorithm has a weakness but isn't it true that a custom password for each layer would indeed greatly increase security given the previous scenarios I've mentioned where their system figures out it's guessed the password? Because if they know they've guessed the user-defined password the entire cascade will then be decrypted whereas a custom password for each layer would surely prevent that. That must be correct.
May 6, 2015 at 6:59 PM
Edited May 6, 2015 at 7:05 PM
Tomashley I think you are underestimating the power of the encryption algorithm. You refer to this "array of computers in a building" brute forcing your password and then gaining access to your data. If you are using a complex password with a large number of characters (no I don't mean 8 or even 16 characters) and proven encryption algorithms like AES that "array of computers" you speak will take many lifetimes to crack by a brute force attack. There is however a simple fix to your concern about the cascading. Simply create cascaded encrypted volumes within themselves and use a different algorithm and password for each. That way if they "crack" the outer volume all they have gained access is to ANOTHER encrypted volume using another unknown encryption algorithm and another unknown password. You could continue to nest these volumes until you feel you've reached the level of security you feel you need. This really isn't necessary and its severe overkill but if you are the tin foil hat type maybe that will suffice.

Moral of the story here is a long strong complex password is your best defense against unauthorized access.
May 7, 2015 at 1:13 PM
I want to thank cyberfed for pointing out the strategy of using nested cascaded encrypted volumes to achieve any desired level of security :)

Idrassi - if this is not in the VeraCrypt user manual already, I'd like to request that it be explicitly pointed out there...

I've created a new issue here:

Everyone, please click to and vote for this issue if you agree with me that cyberfed's strategy is something that all users should be aware of... thanks!!
May 7, 2015 at 1:24 PM
cyberfred posted
  • Simply create cascaded encrypted volumes within themselves and use a different algorithm and password for each. That way if they "crack" the outer volume all they have gained access is to ANOTHER encrypted volume using another unknown encryption algorithm and another unknown password. You could continue to nest these volumes until you feel you've reached the level of security you feel you need.
Оh, this is a truly GREAT idea!
So obvious, but I've never thought about it.
Thank you very much, cyberfed.
May 7, 2015 at 2:12 PM
I'm aware of the benefits of using long complex passwords. This nesting though couldn't be done on a system drive though right?
May 7, 2015 at 2:35 PM
You could not use nesting to protect the operating system on a system drive, but you could use it to protect user data on a system drive.
May 8, 2015 at 6:49 PM
Edited May 8, 2015 at 6:56 PM
Glad to help out guys. I can't take much credit for it though its basically the same principle described by TrueCrypt for creating "hidden volumes". I believe this is already documented in VeraCrypt as well. I took a quick peek at the documentation for VeraCrypt and it appears that yes you can have a hidden OS partition to answer Tom's question. I've never done it nor did I read the whole procedure so take my comments lightly.
May 9, 2015 at 10:37 AM
Nested containers can indeed be seen as a generalization of the hidden volume concept but they bring performance and reliability issues on their own since any written data goes through a stack of device driver instances. For example, the user must dismount volumes in reverse order (LIFO) but VeraCrypt is not aware of the nesting nor the mount order so an auto-dismount can provoke issues or even data loss. This risk can be reduced (but not completely solved) but mounting all volumes in the nested stack as removable media.

Thus, if you are using nested containers, it is advised to disable auto-dismount, mount volumes as removable media and preferably use scripts for dismounting nested volumes in the right order.
May 10, 2015 at 4:22 AM
Hello Mounir,

Is VeraCrypt aware of the dismounting dependencies of mounted file containers that are on mounted on encrypted system and non-system partitions/drives?

Thank you.
May 16, 2015 at 9:38 AM

No, VeraCrypt is not aware of any dismounting dependency as it can't check if the mounted volume contains files that are themselves mounted as volumes (remember that VeraCrypt has no knowledge of the filesystem content).
As I said above, it is the responsibility of the user to ensure that dismounting is done in the correct order.
Jul 11, 2015 at 8:00 PM

Just to correct my previous statement concerning dismounting dependencies: there is one case where VeraCrypt will correctly handle dismounting nested containers and it is when you use "Dismount All" functionality.
In this case, VeraCrypt will dismount all volumes in the reverse order they were mounted and this of course is helpful for nested volumes.

As I said previously, VeraCrypt has no knowledge of nested volumes and the "dismount all" implementation is helpful to cover the lack for specific nested volume support
Jul 11, 2015 at 11:28 PM
I think there are several looming issues VeraCrypt, people are not taking into account. For one there's human intuition, The VeraCrypt boot loader(boot screen) is clearly labeled as such. This immediately gives away the fact that the encryption software you're using is VeraCrypt. Then one need simply google it to get more info, then that immediately defeats purpose of the hidden OS, when it comes to adversaries where absolute certainty is not needed. Like

"Hmm, I wonder why this person has 2 partitions, one roughly 5% larger than the other"

Then they can reasonably suspect there to be 3 different passwords, as that is the default for hidden OSs. And even if you make the size allocation different. That, doesn't change the immediate reasonable suspicion.

I think a option to customize the boot loader text, so it's not so blatantly conspicuous what software you're using would be nice.

I also thought that the hidden os option would be a OS hidden in the same Partition as the system partition as that would be the most intuitive. Although, i do realize as explained by the prompt that, it's not possible with ntfs. Also, i'm curious, how exactly does VeraCrypt manage to install a windows OS in non ntfs partition.

Also, i did think intuitively think cascade was 3 different passwords. Again cascade is pointless when it comes to human intuition.(atleast with system volumes). It's probably reasonable to assume if one is not using AES256 then AES256(TwoFish(Serpent)). In witch case cracking the outershell is all that's needed(as unlikely a feat as that is), since it blatantly advertises itself as Vera Crypt in the boot loader, it's reasonable to assume if more random text is obtained after cracking the outershell, then it's probably cascade, and they should probable just try the password in the bootloader.

Also, I would really like SHA512 to be a available system volume hash. As incase you haven't noticed with BitCoin. There are basically data centers optimized to do nothing but crack SHA256. As with the SHA256 ASICs. Although i'm sure the amount of iterations would keep it secure, with a long passphrase. That is still a looming worry of mine be it unwarranted. Or at-least maybe another 256 hash that's not SHA256.