Encryption Algorithm and Hash Algorithm

Topics: Feature Requests, Users Discussion
Jan 8, 2016 at 1:38 PM
Edited Jan 8, 2016 at 1:40 PM
Hello,

I have several questions for this post.

First, when it comes to Encryption and Hash, what is a good combination? I have been using TrueCrypt for the last 7 years. I tend to always pick the 3 layer Encryption Algorithm, and either Whirlpool or RipeMD-160. It seems that that is an overkill for some file containers. What would be a good combination between Encryption and Hash? I still prefer security over performance.

Second, I noticed that VeraCrypt does not support RipeMD-160 during the file container creation stage. Only SHA 256, SHA 512 and Whirlpool showed up.

Third, I have been using Encryption, Hash, and KeyFiles for TrueCrypt. Now, with the introduction of PIN and picking the Hash "PKCS-5 PRF", I will probably use that too. However, what is the point of the "PKCS-5 PRF" dialog selection when there is also "Auto Detection"? By leaving it at "Auto Detection", wouldn't it defeat the purpose of security? At which point, it only serves as performance to mount quicker, right? Asides from Password, KeyFiles, and PIN; is there any thing else can be used to heighten security?

Fourth, I noticed VeraCrypt, has a 64 bit version. When would I use the 64 bit version over the 32 bit version?

Fifth, what and how to use the PKCS#11.dll?

Thanks
Jan 8, 2016 at 3:21 PM
Edited Jan 8, 2016 at 3:23 PM
RipeMD-160 was removed because it is quite old and not as well-tested as the others.
Removing it is a precaution. It can be used for system partition only, as the bootloader used to support only RipeMD-160 .

Auto Detection is for performance reasons, you are right. If you used the Whirlpool, Auto detection would try (and compute) SHA-512 first which is wasted time.
Even more: If you misstype the password (or PIM or keyfile), all hashes will be tested wasting even more time.

I don't understand what you mean about the ability of selection being a potential security problem?!
It is at most a security degradation with a factor of 4 (An attacker knowing the KDF-Hash vs. an attacker that doesn't) - and a factor of 4 is almost nothing.

All Algorithms used in VC are considered secure, so the choice is up to you. however, using a modern i5 or i7 AES is must faster than the others - but you said that you do not care that much about security.

edit: Oh, and use the 64 bit version if you have a 64 OS. I'm not sure whether there are performance improvements because of the larger register size - would be nice to have a developer's opinion for that.
Jan 8, 2016 at 8:02 PM
WRVeraCrypt wrote:
By leaving it at "Auto Detection", wouldn't it defeat the purpose of security?
As a matter of fact if you select in preferences a selected algorithm, this will be a security weakener.... Or rather a trimmer of the added security provided by VC.... in fact, in case your machine with VC installed falls in your enemy's hands, you will lose the advantage of exactly 1 bit (if we dont count RipeMd, as TC option only) "combinations" as far as bruteforcing your data is concerned :)
Jan 8, 2016 at 8:55 PM
Edited Jan 8, 2016 at 9:00 PM
Hi RandomnameForCode,

You were able to answer my questions: First and Second

As for the Third question: you wrote - "I don't understand what you mean about the ability of selection being a potential security problem?"
Pretty much what Alex512 just wrote. In TrueCrypt, when I create a file container/volume in RIP or WHIRLPOOL, no one knows the hash algorithm. During mounting, it is default. Wouldn't that to be more secure? I feel that VeraCrypt introduced this selection box to compensate for the "mounting delay" set back, due to the heighten 32,676 increase. I have always assumed that when the Encryption algorithm and Hash algorithm are kept confidential, the encryption process would be more secure.

Can a Developer help on the Fourth and Fifth questions? Also, asides from Password, KeyFiles, and PIN; is there any thing else can be used to heighten security?
Jan 10, 2016 at 4:56 PM
This is adding "security by obscurity" - besides the fact that most users will have the default hash algorithm.
Its actually more than a single bit (SHA-512 SHA-256 and Whirlpool are 3 options, not 2).

VC resets the settings for each mount, so how would an attacker know your selection?
If you dont want to, just do not select the algorithm.
I actually dont care whether an attacker need 1 million years to break my encryption or 4 million years...
Jan 10, 2016 at 5:45 PM
Edited Jan 10, 2016 at 5:45 PM
RandomNameforCode wrote:
This is adding "security by obscurity" - besides the fact that most users will have the default hash algorithm.
Its actually more than a single bit (SHA-512 SHA-256 and Whirlpool are 3 options, not 2).
:) it is still one bit exactly.... 3 options will require 2 tries on average (1+2+3)/3=2
Jan 10, 2016 at 7:41 PM
ok, average - good point. It depends on the order of the attack.
I as an attacker would try each password with all 3 hashes, because the number of passwords is much higher :)

On average you would have to try at least 0.5*3=1.5 algorithms. As you cannot test 0.x, the practical average would be 2.
Even if > 99% users keep the default hash function, the practical average is still 2. Math is crazy ^^
Jan 10, 2016 at 7:58 PM
Edited Jan 10, 2016 at 8:02 PM
not quite correct :)
when u try the hashes (if you try the long way, all 3), in 1/3 of the cases you will guess it at once, 1/3 at the second attempt and 1/3 of the cases at the 3rd attempt..... so on average to guess 3 passwords, you will try 1 + 2 + 3 times on average of course. That means 6 tries for 3 password... or 2 times per password... or 1 bit as i stated earlier....
this has nothing to do with rounding of 1,5 to 2 :) Math is a cutie ^ ^

p.s. just kidding today... this is a cool paradox btw... you can prove me wrong and i can prove you wrong! :)
Jan 11, 2016 at 2:22 PM
It is not the case that all 3 algorithm have the same probability, as stated earlier.
If this was the case (same prob.) and you would use a random order of n algorithms, you would expect that you have to try half of them (general case, my formula).
If you fix the order of 3 algorithm with the same probability than you are right: (1/3)1 + (1/3)2 + (1/3)*3 =(1+2+3)/3=2 on average.
In fact it does not matter, the result is 2.
Jan 11, 2016 at 2:29 PM
Edited Jan 13, 2016 at 7:45 AM
RandomNameforCode wrote:
It is not the case that all 3 algorithm have the same probability, as stated earlier.
yes, but for ease of calculation, we assume the probability is the same for all 3
If this was the case (same prob.) and you would use a random order of n algorithms, you would expect that you have to try half of them (general case, my formula).
If you fix the order of 3 algorithm with the same probability than you are right: (1/3)1 + (1/3)2 + (1/3)*3 =(1+2+3)/3=2 on average.
In fact it does not matter, the result is 2.
You came to my conclusion, which is..... FALSE ... LOL.... in fact it is true, but is also false... depends on how you look upon.... if you say that the complexity of AES (or similar 256 bit key algorithm) is 256 bits, then my statement is false.... if you say that the complexity is 255 bits, then my statement is true :)
Jan 11, 2016 at 2:40 PM
You two are so deep into discussion. :)

Regardless, I still think leaving the hash algorithm in a drop-down is like letting someone see the password. Why did they do this? I can only guess because it takes so long to mount if left in auto detection mode.

I also find the split of 32 bit and 64 bit is a bit of a downgrade. TrueCrypt had it combine, only the driver was kept separate.

I have been migrating a majority over in the past 2 days. It takes so long to mount!

Is it safe to stay on truecrypt for six more months?
Jan 11, 2016 at 4:19 PM
Edited Jan 11, 2016 at 4:20 PM
TC has no major issues causing real problems.
If the password is good and the systems you enter the password on are clean, that is fine for now.
It it's not, VC provides a better but still not a good protection - just because this is not the design goal.

The dropdown-menu is reset by VC anyway (which is really anoying to me), so you do not see it.
But even knowing the algorithm is like telling someone "the first letter of my password is an ASCII character" - its worthless.

A good encryption algorithm must be secure even if an adversary knows the exact algorithm
The only thing secret shall be the key. (I'm wating for the first person asking about keyfiles and PIM ^^)
Jan 11, 2016 at 5:26 PM
Some time ago I have suggested here (and have received no meaningful responses so far) that as VC is anyhow iterating hundreds of thousands of times the hash transformation, it should better mix the hashing functions. This will not slow down the process (even if it does, then the iteration count can be decreased, the result will be the same in terms of bruteforce effort)..... but will eliminate any eventual weakness in any of the hash algorithms and will additionally "deprive" the user of the "choice" of hash algorithm - it will be always cascaded. There are some considerations as to NOT using cascading hashes, but as far as I agree with them, only to the extend where the hashing result is sum of the different hashes, thereby increasing the output size, rather than pure cascading.
Jan 11, 2016 at 11:06 PM
Thank you for your replies Gentlemen!

RandomNameForCode, what should the first person ask about KeyFiles? I have been using them for years. PIM is new so I just have posted a question in another thread.

So what you are saying in your previous post is that someone can know the Encryption Algorithm and Hash Algorithm, and it will still be safe? I just think that keeping all of that confidential would make it even harder to hack since they don't know where to start.

As for "the dropdown-menu is reset by VC" - I use to program in the past. I actually can scrape text data off of (almost) any window. If there is a keylogger embedded illegally in the OS, the password box may protect with the masked field but it does not protect against key strokes. Same goes for the dropdown, regardless VC reset it. The data can be scrape from the drop down. Again, I just wondering why would it be necessary for VeraCrypt to expose this?


Alex, are you saying that cascade hash is not necessary? I did not see cascade hash in VC. There is only SHA and Whirlpool. I did see cascade Encryption (among AES, TwoFish, Serpent). Could you help me understand?

Thanks
Jan 12, 2016 at 4:46 AM
WRVeraCrypt wrote:
Alex, are you saying that cascade hash is not necessary? I did not see cascade hash in VC. There is only SHA and Whirlpool. I did see cascade Encryption (among AES, TwoFish, Serpent). Could you help me understand?
There is no cascading hashing neither in VC nor in TC. What i am saying is that as VC is anyhow performing tons of iterations, it would be m uch better to mix the hash function, say 200000 SHA1, 200000 SHA2 and 200000 times Whirpool. In this way, I think, the security of the hash will be improved and there will be no need for the user to make an UNINFORMED (for 99,99% of us) decision as to which hash to chose.
Jan 12, 2016 at 4:49 AM
Got it. That makes sense. Have you posted in the feature request location? Thanks
Jan 12, 2016 at 5:35 AM
Edited Jan 12, 2016 at 6:47 AM
WRVeraCrypt wrote:
Got it. That makes sense. Have you posted in the feature request location? Thanks
I thikn I have. Also, it is not really necessary to make 200000 iterations of each... it can be setup to work as now, with all the iterations done by one hash algorithm and then at the end add one round of another one and one more round of the third one. Unlike with cascaded encryption, it will not cause cpu overload and performance issues.

p.s. when doing that, the chance of collision in the output is slightly higher due to the multiple hash algorithms, although it shouldn't be a real security concern as it all about encryption, not authentication.
Jan 12, 2016 at 5:14 PM
If your OS is compromised, TC/VC protection is done - period.
The AES Key can be dumped from memory and thats it.

I said "first person asking" because keyfile and PIM are not a password in the strict sense.

And yes, a good encryption scheme is good even though everybody knows how it works (e.g. AES).

Why would you use 1 iteration of hash 2 and 3? If hash 1 is broken, those 2 iterations will not help a lot.?
Jan 13, 2016 at 7:51 AM
Edited Jan 13, 2016 at 7:53 AM
RandomNameforCode wrote:
Why would you use 1 iteration of hash 2 and 3? If hash 1 is broken, those 2 iterations will not help a lot.?
If hash 1 is broken then hash2 or hash3 will still remain irreversible so it will help a lot. The only problem of cascading hashes (as i am suggesting) is that the chance of collision (getting the same end result from different inputs) will be twice higher if used 2 hash functions, 3 times higher if using 3 functions and so on..... still, this could be consider as negligible possibility possibility and even then, in case of a collision, the security model will be not severely affected.
Jan 13, 2016 at 11:26 AM
If its just 1 iteration, you can brute-force it in "notime".
Why does the collision risk increase compared to 2 more iterations of hash 1?

Of course, the chance for a collision in SHA256 is much higher than for a collision in SHA-512 (constructed the same way but the possible outputs are 2^256 compared to 2^512). So if you start with SHA-512 and add a iteration of SHA-256, you increase the risk of a collision.
But in the general case?!
Jan 13, 2016 at 12:09 PM
RandomNameforCode wrote:
If its just 1 iteration, you can brute-force it in "notime".
No, if the hash function is ok, you can not reverse it. You have to bruteforce the whole bit space, which is definitely not "notime". You are mixing the terms a bit. The iterations add ONLY some time for the hashing process of each password to be performed. The iterations do not add real security enhancement apart of that.
Why does the collision risk increase compared to 2 more iterations of hash 1?
Because if ANY of the hashes results in a collision, then the end result will be a collision too, even if there are many hashes on top of each other.

Lets give an example. Suppose we have 2 plaintexts "AAAA" and "BBBB" (which are our passwords in fact, but it doesnt matter. And suppose we have 2 hash algorithms SHA1 and SHA2... and suppose SHA2 is bad in terms of colission, such that:

Sha1 ("AAAA")=> "GTRF" , which is fine
Sha1 ("BBBB")=> "WBTY", which is fine
Sha2 ("AAAA")=> "CGBS", which is fine so far
Sha2 ("BBBB")=> "CGBS", which is bad as it is the same as the result above (a collision)

Now in reality, suppose we iterate 1000000 times Sha1..... the end result of the 2 different inputs (AAAA and BBBB) will be also different (hopefully and most probably, if Sha1 is really ok for each and every input text, which is theoretically not possible as the end result is limited to the bits of the hash function, which may be less than the input)

Suppose however that we do one round with Sha2 and 999999 rounds with Sha1.... then after the first round Sha2, the intermidate result from both plaintexts (AAAA and BBBB) will be the same (CGBS) so after that no matter how many iterations will be performed with the good Sha1, the end result will be again the same because the good hash function is feeded with the same output from the bad hash function. So in reality, in terms of collision, the strength of the cascaded hash transformation is equal to the strength of the weakest hash function....
Jan 14, 2016 at 8:18 AM
Hello, you may have some delusion of what security means, so I suggest reading Kerckhoffs's principle. What cipher you have used, key-derivative hash selections, and/or iteration count is NOT security and should NEVER BE considered security. Assume your attacker knows everything you have done to encrypt your data except the key. I have used AES to secure my HDD, with a PIM of 5, and a hash of SHA-256. Knowing this you are no closer to decrypting my HDD than had I told you nothing. This is mathematically proven.
Jan 14, 2016 at 8:53 AM
Edited Jan 14, 2016 at 8:53 AM
**brett_ wrote:**
Hello, you may have some delusion of what security means, so I suggest reading Kerckhoffs's principle. What cipher you have used, key-derivative hash selections, and/or iteration count is NOT security and should NEVER BE considered security. Assume your attacker knows everything you have done to encrypt your data except the key. I have used AES to secure my HDD, with a PIM of 5, and a hash of SHA-256. Knowing this you are no closer to decrypting my HDD than had I told you nothing. This is mathematically proven.
this is true, but in a very, very sterile form... in real life, even putting my laptop under the mattress instead of leaving it on the table, is an added security :)
Jan 14, 2016 at 9:10 AM
Edited Jan 14, 2016 at 9:28 AM
Alex,

I agree with you. You and I come from the same camp. The less they know the better the security.

I have a gun safe at home and for the longest if time, I refused to let anyone know that I have one. If you can't find it, how are you going to break into it? The safe itself is a form of protection but is it 100% protection? NO! Someone who knows the dimension can formulate a plan of either carry it out or plasma cut it open. A 300lb safe vs a 1000lb safe caring down a flight of stair? When you can introduce a sense of doubt and take away their ability to formulate, that is an added layer of protection. It may not be 100% guarantee but it still an added layer of protection.

I have a friend who leaves his gun safe in the wide opening. He told me no one will be able to open it. Sure about that?
Jan 14, 2016 at 10:31 AM
WRVeraCrypt, you are absolutely right. From brett's position, he also has a point. In the encryption field, when a product is brought to the market, it is of course so that one should not count on keeping the encryption system secret, as it will, soon or later, be revealed...... So he is right that it is not the real security... In real life however, when it comes to everyone's particular case, things are very different.....

A few examples to backup my point: why did the Germans during WW2 kept their enigma machine so secret? Why would they do the impossible to prevent any of these machines fall in enemy's hands? They could have just reshuffle the rotors and initialize the machine to its factory state and problem solved, right? Wrong... they simply didnt want the machine's internals to be known.... and that is added security..... Or why are nowadays so many classified encryption algorithms (mainly by the military)? Why they just dont publish everything so the public can have a look? Because thats also an added security.....
Feb 1, 2016 at 5:22 AM
Alex512 wrote:
WRVeraCrypt, you are absolutely right. From brett's position, he also has a point. In the encryption field, when a product is brought to the market, it is of course so that one should not count on keeping the encryption system secret, as it will, soon or later, be revealed...... So he is right that it is not the real security... In real life however, when it comes to everyone's particular case, things are very different.....

A few examples to backup my point: why did the Germans during WW2 kept their enigma machine so secret? Why would they do the impossible to prevent any of these machines fall in enemy's hands? They could have just reshuffle the rotors and initialize the machine to its factory state and problem solved, right? Wrong... they simply didnt want the machine's internals to be known.... and that is added security..... Or why are nowadays so many classified encryption algorithms (mainly by the military)? Why they just dont publish everything so the public can have a look? Because thats also an added security.....
This is a late reply, sorry. On an extremely technical level, yes keeping something a secret is added security. But in reality it really isn't. If you could take some complicated step to add 0.00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001% more security, would you? No, because that is implausible, especially since adding 1 more character to your password adds significantly more security in much less time.

Anyone who thinks abusing the hash+algorithm secret combo is added security is mistaken, since just 1 more lowercase letter [a-z] in their password would add significantly more security to their encryption than any bullshit hash+algorithm secret ever would.

The only REAL security you will ever get from encryption is the key, more specifically the password used to derive the key. If you think any of this other stuff matters then you have not read up enough on encryption. 64-bit keys will take a ridiculous amount of time to crack (years) even with a large amount of chosen plaintexts. 65-bit are twice as hard. 128-bit keys have been agreed upon to take longer than the life+energy of the entire universe to crack. 129-bit keys would take double the entire life+energy of the universe. Most encryption schemes use 256-bit keys. Spend at least 60 seconds thinking long and hard about that fact. We do not use 256-bit keys for protection, we use them because technology easily allows us to. If we were only concerned about security we'd still be using < 128-bit keys. Even if some god with universal powers was able to brute-force the 256-bit key against a chosen plaintext, they would only have the key for that block, not the master key for all blocks. Since XTS mode is used, cracking the key for a single block provides no information for the master key. Thus another 256-bit key space per original 256-bit key space would need to be cracked. AKA this will never happen ever, even with unforeseen alien technology.
Feb 1, 2016 at 3:00 PM
Nobody knowAlex:
Still, why is the chance for a collision twice as high for 2 algorithms?

I have used AES to secure my HDD, with a PIM of 5, and a hash of SHA-256. Knowing this you are no closer to decrypting my HDD than had I told you nothing. This is mathematically proven.
Source? Even if it takes 5 billion years to crack we are still much closer than before (5k trillion year to crack) - of course the numbers are just examples.

The iterations add ONLY some time for the hashing process of each password to be performed. The iterations do not add real security enhancement apart of that
What definition of security are we interested in, if not time to crack?
And we have to consider, that you usually would rather dictionary-attack a password than brute-force it.

brett_
we have no idea how secure our encryption is in a universal perspective. There might be weaknesses we just could not think of yet and/or computing systems we just can not think of (similar to RSA with quantum computing).
Talking about RSA: Think about RSA with a 128-bit key space.
Feb 2, 2016 at 1:36 AM
RSA is not a symmetrical block cipher and thus has a different key size for that reason alone. This is also why ECC can use a smaller key size compared to RSA but still offer the same buffer of protection. Quantum computing is a thoery, not a reality, based on quantum mechanics, another theory with no evidence of its existence. Even if it existed, quantum computing has no effect on block ciphers that use the foundations of confusion & diffusion in a way that achieves strict avalanche criterion. There are no shortcuts, now or ever, for bypassing substitutions and permutations when block/box sizes are large enough. 8-bit randomly generated S-boxes and P-boxes are provably secure:

Gordon, J. and H. Retkin. 1982. Are Big S-Boxes Best?
Pieprzyk, J. and G. Finkelstein. 1988. Towards effective nonlinear cryptosystem design. IEE Proceedings, Part E. 135(6): 325-335.
Youssef, A., S. Tavares. 1995. Resistance of Balanced S-boxes to Linear and Differential Cryptanalysis. Information Processing Letters. 56: 249-252.
Feb 2, 2016 at 3:21 PM
Edited Feb 2, 2016 at 3:35 PM
RandomNameforCode wrote:
Still, why is the chance for a collision twice as high for 2 algorithms?
suppose we have a simple model that hashes once with SHA256 (which is considered good and collides only once in 2^256 hashes, which we consider a zero chance) and then on top of it we hash additionally with GUMBLE (a hash algorithm designed by my 7 yo daughter, which is not as good and collides once in 10 hash calculations)....

so in our model we first hash with SHA256 and then we do additional hashing with GUMBLE as follows:

PASSWORD 1 ---> (SHA256) ----> INTERMEDIATE 1 --------> (GUMBLE) ------------> OUTPUT HASH 1
PASSWORD 2 ---> (SHA256) ----> INTERMEDIATE 2 --------> (GUMBLE) ------------> OUTPUT HASH 2

The chance of collision between intermediate 1 and intermediate 2 is 1/2^256 or close to zero...... however passing these 2 DIFFERENT intermediate values through GUMBLE gives us chance of collision of output hash 1 and 2..... to be 1 to 10..... So the whole model with the 2 hash functions on top is compromised....
If we first hash with GUMBLE the 1/10 chance result is still the same, because then the chance of collision in the INTERMEDIATE 1 and 2 will be 1/10 and if these values are the same, hashing them with SHA256 will again provide the same output :)

So the chance of collision is twice higher as we have 2 hash functions and EACH of them can weaken the collision model. In an extreme scenario, if there existed 2^256 different GOOD hash algorithms, each producing a nice 256 bit hash output without any collision issues, and then we use all these 2^256 on top of eachother... then we would almost always get a collision.... which makes us think of what if we iterate 2^256 times with ONE GOOD hash function? Any thoughts? What would be the chance of collision? :) Can we predict? Does it depend on the hash function at all? Come on.... a little brainstorming :)

p.s. and even more practical question: do the iterations in VC increase the collision possibility of the hash output ? And if yes by what factor? And again, can we tell? :)