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

The ceiling of 64 characters - break it!

description

Discussion on the page:
https://veracrypt.codeplex.com/discussions/577716#post1342611

Mounir, I suggest that we limit the password to more than 64 digits. Sometimes this is a security issue. Moreover, it gives much greater freedom in creation of the password. Thus to make the pass not only secure, but memorable too.
Mounirs reply:
Concerning the password limit, it was inherited from TrueCrypt and it is linked to the fact that we always use a 64-bytes password internally that is derived from the user password and any specified keyfiles. There are no technical issues for making it larger (it is indépendant from the storage format). The only point is compatibility with the current VeraCrypt volumes: I don't want to add a new checkbox to say which password type (short form or long form) are we going to use for mounting.

One idea is to activate the longer password code only when the user enters a password longer than 64 during the volume creation or volume mounting. This way, the new code will only execute in this case and it will not affect the current password handling.
I strongly recommend to remain the keyfiles option for the long password too (more than 64-bytes). Immediate thought would be about keyloggers (most of them still without snapshots). There was an issue in our company, when the password was compromised by a keylogger, BUT not the keyfile of the volume! It saved us from a very big headache. And maybe from a situation like in Sony's case :D

comments

commenter8 wrote Jan 16, 2015 at 2:33 PM

This change should keep in mind the UniCode transition (see https://veracrypt.codeplex.com/workitem/62). With UniCode a string is usually in UTF-16 format, which allocates one 16-bit unit per character most of the time but about 1% of the time will need a second 16-bit unit to represent a single character. So if there are 100 characters then the UTF-16 string representing that password will be about 101 16-bit units long. It is also possible to use UTF-32 which simply allocates 32 bits for each character no matter what. The code packages for UniCode string and character handling will automatically take care of these details and they provide easy conversion between the UTF-16 and UTF-32 representations.

Writing the code to handle longer passwords is a good time to start using UniCode string and character handling packages such as the International Components for UniCode - http://site.icu-project.org/ - and more information on UTF-16 and UTF-32 can be found here: http://www.unicode.org/faq/utf_bom.html

If a new finite limt on password length is needed, I suggest 128 Unicode characters as the new limit.

L0ck wrote Jan 16, 2015 at 2:57 PM

Voted +1 :)

Enigma2Illusion wrote Jan 19, 2015 at 2:53 PM

This will cause performance issues for the other hashes except SHA-512.

http://sourceforge.net/p/veracrypt/discussion/technical/thread/ad0bcd60/#fc20

Mounir wrote:
The 64 bytes limit for the password was chosen because it's the smallest block size of all used hash algorithms. Thus, we have the guarantee that no matter what hash algorithm is chosen as PRF, the hash compression function will only be called once per-loop of the PBKDF2 algorithm.

If the password is longer than 64 bytes (for example 128 bytes) and if the used hash algorithm has a block size of 64 (like SHA-256, Whirlpool or RIPEMD-160), then the hash compression function will be called twice per-loop which will basically double the time taken by the key derivation.

Only SHA-512 has a 128 bytes block size and for this algorithm a password of 128 bytes maximum can be used without loosing performance.

commenter8 wrote Jan 19, 2015 at 11:08 PM

SHA-512 has to process at least two 128-byte blocks, of which 16 bytes are reserved for the message length. Therefore 240 bytes are available for the password, not 128. See page 39 of this Purdue University cryptography lecture: https://engineering.purdue.edu/kak/compsec/NewLectures/Lecture15.pdf

With UniCode BMP as the character set and UTF-8 representation, in the worst case three bytes per character will be used. Most of the time only two bytes will be needed. Worst case, 240 bytes provides room for 80 UniCode BMP characters. Most of the time there will be room for 120 UniCode BMP characters. If only the ASCII characters are actually used, then only one byte per character is needed and thus a 240-character passphrase can be accepted.

It therefore seems best to avoid specifying an exact maximum number of characters but still let the user know that there is a limit and that VeraCrypt will issue a warning if the proposed passphrase is too long. The actual warning should advise the user to try shortening it by X characters, where X is calculated as (240 divided by (the number of bytes needed to represent the passphrase proposed by the user, divided by the number of characters proposed by the user)) minus the number of characters proposed by the user. So if the user's proposed characters all happen to need two bytes each, and the user proposes 123 such characters, then 246 bytes are needed to represent the proposed passphrase, the user's calculated character budget is 120 characters, and the user will be advised to shorten it by three characters.

commenter8 wrote Jan 19, 2015 at 11:27 PM

SHA-512 would be able to use only one block ONLY if the password length in bytes was (128 - 16 =) 102 at most. That would be 34 worst-case UniCode BMP UTF-8 characters, 51 typical UniCode BMP UTF-8 characters, or 102 ASCII-range UniCode BMP UTF-8 characters.

commenter8 wrote Jan 19, 2015 at 11:47 PM

It should also be noted that the user who proposes a very long passphrase may actually be happy to see it cause a performance penalty, as this makes life much more difficult for the attacker. And the user who chooses a passphrase that is short enough to fit into one SHA-512 block will never see any difference. If the limitation on passphrase length were to be removed entirely, with appropriate documentation to the effect that longer passphrases may result in longer processing time, that would free users to make their own choices about password length while leaving users who stay within the current limitations completely unharmed (zero performance penalty).

idrassi wrote Jan 20, 2015 at 8:46 AM

Thanks commenter8 for all these inputs but I think I didn't use the correct language in my answer about the 64-bytes limit and that's why part of your thinking is not correct. Actually, the second call to the hash compression function I was referring to in my Sourceforge posting is linked to the HMAC implementation where we need to do an extra hash if the password is longer than the block size. So, if the password is 128 bytes and SHA512 is used, then this extra call will not happen.

SHA512 is not used by everyone and Whirlpool which has a 64-bytes block size has a strong following. For such users, I agree that it is enough to inform them about the impact of the extra hash call on the mounting performance.

kbosak wrote Mar 21, 2015 at 6:15 AM

Using small case a-z, perfectly random, you get 256 bits of entropy with 55-letter password
a-zA-Z 256 bits with 50 letters
a-zA-Z0-9 256bits with 49 letters
a-zA-Z0-( plus specials - even less.
Therefore the only reason for passwords over 64 letters for encryption scheme that has 256bits of possible outcomes is when your pasword is dictionary based, like myverylongpasswordplusnamesofsomestupidMoviesAndAbigDogThatEatsEverybodyAfter2013-13-13

If it is very complicated like bf823fxl237-23bx5l.d then you can just fill up to 64 bytes with keyfile-based data and get that 256 bits of entropy on authentication.

morethn64chrspls wrote Jul 25, 2015 at 1:52 PM

Just signed up to vote for this. I'm not a programmer or a cryptography specialist so I don't have too much input regarding the technical details, but I will be using a combination of a memorised, long static passphrase combined with a static password generated by a YubiKey, which currently would exceed 64 characters. I don't mind taking a performance hit for longer password length, and intend to select SHA-512 or larger anyway if it's available.

+1 from me!

codegrind wrote Jan 8, 2016 at 1:21 PM

The 64 bytes limit for the password was chosen because it's the smallest block size of all used hash algorithms. Thus, we have the guarantee that no matter what hash algorithm is chosen as PRF, the hash compression function will only be called once per-loop of the PBKDF2 algorithm.

If the password is longer than 64 bytes (for example 128 bytes) and if the used hash algorithm has a block size of 64 (like SHA-256, Whirlpool or RIPEMD-160), then the hash compression function will be called twice per-loop which will basically double the time taken by the key derivation.

Only SHA-512 has a 128 bytes block size and for this algorithm a password of 128 bytes maximum can be used without loosing performance.
Do we really care about performance of password derivation function?? Really?? So why are we doing 100000 iterations?

The fix seems easy: increase password length limit to 128 bytes and divide number of iterations by 2.