origin of maximum password length
Open source disk encryption with strong security for the Paranoid
Brought to you by:
idrassi
Menu
▾
▴
Is the 64 character password length limit in truecrypt/veracrypt a limitation of existing supported ciphers, digests, and memory or is it an arbitrarily assigned length that could as easily be set to 128, 256, or even 512 characters?
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.
Thanks. Your explanation is especially appropriate given the comments on the long boot time thread.
If a 128-byte password is allowed then 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 actually available for the password in that case, 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.
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.
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).
Thanks for all these input but I think I didn't use the correct language in my first answer and that's why part of your thinking is not correct. Actually, the second call to the hash compression function I was referring to 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.
Well, that explains why Diskcryptor, among others, was able to boost the password limit to 128 characters. It's because it always uses SHA-512 as it's main hash function. Personally, I'd like to see such a feature implemented in Veracrypt, as an option for those who are perhaps a bit extra paranoid, since SHA-512 is already supported.
FYI: This issue as been formally requested by algreider8. Sign into CodePlex to vote up the feature.
https://veracrypt.codeplex.com/workitem/71
I vote that the SHA512 algorithm is allowed to use a password of 128 characters in length so as not to affect performance by having 128 bytes
I propose to look for new hash algorithms that exceed 64 bytes, so that users can use longer passwords without affecting the performance of veracrypt
ask how many bytes does streebog have?
See the developer’s analysis on password length and estimates to crack them in the following posts.
https://sourceforge.net/p/veracrypt/discussion/general/thread/09696187/#491d
https://sourceforge.net/p/veracrypt/discussion/general/thread/09696187/#65da/ca99
64 characters for a password composed of mixed letters and numbers is unbreakable unless you choose a simple pattern for the 64 characters.