Free PIM setting, regardless of password length, pleaaaase?

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.

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.

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.

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?