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

Free PIM setting, regardless of password length, pleaaaase?

Topics: Feature Requests
Aug 23, 2016 at 9:53 PM
Hi,

First of all, congratulations to Idriss and the other contributors for a fantastic work in taking over TC so smartly.

I'm gonna cut it short, the only reason why I don't use VC is the constraint of having a high PIM in case of a "short" password. I fully understand the rationale behind that constraint (brute force attack capacity with new hardware, CUDA, rainbow tables, ...) but let's face it, if you have a 19 chars password (which is still huge by current standards) it takes around 30 seconds to pass the verification on a quad-core i7-6700HQ at boot time !

Why not let the user choose their own [ password length / iterations / security ] trade-off?
While of course still heavily warning them of the possible consequences of that choice through blinking popups with red signs :) or hide the option to free the PIM deep inside the settings so that the average unaware user can't override and stays protected.

Free the PIM ! Free the PIM !
:)
Sep 12, 2016 at 4:15 PM
Edited Sep 12, 2016 at 4:16 PM
I second this proposal.
18 random alphanumeric characters contain 107-bit of entropy.
16 random ASCII printable characters contain 105-bit of entropy.
Both are reasonably strong.
And yes, people DO use random string of ASCII printable characters as their passwords, such as me! I don't actually find passphrases of equal entropy more memorable.
Sep 19, 2016 at 7:39 PM
Edited Sep 19, 2016 at 7:43 PM
The creators of VC do not understand cryptography which has lead them to implement some strange pseudo-cryptographic properties. The high "PIM" value being one of them, and a bunch of unnecessary hashing algorithms the other.

The point of key-whitening was taking a low-entropic source (such as a human-language password) and turning it into a fixed-length high-entropic source. Only ONE ROUND of a cryptographic hash is needed to achieve this goal. Any time spent 'hashing' the key is provably a waste of time. If more than 1 second is used to whiten the password, it would have taken less time & been more beneficial to simply add an additional character to the password. IE: A password of length 12 and a whitening round-count of just 1 is mathematically more secure than a password of length 8 with 200,000 rounds. Not only is it more secure, it will take less time to type in 4 more characters (2 seconds) than it will take a CPU to do 200,000 iterations (30 seconds).

On top of that, the encryption algorithms themselves can be used to whiten any key, making the inclusion of any generic hash unnecessary as well as increasing the sizes and complexities of the bootloaders (a bad thing). Rather than using say RIPM-160 or SHA-256 to whiten a password, the plaintext password itself can be set as an AES key (with a padding scheme) and used to encrypt a fixed plain-text string. This process is repeated several times to generate enough bits for the key from every byte of the password. Basically.. for those who do not know, any symmetrical block cipher like AES, Two-Fish, Serpent (etc) are all 1-way hashes that can be used just like MD5 or SHA or Whirlpool. It's just slightly more computationally slow to use a block-algorithm (designed for encryption and decryption) as a 1-way hash than an algorithm specifically designed for just 1-way hashing. In laymen terms, all symmetrical block ciphers can "self whiten" their own keys so reliance on other cryptographic algorithms is 100% unnecessary.

AES Example: Lets say I have a password that is 40 bytes long, and I need a whitened key with a length of 256-bits:
  • We nee 4 rounds to build a secure key that is based upon all 40 bytes of input:
    1) AES's key length is 32 bytes, so I'll need to call this twice, once with the first 32-bytes of my password, and once with the remaining 8 bytes that are padded.
    2) AES's block length is 128-bits, so I need to do step 1 twice to get 256-bits.
  • Round 1: Encrypt the 128-bit integer value of 0 with the first 32-bytes of the password
  • Round 2: Encrypt the 128-bit integer value of 0 with the 2nd 32-bytes of the password
  • Round 3: Encrypt the 128-bit integer value of 1 with the first 32-bytes of the password
  • Round 2: Encrypt the 128-bit integer value of 1 with the 2nd 32-bytes of the password
XOR R1 with R2, this is the first 128-bits of the whitened key. XOR R3 with R4 for the remaining 128-bits. This pattern can be used to extract an infinite amount of bits from any password of any length, these bits can then be used as a strong key in the very same block cipher that produced them.
Developer
Sep 19, 2016 at 8:42 PM
Encryption key and authorization key are different.
see: https://veracrypt.codeplex.com/wikipage?title=Header%20Key%20Derivation

PIM reasons:
  1. Slow down bruteforce
  2. More easy to mount volume with password cached. (No need enter password. PIM only)
It is better to use several factors of authorization (key file or smart card)
Oct 21, 2016 at 4:59 PM
I don't have the knowledge and background to get into taht kind of debate, however I strongly feel the end-user should be free to decide the strength of his protection based on the real threat. I feel my "less than 20 character" password is strong enough but can't handle the 30 seconds wait on boot (on a core i7-6700 HQ !) because of the high default PIM.

Please, development team, can you express your opinion on why you wouldn't let user decrease - voluntarily - the security level, if they wish, while still alerting them in that case?