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

Plase add cascades with new hash algorithms

Topics: Feature Requests, Technical Issues, Users Discussion
Aug 17, 2016 at 6:43 PM
Plase add cascades with new encryption algorithms that has been added in the newest release beta 1.18. I want as many as possible cascade encryption algorithms.

Is it possible to cascade several hash algorithms?
Aug 17, 2016 at 11:04 PM
VCuser, I am glad you raised this topic again as I been considering this topic and if cascades should have been ported from TrueCrypt to VeraCrypt for creating new volumes.

Cascading Encryption Algorithms

The developer, Mounir has stated that he is considering how to implement cascading the additional encryption algorithms given the number of permutations increases for each newly added encryption algorithm.

My question to the community is what other encryption software that is not a fork of TrueCrypt uses cascade encryption algorithms? Should VeraCrypt depreciate cascading algorithms by only allowing selection of a single encryption algorithm when a new volume is created?

If cascading is more secure, then why are paid encryption software not offering cascades? The paid encryption software companies could promote their product as being better than their competitors by allowing the users/companies to trade-off performance for the "extra" security of cascade. Has cascading encryption algorithms been false security the whole time due to the popularity of TrueCrypt and people have bought into the idea that somehow cascades are more secure?

Years ago when I researched the topic of cascade algorithms, there were cryptographers that said that cascading can have unintended consequences of partially cancelling out the other encryption algorithms. Remember that these are math equations that may introduce cancelling properties to the other algorithms.

I no longer have the links to present to the community and I do not care to re-research this topic again. I trust that Mounir and his development team have contacts in the cryptography community to help advise them if cascades provide more security and should be included in VeraCrypt for the newer encryption algorithms being added to the software.

Cascading Hash Algorithms

Cascading one-way hash algorithms would not create a more secure result. Also, users would become extremely frustrated at the huge increase in time to mount their volumes.

http://security.stackexchange.com/questions/8940/are-different-hash-algorithms-ever-used-together

https://www.iacr.org/archive/crypto2004/31520306/multicollisions.pdf
Developer
Aug 18, 2016 at 7:42 AM
Cascading is interesting possibility in VeraCrypt.

to Enigma2Illusion: In general I agree with your conclusion. Below some notes.

Current crypto implementation contains the following parts:
1) Encryption - AES, Twofish, GOST89, Camellia, Kuznyechik, Sepent and some predefined combinations
2) The only encryption mode is XTS (for block device encryption)
3) Hash - SHA512, SHA256, RIPEMD160, Whirpool, STREEBOG

Current implementation does not have possibility to configure custom combinations.
Pros for this implementation: simplicity, security, compatibility.
Cons: Lack of extra security flexibility

Personally I like flexibility of software and it would be good to create plugins architecture and extra configuration. But the work is rather complex. Need serious reasons to start the modification.

At present moment I see several pros to start the work:
1) Hardware AES is faster then Twofish or GOST89 almost 10 times. So AES can be whitening for other in combinations AES(TwoFish()), AES(GOST89()) and it does not affect performance significantly.
2) Separate crypto module gives extra possibility for customization.

to VCuser: Could you explain your ideas?
Aug 18, 2016 at 4:22 PM
We got used to "cascading" concept and everyone thinks it's more secure.

I think it's OK to have combinations, specially with algorithms that ARE NOT from the United States.
Aug 18, 2016 at 4:38 PM
Edited Aug 18, 2016 at 4:39 PM
@ Enigma2Illusion
You have a good point. I have looked at other encryption software and asked myself why they don't cascading encryption algorithms. Why would they not offer it if it was more secure.

I don't mind if it takes longer to mount volumes as long it's more secure.


@ kavsrf
The only thing I can do with VeraCrypt is to install and encrypt. No any other skills in encryption. I thought cascading encryption algorithms would be more secure? More layers?



I hope we will see cascading encryption algorithms with the newest algorithms added. Cascading as much as possible. Again, I'm not sure if it's more secure.
Aug 19, 2016 at 1:51 PM
The cascading of algorithms and also of hashes has more value than the simple act of cascading.

It adds complexity and uncertainty to the attacker. If the attacker has no idea of the algorithms used and / or in what order they have been used in, an attacker simply doesn't know where to start.

Password hashing, if a known hash function is used, coupled with a known number of iterations, then the attacker has something to work with. Brute forcing the password can start as the attacker knows exactly what to attack. However, the strength of VeraCrypt over other encryption products is the attacker has no idea which hash function has been used or how many iterations have been employed. To be honest, it is an attackers worst nightmare when it comes to hash cracking.


A personal plea to the developers....

As interesting as it is adding new features to VeraCrypt, something I am all for, PLEASE would the developers look at basic functionality first ? VeraCrypt needs full 4k sector support, I believe this will become a significant issue over the next year or so as more and more hard drives are 4K. We are relying on backwards compatibility of new drives firmware to allow us to use VeraCrypt on large modern drives. I fear manufacturers may not continue their backwards compatibility for much longer.

I love the idea of adding new features and I am as keen as anyone to make suggestions and requests, but basic functionality really should come first.

VeraCrypt has progressed significantly over the last year, many thanks to the developers of VeraCrypt for all your hard work so far, you have made a wonderful program :)
Aug 19, 2016 at 3:15 PM
DBKray:
VeraCrypt needs full 4k sector support, I believe this will become a significant issue over the next year or so

I love the idea of adding new features and I am as keen as anyone to make suggestions and requests, but basic functionality really should come first.
.
Totally agreed, DBKray.
Aug 19, 2016 at 4:03 PM
algreider8 wrote:
Totally agreed, DBKray.
.

Thank you algreider8, it seems we share a passion for VeraCrypt's continued success.

I hope my text above did not seem ungrateful or complaining in any way. I fully appreciate all the work done so far and as I said, I would love to see new features but 4k support is starting to become a necessity for some users.

I simply hope Mounir and the others helping him, do not feel under pressure to add new features to keep the users happy. I believe the core VeraCrypt fans wouldn't mind the next couple of releases to only include bug fixes (if there are any left) and basic capabilities such as 4k support added.

Ideally 4k support would be added before any audit.

Anyway, thanks again and lets keep VeraCrypt number 1 !!!
Aug 19, 2016 at 7:55 PM
Enigma2Illusion wrote:
Cascading Hash Algorithms

Cascading one-way hash algorithms would not create a more secure result. Also, users would become extremely frustrated at the huge increase in time to mount their volumes.

http://security.stackexchange.com/questions/8940/are-different-hash-algorithms-ever-used-together

https://www.iacr.org/archive/crypto2004/31520306/multicollisions.pdf
I do not agree with the above statement, You might want to review https://veracrypt.codeplex.com/discussions/649763 especially my last post there.
Aug 19, 2016 at 9:26 PM
Edited Aug 19, 2016 at 9:29 PM
@Alex512,

I read your last post and you seem to be supporting the statement I made that cascading hash algorithms would not create a more secure result.

I going to guess that most users of VeraCrypt are not cryptographers and just have the idea that if we cascade hash and encryption algorithms that somehow we are more secure. If that is true, then there should be plenty of cryptography papers supporting cascades for either hash or encryption or both.

I have not seen research supporting cascades from credible researchers.

A quick Google search I just performed for encryption cascades are:

https://en.wikipedia.org/wiki/Multiple_encryption#Importance_of_the_first_layer

Matthew Green on Multiple encryption:

http://blog.cryptographyengineering.com/2012/02/multiple-encryption.html

I do not understand the distinction that Mr. Green stated between "simply block ciphers" verses "true encryption algorithms":
A lot has been written about cascade encryption, some good and some bad. The answer to the question largely depends on whether the algorithms are simply block ciphers, or if they're true encryption algorithms (e.g., a mode of operation using a block cipher). It also depends on what security definition you're trying to achieve.
.
Technical paper called "Cascade Encryption Revisited" that you can download or view:
http://link.springer.com/chapter/10.1007%2F978-3-642-10366-7_3
https://eprint.iacr.org/2009/093.pdf

I would like to see research papers that either support or do not support cascades verses unpublished opinions. :-)

@DBKray,

In my opinion, the statement that cascades will impede hackers or government agencies is unlikely. Government agencies will use many methods of infecting your machine with malware to gain access if you are deemed a high value target. Hackers will use custom code to run password attacks to unlock the volume header which is the hash. In VeraCrypt, the hash can use optional keyfiles and custom PIM which will make attacking the header impossible to attack unless the attacker gains knowledge of your keyfiles and/or custom PIM.

http://contest.korelogic.com/

Once the header is unlocked with the correct password, you know the hash and encryption algorithm(s) by using the same procedures that VeraCrypt uses to mount the volume. See the link below.

https://veracrypt.codeplex.com/wikipage?title=Encryption%20Scheme

None of this requires breaking the algorithms. The weakest link is a password (no keyfiles, no custom PIM) and not the hash or encryption algorithms.
Aug 19, 2016 at 10:32 PM
@Enigma2Illusion,

Hi :)

I am not actually certain whether I support cascading hashes or not. I have asked few questions in my referred post, which remained unanswered.

As to cascading encryption algorithms, the situation is quite clear there: If you cascade N different algorithms with N different and completely INDEPENDENT passwords, you can not lose in terms of security if the LAST algorithm is weak (no matter how bad, weak, etc.). If any of the other (previous) algorithms (with exception of the last one) are particularly weak, even if completely independent passwords are used for each layer, you can lose security! So lets say you use 2 layers AES-Twofish, then in WORST case scenario, the result can not be weaker than is AES. This is of course a very conservative, although correct, statement. In reality, if we consider both AES and Twofish NOT particularly weak (or really, really bad), then the result will be most probably as good as AES and Twofish together... which is really strong strong strong.... Still, NO guarantee about the last statement, just a conjecture, which by definition, can not be proved! Probably we can call this conjecture - hope, or trust :)

When it comes to VC, the story is different. It cascades using passwords derived from the user password. This is dangerous! and by definition, UNLESS the user uses password which is N times longer (or has more entropy) than the minimum entropy considered as secure against brute force (i.e. 128 bit) attack, where N is the number of cascading rounds, then it is CERTAIN that there MAY be loss of security! In other words, if with VC, the user uses AES-Twofish with 200 bits password, he would be better off using only AES with 128 bit password. This is on the presumption, that 127 bits can be bruteforced and 128 bit can not, and also that AES is stronger than is Twofish, eventhough Twofish doesnt have to be weak.

In an extreme statement, I dare say, that using VC at the moment with 3 cascading ciphers (the ultimate protection? ) with 128 bit password should be crackable right now, by someone with enough brain and computing resources to bruteforce about 64 bits. By "enough brain" I mean of course, really "enough brain" :))))))))))))
Developer
Aug 19, 2016 at 11:15 PM
Edited Aug 19, 2016 at 11:16 PM
All authorization data is converted to 256 bit key to decrypt header.

Normally password is 512bit.

The following authorization data is used:
  1. text string (size 1..64 bytes)
  2. Salt (256 bit)
  3. PIM
  4. key file
  5. Hash (to create 256 key)
Any sector is encrypted by XTS mode (256bit key withering, 256bit encrypt)
Any cascade algorithm uses different keys.

Where do you see weakness?
Aug 20, 2016 at 3:25 PM
@kavsrf,

The thing is that USER password is not 512 bit (usually). The user password is usually with much lower entropy (or put simply length), lets say 80 bits, which is perfectly OK, bearing in mind the PIM to slow the brute force attack, etc. This is when we speak for single (normal) encryption. If we however take this 80 bit password (which is fine for single layer encryption) and somehow transform it into 512 and then make two 256 bits passwords to use with each encryption layer, then we have a problem. I am not speaking about keyfiles, PIM number, etc. These are additional features.

So what is the problem with having 80 bit password input (by the user) and then making from it two 256 bit passwords for each encryption layer? Quite simple, these passwords MAY (and most probably WILL) depend on each other, which is a major security concern (attack in the middle?, and many other possible attacks). In an extreme scenario the output passwords can be completely independent, but this can be achieved in one way only - by splitting the original password in two, thereby making two 40 bit passwords for each encryption layer (not a good option neither). Whatever other mambo jambo VC does with the original user password, it can never make 2 passwords of at least the same quality. You can for example hash the 80 bit password to make 512 bit output, which you can divide in 2... but you can also hash 2 bits to a 1024 bit output, so what? Security suffers immensely.

It is of course not so simple, passwords are hashed, so it will be very difficult to "calculate" the dependency. PIMs are used, slowing the whole process down... and of course, it will require extreme brainstroming and computer power to crack such scenario, but again: I think that my previous post statement, can be even proven mathematically!
Aug 20, 2016 at 4:53 PM
Edited Aug 20, 2016 at 5:04 PM
@kavsrf,

Either the documentation is incorrect or I am misunderstanding your post.

kavsrf wrote:
2) Salt (256 bit)
.
https://veracrypt.codeplex.com/wikipage?title=Header%20Key%20Derivation
512-bit salt is used, which means there are 2^512 keys for each password.
.
kavsrf wrote:
Normally password is 512bit.
You mean after salt is added?
Aug 20, 2016 at 5:02 PM
Enigma2Illusion wrote:
@kavsrf,

Either the documentation is incorrect or I am misunderstanding your post.

https://veracrypt.codeplex.com/wikipage?title=Header%20Key%20Derivation
512-bit salt is used, which means there are 2^512 keys for each password.
.
kavsrf wrote:
Normally password is 512bit.
You mean after salt is added?
Precisely Enigma, precisely :) here is where the problems come from.... I think you got my point.
Developer
Aug 20, 2016 at 6:49 PM
Edited Aug 20, 2016 at 6:50 PM
Enigma2Illusion wrote:
@kavsrf,

Either the documentation is incorrect or I am misunderstanding your post.

kavsrf wrote:
2) Salt (256 bit)
.
https://veracrypt.codeplex.com/wikipage?title=Header%20Key%20Derivation
512-bit salt is used, which means there are 2^512 keys for each password.
You are right - salt is 512 bits.
Note: the salt is open data. The salt is necessary to prevent precalculation of key derivation tables.
.
kavsrf wrote:
Normally password is 512bit.
You mean after salt is added?
No. Maximum size of password is 64 bytes
Password length is 64 bytes (512 bits) If key file is used
Developer
Aug 20, 2016 at 7:14 PM
@Alex512

Let me clarify. We are discussing two different areas of decryption 1. decryption of sectors data 2. header. Right?

Sectors:
Sectors data is encrypted on keys from the header. Mode is XTS.

Sectors data security is better if cascade encryption is used. It depends of trust of security algorithms. E.g. AES + GOST89 are good because if AES has backdoor GOST89 blocks it and vice versa

Header:
Header is encrypted by the key derived from
1.Password (length 1-64)
2.Pim
3.Salt

Length of password is 64 bytes if key file is used. Header is protected by 512 bits key.

Source of key file can be different - ordinary file or Smart Card.

So VeraCrypt gives possibility.
Aug 20, 2016 at 8:19 PM
Edited Aug 20, 2016 at 8:24 PM
@kavsrf,

PIM, salt, keyfiles, smart cards - these are all irrelevant. They are great, dont get me wrong, but they are just enhancements and not subject of this problem. Obviously, if keyfile is used with enough entropy, my concern is irrelevant.

The problem is not with the sector data encryption (obviously VC creates good random data for the headers in order to encrypt the sectors, this is fine), but with the user password being used to encrypt more than one header (in cascading encryption mode).

I am addressing a sterile scenario, where one is using a good password (ie 80 bit) with single encryption and another one is using equally strong user password with double (triple, etc.) encryption. I state that :
  1. The guaranteed resistance of the first scenario is equal to the lesser of the user password (ie 80 bit) entropy and the resistance of the single cipher used. This statement is quite obvious.
  2. The guaranteed resistance of the second scenario is the lesser of the user password entropy (ie 80 bit) divided by the number of encryption layers (ie 2), and the most resistant encryption algorithm used in the cascade.
Obviously, there can be instances, where the guaranteed resistance of the second scenario will be less than the first one.

However, I also conjecture, that the second scenario has higher probability of being more resistant than the first one. That being valid only for reasonable ratios between the user password entropy and number of cascades. If the password entropy falls and the number of cascades rises, my conjecture will cease to be valid. This is precisely the problem with the cascading of VC. Just as a sidenote, finding a formula to calculate the probability of the resistance for the second scenario being higher (or lower) than the resistance of the first scenario would be a gigantic mathematical challenge!
Developer
Aug 20, 2016 at 9:22 PM
@Alex512

I can't connect your model to code in VeraCrypt of header keys derivation.

For cascade algorithms keys derived are different.

e.g. AES + Twofish.
AES needs two 256bits keys (withering and encryption)
Twofish needs two 256bits keys (withering and encryption)
To derive keys for AES: algorithm of key derivation uses hash, password, salt, pim and block index 0
To derive keys for TwoFish: algorithm of key derivation uses hash, password, salt, pim and block index 1
=> keys for AES and TwoFish are different.
Protection of password are granted by hash algorithm (impossibility to restore original data from hash (password, salt, pim and block index))

Agree: length of password is very important.
Do not understand: How cascade affect security?
Aug 20, 2016 at 9:49 PM
Edited Aug 20, 2016 at 9:53 PM
@kavsrf,

You emphasize too much on the technical side. I speak about the maths of the model.

Imagine having a door key (normal, hardware, metal key, the one you probably have in your pocket). And your door lock has 5 pins that need to be adjusted by the cuts in the keys in order to make the sheer line so the lock will turn and open. And imagine, for the sake of simplicity, that each pin has 2 states, up and down. Obviously 5 bits of resistance. However, our thief at night will still has a hard time with his his picks, adjusting trough the tiny keyhole all 5 pins to the required state, up or down.... lets say he will be more or less bruteforcing the combination, trying the different states of the pins until he opens the lock.

And now imagine I tell you that you are allowed to put 5 doors on your house for better protection. What a wonderful idea, right? The thief will have to unlock all 5 doors, right?.... but the catch is, that the condition is that you can open all these 5 doors with your good old metal key. So what do you do? I bet my 5 cents, that whatever you do (unless you simply put 5 doors with the same original key, which makes no difference to the thief as he will simply unlock them all in a row), you will only make it easier for the thief.

Even worse, if you put 5 doors with the same key in a row and the first door sucks (like a bad cipher), the thief will simply see the required state of the pins and will not even need bruteforcing the next doors.
Developer
Aug 20, 2016 at 10:08 PM
Edited Aug 20, 2016 at 10:08 PM
@Alex512

Ok. Your model is different.

Let's image you have special tool and can easy open first door (name AES).
To open second door (name TwoFish) you will need different tool.
Aug 20, 2016 at 10:24 PM
@kavsrf,

I dont think you understood my idea :(
Developer
Aug 20, 2016 at 10:30 PM
Edited Aug 20, 2016 at 11:08 PM
@Alex512

I'm trying.

Let's imagine first door is not real door.it saves info about the key to open.
How does it affect second door? (Keys are different)
Aug 23, 2016 at 10:46 AM
Edited Aug 23, 2016 at 10:48 AM
@kavsrf,

We don't even need the first door to be fake and to reveal us something!

The problem is that although the keys are different, they are both derived from the first original key (the user password). And unless the original key is as long as King Arthur's sword so it can be cut into pieces and still make good length knives (keys), there is a problem. And a huge one.

Cascading (as is done in VC) creates something like a "master key", as is known among lockpickers. So you have 2 (or more) locks that are being opened by different keys, but all these doors are also being opened by a master key (that is the original user password). These locks are at least 2 times easier to pick open than a normal lock of the same model. By at least, i mean really at least, because, if the master key system (in hardware locks) was implemented the same way as is done in VC (which is btw, almost always the case), then the ratio of decreasing the difficulty to pick it open would be not " Decreased number of combinations = N / 2", but "Decreased number of combinations = N^((log(2)N) / 2)", where N is the original number of possible combinations, expressed as natural number (not in bits/powers of 2). The last is quite worrying. Of course, we have hash, PIMS, etc, but unless the initial password is really LONG (or using keyfile), then we have a problem.
Developer
Aug 23, 2016 at 11:28 AM
Agree. Keys to open are derived from password+PIM+keyfile+salt by means of the only hash function.

Normal way of use: PIM is default, salt is known and no keyfile. So the only password is important and hash function.

Let's imagine we have keys for first cipher. The key is result of hash function. We have to solve problem hash -> password.

Note: Protection of header depends on cascades of ciphers little. It depends on hash function. At present moment no cascades of hash.

So we are trying to attack hash function.

Your suggestion: Cascade of hash does not improve security or can decrease even. Is it right?

Authorization: password is the only factor. ("what I know") We are trying to add extra factors ("what I have") and location. Also we are planning to make separate keys and data encrypted. Bruteforce of password can be complex problem if we use smart card with number of attempts limited.
Aug 23, 2016 at 12:17 PM
kavsrf wrote:
Let's imagine we have keys for first cipher. The key is result of hash function. We have to solve problem hash -> password.


So we are trying to attack hash function.
no, we dont have to attack hash->password (we assume this is waterproof). That is the problem. We will attack the hash output directly by simply hashing the shorter (or dependable) user password (crippled)...

going to the extreme scenarios again.... please use undependable passwords for each layer derived from the user password +hash+salt and make me 256 layer cascaded (wow) encrypted cipher text. You can use as many algorithms you wish (max 256 bits) and as many hash functions you like. I will decrypt such output using pen and paper only. Making the passwords dependable will give me some more trouble, but still...

anyways... i dont think i can express myself better than that :)

extra factors, smart cards, pims, salt.... they r fine.... but the basics with the cascades is totally wrong. to put it mildly...
Aug 23, 2016 at 12:22 PM
Edited Aug 23, 2016 at 12:37 PM
kavsrf wrote:
Your suggestion: Cascade of hash does not improve security or can decrease even. Is it right?
no no no!!!!! Hash cascading MAY improve security. Not necessarily though! They may also decrease security, but chances for increasing it are better. My previous posts explain why. And especially because VC does so many iterations, it should cascade the hashing by adding ONE LAST HASH at the end (this statement is also not quite correct, but here it gets really complicated) by different hash function (hashing in the start is DANGEROUS if the hash function is bad), as it is running the rounds anyways. No further delay for the user or system load will appear.

Cascading the encryption does NOT necessarily provide security enhancement. It weakens the guaranteed minimum resistance of the system. This can be proven mathematically. That was my point in the recent posts.
Sep 3, 2016 at 1:52 AM
Alex512 wrote:
kavsrf wrote:
Your suggestion: Cascade of hash does not improve security or can decrease even. Is it right?
no no no!!!!! Hash cascading MAY improve security. Not necessarily though! They may also decrease security, but chances for increasing it are better. My previous posts explain why. And especially because VC does so many iterations, it should cascade the hashing by adding ONE LAST HASH at the end (this statement is also not quite correct, but here it gets really complicated) by different hash function (hashing in the start is DANGEROUS if the hash function is bad), as it is running the rounds anyways. No further delay for the user or system load will appear.

Cascading the encryption does NOT necessarily provide security enhancement. It weakens the guaranteed minimum resistance of the system. This can be proven mathematically. That was my point in the recent posts.
I don't know any tech details of encryption. But use logic - imagine 10000 different ciphers were used in cascade, based on your idea, the password bit would be N/10000, and if the number of ciphers used were infinity, then password bit is 0, which means no encryption at all. Do you think it make sense? Certainly not, to me.
Sep 3, 2016 at 12:45 PM
oliverjia wrote:
I don't know any tech details of encryption. But use logic - imagine 10000 different ciphers were used in cascade, based on your idea, the password bit would be N/10000, and if the number of ciphers used were infinity, then password bit is 0, which means no encryption at all. Do you think it make sense? Certainly not, to me.
Nah let's make an example
Cirno's perfect matn class #999
let f(x) = x^99 + 35x^3 + 1
g(x) = x^3+4x^2
cascading would be f(g(x)) = (x^3+4x^2)^99 + 35(x^3+4x^2)^3 + 1

Let's say Yukari (adversary) wants to break Patchouli's (user) volume (containing her secret starch of doujins) which is using casaded algorithm , say AES-twofish-Serpent , and a assumption that the algorithms are good enough
Since Yukari's brain computing power is huge , she can brute force one AES or twofish or Serpent layer in x hours

If the the ciphers and hashes for each layer have no relationship among each other , she will need a total of 3x hours
If there's relationships between the ciphers and result of hash ,
after using x hours to break the first layer she can derive the other 2 and SUCCESS!!
In this case she only used x hours to take all of Patchouli's doujin out of the volume and read the doujins .

Cascading isn't a problem . The problem Alex says is that the relationship between the ciphers and hashes shortens the time for adversary needed to perform brute force attack and that's what his main concern ------ Cascading cannot do its job . But the thing is that Veracrypt is made for simple but effective encryption solution so the REAL problem is that users have to choose between less secure theoretically or making it not convenient at all .
Developer
Sep 4, 2016 at 7:14 AM
Edited Sep 4, 2016 at 7:15 AM
In theory I agree with Alex. It would be good if each layer of encryption has different password and passwords do not have correlations.

It is possible with current VeraCrypt implementation because VeraCrypt gives possibility to create encrypted container in encrypted container. In this case all containers do not have correlations at program level.

Probably we need to separate attacks.
1. Attack to password
2. Attack to data

Layers of ciphers do not improve 1 but it is useful for 2
To improve 1 it is necessary to create more factors of authorization. (like key file or smart card)
Sep 5, 2016 at 6:28 AM
Alplaza wrote:
oliverjia wrote:
I don't know any tech details of encryption. But use logic - imagine 10000 different ciphers were used in cascade, based on your idea, the password bit would be N/10000, and if the number of ciphers used were infinity, then password bit is 0, which means no encryption at all. Do you think it make sense? Certainly not, to me.
Nah let's make an example
Cirno's perfect matn class #999
let f(x) = x^99 + 35x^3 + 1
g(x) = x^3+4x^2
cascading would be f(g(x)) = (x^3+4x^2)^99 + 35(x^3+4x^2)^3 + 1

Let's say Yukari (adversary) wants to break Patchouli's (user) volume (containing her secret starch of doujins) which is using casaded algorithm , say AES-twofish-Serpent , and a assumption that the algorithms are good enough
Since Yukari's brain computing power is huge , she can brute force one AES or twofish or Serpent layer in x hours

If the the ciphers and hashes for each layer have no relationship among each other , she will need a total of 3x hours
If there's relationships between the ciphers and result of hash ,
after using x hours to break the first layer she can derive the other 2 and SUCCESS!!
In this case she only used x hours to take all of Patchouli's doujin out of the volume and read the doujins .

Cascading isn't a problem . The problem Alex says is that the relationship between the ciphers and hashes shortens the time for adversary needed to perform brute force attack and that's what his main concern ------ Cascading cannot do its job . But the thing is that Veracrypt is made for simple but effective encryption solution so the REAL problem is that users have to choose between less secure theoretically or making it not convenient at all .
Thank you for your explanation. It makes sense to me.
However, I still can not understand this statement from Alex: "It weakens the guaranteed minimum resistance of the system (when single cipher is used)". How come this will happen? My understanding is, at least cascading will be as secure as single cipher, provided the same password is used in both cases. But it sounds from Alex's statement that using a single cipher will be safer as compared to cascaded ciphers.
Nov 16, 2016 at 3:51 AM
Edited Nov 16, 2016 at 5:00 AM
cascades are also known as "robust combiners", they're usually the domain of ultra high security margin applications, governments, etc.

"Cryptographic schemes are often designed as a combination of multiple component
cryptographic modules. Such a combiner design is robust for a (security) specification if it meets the specification, provided that a sufficient subset of the components meet their specifications. A folklore combiner for encryption is cascade.
We show that cascade is a robust combiner for cryptosystems, under three important indistinguishability specifications:
chosen plaintext attack (IND-CPA), non-adaptive chosen ciphertext attack (IND-CCA1), and
replayable chosen ciphertext attack (IND-rCCA). We also show that cascade is not robust for the
important specifications adaptive CCA (IND-CCA2) and generalized CCA (IND-gCCA). The
IND-rCCA and IND-gCCA specifications are closely related, and this is an interesting difference
between them. All specifications are defined within.
We also analyze few other basic and folklore combiners. In particular, we show that the following
are robust combiners: the parallel combiner for one-way functions (HASHES) , the XOR-Input combiner for cryptosystems, and the copy combiner for integrity tasks such as Message Authentication Codes (MAC) and signatureschemes. Cascade is also robust for the hiding property of commitment schemes, and the copy combiner is robust for the binding property, but neither is a robust combiner for both properties.
We present (new) robust combiners for commitment schemes; these new combiners can be viewed
as a composition of the cascade and the copy combiners. Our combiners are simple, efficient and practical"
https://eprint.iacr.org/2002/135.pdf

and here's an excellent paper from harvard
www.eecs.harvard.edu/~alon/PAPERS/combiners/combiners.ps

yet ultimately they aren't that complicated. just because not many applications use them in the public domain isn't relevant.
the weak password argument, isn't that much of an argument - it's essentially an argument from incredulity.

when it comes to stream ciphers the simplest form of a cascade or combiner is simply taking the exclusive-or (XOR) of the output of more than one hash function and using the combined result as a pad. the harvard paper shows a model similar to that.

hash functions, with regard to the "relationships between them", see the harvard paper. most of these functions operate on such different principles that you aren't going to have the problem fearmongered about, with them cancelling out each other. in fact, combining hash functions is an excellent way to protect against one of them being compromised and giving up your data. there are other ways to break a cipher than brute force.
in skein (https://www.schneier.com/academic/skein/threefish.html) a method for using the skein hash function as a stream cipher is a documented mode - salsa20 has roots in the author finding it ludicrous that the US government at one time had proposed to ban encryption but not stream ciphers. a functional example (disclosure, mine) of some interesting combiners implemented in c as a public key application is at http://github.com/adouble42/rotor
in that example the model is very similar to PGP except the NTRU lattice functions are used in place of RSA to secure the ensuing stream/block cipher keyspace. the stream that follows is SHAKE-256^Salsa20, in an output feedback block configuration, in normal operation. SHAKE-256 is the permutation function (XOF) used in hash function SHA-3 keccak (http://keccak.noekeon.org/fips202final.html). it's extendable output make it very useful as everything from a KDF to a hash to a stream cipher to a mask function that does a far better masking job than MGF-1. the simple XOR of SHAKE and Salsa20 guarantees that should either hash function be compromised the other will still hold, without the other unknown portion of each block, breaking one simply does no good. the more complex mode involved SHAKE as a mask against data inside of NTRU blocks , then xor'd against a Salsa20 stream. in that case it's really the NTRU doing the work, still, as it's the public key function....but, by default rotor knocks off the NTRU encrypted header as a separate, lattice PKI encrypted file. without which, you've got a bunch of data woefully inaccessible. for reference, NTRU is a public key scheme known to be resistant to quantum computing attacks that will break the likes of RSA. there's a difference in the encryption of the header, fundamentally, between NTRU and the methods used to secure the key in truecrypt, in that NTRU is an assymetric public key method versus the symmetric method of something like TC. that doesn't affect the security of the combinations on their own.
hashes are different in that they're optimized for a different role, where you may want a cipher to be lightweight and focus on speed, it's more important, perhaps, to focus on collision resistance in a hash.
https://www.technologyreview.com/s/600715/nsa-says-it-must-act-now-against-the-quantum-computing-threat/
there's a reason the NSA dropped 80 million researching things like NTRU last year
it's prudent to use more than one method to protect your data and secure your keys if you want it to stay hidden
just because something is not understood by the individual completely does not make it less valid

most of the arguments against these cascades - combiners - are based on a lot of theory and what if that doesn't pan out in to the applied, and presumptions of improper implementation, and what amounts to operator error in choosing bad passwords to secure keys.
there are combinations like RC4:AES:RC4, which, while itself outdated, is an excellent example of obfuscation. you have a 512 bit key there, with two 128 bit RC4 keys, the 128 bit AES key, and a hidden 128 bit AES IV in the middle which makes for a very difficult situation for an attacker. which you can find a plethora of examples of being utilized by sysadmins on stackexchange. often they don't use a custom built application but string output of several functions together on the command line.
if your passwords are the problem -
you have a problem with passwords, not ciphers.
if you need a strong password look at s/key calculators or diceware passwords
http://world.std.com/~reinhold/diceware.html
there's enough entropy in a diceware password generated in the physical world using wordlists and plain old dice that assertions of brute force don't matter
the whole point of things like PBKDF2 is to make up for users choosing lousy passwords - but again, users choosing lousy passwords, is not something to discount an effective, robust combination of ciphers over.
to that end there are memory hardened KDFs like yescrypt and scrypt designed to thwart FPGA attacks by raising the cost of such an attack to be unfeasible
it's easy enough to design something like the EFF's deep crack https://en.wikipedia.org/wiki/EFF_DES_cracker with a solid investment, but the numbers are well researched and quite available to demonstrate that when you add a memory cost your GPU or FPGA cracker becomes insanely out of the range of even governments when combined with solid passwords. the example public key implementation above (rotor) uses a memory hardened BLAKE-256 PBKDF function based on yescrypt to demonstrate this.
it's simply not sound to presume that governments are using magical brute forcers that will inevitably guess your password, when it's well documented that the NSA and such organizations would most often prefer a side channel attack to avoid attacking the encryption entirely. which does NOT make the argument, that because such an attack is within the realm of possibility, it's not worth securing against other known attacks with readily available methods. that's just sloppy opsec.
if someone can brute force your password in a few hours, it's not the encryption failing to protect your data. it's not that difficult to create a large enough keyspace that brute force is the least effective option. 64 bytes is not just a-zA-Z 0-9. again, see diceware above. even when it is, that's why we say passPHRASE, not passWORD. many attacks on ciphers of the sort used here use software SMT solvers (https://www.easycrypt.info/trac/), reduced round count versions of hashes and ciphers.
as far as TC goes
the hashes derived from your passwords protect randomly generated XTS keys that differ for each cipher in the volume -there is no mathematical relation between the XTS key and the hash. that's why you can change the hash function and the password without reencrypting the entire volume.
there's nothing stopping anyone from knocking the entire header off of a truecrypt volume and storing it separately, as rotor demonstrates, and then there's nothing to brute force except the combined keyspace of all three ciphers in the combiner.
good luck with that.
robust combiners are not designed to protect users from choosing poorly with regard to keys. KDFs like PBKDF2 and yescrypt/scrypt attempt to help there. robust combiners (cascades) are designed to protect against things like differential attacks. there's a different and very valid purpose to them.
and the fear mongering about ciphers "cancelling each other out" is a bunch of hypothetical without a lot of substance. you'd need to almost willfully choose ciphers deliberately to combine in to such a configuration.
www.wisdom.weizmann.ac.il/~naor/PAPERS/robust_abs.html
robust combiners, they are so farfetched that NESSIE standards even suggest using them.
https://www.cosic.esat.kuleuven.be/nessie/deliverables/decision-final.pdf
Nov 16, 2016 at 4:55 AM
Edited Nov 16, 2016 at 8:32 AM
if there was ever a reason to hedge one's bets with regard to ciphers the NSA/RSA bSafe payoff regarding dual elliptic curve provides an excellent reason, particularly to combine ciphers from different standards bodies, ie a NESSIE/NIST chain involving Camellia, say and twofish, serpent (also, done that, already put my time where my mouth is, there)
the NSA paid RSA 10 million dollars to insert compromised elliptic curves in the default cipher used by one of their products, enabling years of dragnet surveillance.
this is not speculative or tinfoil hat domain, this is a real, documented and considered threat and one of the situations a robust combiner/cascade is designed to protect against
when combining ciphers it's more than the math to be considered. think of the politics and agendas behind the standards bodies attesting to the strength of the ciphers. all of the angles matter.

http://dualec.org/

if you want a memory hard kdf mfcrypt types based on scrypt and yescrypt are drop ins with many of the existing hashes. rotor uses zefcrypt which is a fork of yescrypt using a BLAKE-256 HMAC/PBKDF2, have at it. but don't fault solid, fundamental applied cryptography for not protecting users from their own error of not choosing strong passwords, that's arguing that just because some careless people get cheap on the deadbolt we shouldn't bother building solid doors and frames at all.
one last time
http://world.std.com/~reinhold/diceware.html
http://www.iusmentis.com/security/passphrasefaq/strength/#HowdoImakeastrongpassphrase

https://www.iacr.org/archive/crypto2006/41170550/41170550.pdf

"Free software is the world's most advanced technical education system. It allows anybody, anywhere in the world, to get to the state of the art in anything computers can be made to do, by reading what is fully available, by experimenting with it and by sharing the consequences freely."

Eben Moglen
Developer
Mar 30 at 7:52 AM
Password is common part to derive key for decrypting header. All decryption stages (e.g. D1, D2, D3) use the same key(from password). So if we can break D1 or any other in cascade we know key for all (D1, D2, D3)

Sector encryption procedure uses independent keys for all ciphers in cascade but header decryption procedure uses key derived from password for ciphers cascade.

Probably to solve the problem we can select hash and encryption algorithm for header (separate from data sectors encryption) but it is not obvious,
Apr 1 at 11:13 PM
I'd recommend depreciating cascades, personally. The few times I've ever seen them they were giving the user a very false sense of security. Ex: Since I'm using cascading algorithms I can use a 5 character password and it'll be secure.