Why is the password limited to 64 characters?

Topics: Feature Requests, Users Discussion
Jan 14, 2015 at 7:02 PM
Mounir, I suggest it to be longer. Sometimes this is a security issue.
Moreover, it gives much greater freedom in creation of the password.
Jan 14, 2015 at 7:47 PM
As VeraCrypt has a high minimum iteration count, the need for longer password is not really there.

If you know of a technical reason the password length needs to be increased, please let us know and I am sure we would all enjoy discussing it.
Jan 14, 2015 at 10:01 PM
It's possible to have extremely high security with 20 to 64 characters, especially if those characters are UniCode (see https://veracrypt.codeplex.com/workitem/62). But having even more characters may still be a good thing, simply to give users more freedom to create very secure passphrases that they can easily remember. How many password characters would you consider to be enough?
Jan 14, 2015 at 10:05 PM
I am not against increasing password length in principle.

However I wonder if this will encourage weaker password choice by unskilled users ?

They may be under the impression a quote from a song or book is very long and so very secure, which it isn't.
Jan 15, 2015 at 12:51 AM
Regarding passwords, has anyone checked out my distributed network proposal? It would be nice to have your analysis on the matter.
Jan 15, 2015 at 3:21 PM
I have been giving this more thought, my heart says yes increase password length.

My head says that 64 random characters, when combined with the brute force protection offered by VeraCrypt, are stronger than the master key :)

This feature request is something of a dilemma. Yes password length increasing does add the possibility for more security, but does it encourage weak password choice by less aware users, probably.

Is it better these less skilled users choose a longer password, song lyric, quote etc or a shorter more random password ?

The high minimum iteration count does protect these users more than a low count would, so I guess this feature could be added. A simpler increase in security would be more iterations, this would allow the user to use shorter passwords which are more easily remembered.

The question should be, is it worth the extra coding time and is there a risk of introducing a bug or weakness ?
Jan 15, 2015 at 4:10 PM
I'm sure that in 99,9% of the cases it won't increase the security of VC. More iterations will increase the security more than the "possibility" of a long password.
Jan 15, 2015 at 4:20 PM
Edited Jan 15, 2015 at 4:25 PM
L0ck, and all the paranoids :D/serious users:
Of course, 64 random pass is something unbreakable (in the foreseeable future), but also absolutely uncreative --> thus, unmemorable. (if you use it everyday and has got one like that - so ok. But if you have got more than one + you dont use it more than once a week + you must change the password once a month by the policy....oh, shit!)

The password is the most important thing that the user has got (I am talking about the issue that depends ONLY on the user himself and not the program, for example the iteration issue). Thus, I think that there must be given the maximum freedom in his length and, if possible, as commenter8 mentioned, the UniCode issue).

Veracrypt is not build for the average user who has got no clue how random the password must be/the length VS simplicity issue. VeraCrypt & Mounir should not protect the dumb from himself. The user who will fail with the password issue you mentioned, L0ck, has got nothing more than a diary/porno to hide. Thus, VeraCrypt is not for him at all (he has got winrar :D). And this average user will fail with or without 30/64/128 limiter and will put his birthday or a qoute from Beatles song without any significant change.

I started this thread, because the advanced user like you, L0ck, (and Big Companies with "real secrets") could get a great possibility of creativity + memorability + security - All in ONE! If we extend the 64 ceiling.

It is very difficult to remember a pure 100% random pass more than 30 symbols (especially if you dont use it daily and if you've got many of them), but some Latin quotes, for example, mixed up with some symbols/numbers will be great. The problem now is the length of the password. So, here comes the 64 limitation that I want to break. 30 UNMEMORABLE (but very secure) random symbols in the password could theoretically beat my 30, or even 50 very memorable, mixed up with symbols, two Latin quotes. In this stage comes the length limitation.

For example, one could take three quotes from Julius Caesar(if he likes Julius :-)) and mix it up with special symbols. This is very long and memorable, and the entropy of this password will be extreme secure, as in the random pass case.

Our company works with very sensitive data a lot (and we are not the only one). And, as a consequence, there is this problem. *(no, KeePass is not a solution here. We must remember it and be undependable of something external as far as possible).
You make a random AND secure pass, but not memorable (especially if you have got a lot of levels of security -> various containers/passwords to the encrypted systems). So, I see a very good solution in extending the pass length to gain both security and memorability.

This is why I asked Mounir, the developer of VeraCrypt, why is this limitation? is it critical? and could it be extended?
Jan 15, 2015 at 4:47 PM
destrukt wrote:
I'm sure that in 99,9% of the cases it won't increase the security of VC. More iterations will increase the security more than the "possibility" of a long password.
I agree destrukt, more iterations are good.

You will be pleased Mounir will be providing the opportunity to increase iterations from the existing default. Decreasing iterations has no merit on VeraCrypt full. :)

I award you 1 paranoid point :) LOL
Jan 15, 2015 at 4:47 PM

Thank you for the compliments algreider8 :)

I award you 1 paranoid point LOL :D

I understand and fully agree with your implication that VeraCrypt is not for the home or unskilled user, facing a low skilled and poorly funded threat model.

I think a turning point has been reached, VeraCrypt is just too special as it is to start to dumb down to the lowest skilled user, with the least powerful hardware.

Mounir has noble intentions to care for everyone, however it has been demonstrated some people refuse to be helped. In light of this I believe VeraCrypt is on track to remain the uncompromising standard to compare other encryption applications to.

As you infer there are other more suitable products for these users, there was even an offer of VeraCrypt Lite which did not seem to be accepted. Their intention was to cripple VeraCrypt full directly, which is unacceptable.

I understand and accept your argument for longer passwords, I have not rejected it. My only concern was if this complicated things for Mounir or could potentially cause other issues.

With the minimum iterations remaining and the possibility of increasing them looming I suspect it is "safe" to allow longer passwords even if they are based on phrases / quotes etc.

Thanks :)
Jan 15, 2015 at 5:28 PM
The limitation arises because the header must include a finite number of characters for storage of the encrypted password. The TrueCrypt header allocated 64 characters for this purpose. If more characters are allocated then the header either becomes larger or has to reduce its allocations to other areas.

algreider8, I asked already but you did not answer: How many password characters would you consider to be enough?
Jan 15, 2015 at 5:45 PM
Edited Jan 15, 2015 at 5:45 PM
I tried to find some option to write a private message to you, but failed to find one. So I will write here something more general AND something addressed to you personal.
"I think a turning point has been reached, VeraCrypt is just too special as it is to start to dumb down to the lowest skilled user"
Yes it is. However, there will be never some kind of "no turning point", L0ck. The simple users (speed is everything :D) and conscious enemies (N*A) will always try to dumb down VeraCrypt. This is very logical from their perspective.
"Their intention was to cripple VeraCrypt full directly, which is unacceptable"
L0ck, their intention WASN'T. It is still there. And it will be there always. But if we guard Mounir and he will feel confidence in the users he is building the VeraCrypt for, they will fail. Like this time!

Now, the personal message: (you should put some account, so paranoids could directly write to you :D)
L0ck, the last war you led here (in the looong topic) was extremely important. Every war on the security issue (and it wasnt the only one you participated!) will bring us either to preserving our status qou/greater security, OR to point of no return when Mounir will weaken security (no matter with what intentions).
We, the "geeks/paranoids/advanced users" have won this war thanks TO YOU, L0ck! I am not kidding. I dont know about the others, but I, personally, dont have time to write here. Еspecially in light of the fact that my English is not perfect -> it is not fluent and it takes me too much time to write a comment.
So, coming back to the war you led here, your defense was extremely important! Extremely!

We should all realize, that Mounir (->VeraCrypt) can keep standing up staunchly ONLY IF he will see and feel the full support of the community, more precisely "the backbone of the community" (which consists the advanced security oriented users & companies). And here you came up, L0ck. Believe it or not (finally I have time and I read all your comments), you defended all of us, especially in the last long topic, whether we realize it or not.

You must firmly know, that this forum, these discussions, as I call it "wars", are not children's games, as one could think. These discussions have direct impact on Mounir --> on the future of VeraCrypt. Which should&will become the best crypto-softwarе out there after the Fall of TrueCrypt.

L0ck, Continue your valuable work. Mounir will maintain the code and you - the ideology :D

I take off my hat to thee, Friend.
God bless you.
Jan 15, 2015 at 5:57 PM
Edited Jan 15, 2015 at 5:58 PM
algreider8, I asked already but you did not answer: How many password characters would you consider to be enough?
Commenter8, the more - the best. Lets say 100.

The question remains, whether the extension will arise some other critical issues/flaws in the security code or not. And whether Mounir will have to rewrite too much code for it.
Jan 15, 2015 at 5:59 PM
algreider8, you said it all. I agree, keep fighting L0ck, we need to win the war :-)
Jan 15, 2015 at 5:59 PM
algreider8 wrote:
I take off my tin foil hat to thee, Friend.
Jan 15, 2015 at 6:00 PM
Heavens above.

I have read the User selectable KDF iterations thread.
I find it incredulous anyone would wish to diminish iterations, the primary feature which set VeraCrypt apart. May I add my congratulations L0ck, you defended VeraCrypt most eloquently.

Can I assume VeraCrypt will retain this stance indefinitely? Is there still a requirement to remain vigilant in case of further attempts to force this rather odd request?
Jan 15, 2015 at 6:50 PM
128 characters would therefore be the new maximum, double the current limit.
Jan 15, 2015 at 7:19 PM

Thank you once again algreider8 for the support and kind words :)

I am almost too embarrassed to reply LOL

Yes a PM system would be useful.

I am only a member here, as you say more members need to let Mounir know they do not want VeraCrypt to be weakened in any way. He was probably feeling alone in his thoughts until a few of us joined in.

There are many thousands of users who remain silent as they probably assume there is no challenge to VeraCrypt's security. However we had 4 users cause a disproportionate fuss over a feature which should have been immediately laughed off the forum.

Please encourage your friends to join the forum if another attempt to undermine VeraCrypt is made.

I will be writing to the CipherShed team soon as I hope they will finally get something released. If they have an option to cripple iterations, which is likely, we at least have another product to send to the n00bs to, so hopefully they will get the message that VeraCrypt is no compromise security.

Keep up the good work and those suggestions coming in algreider8 :)

I simply don't have enough "paranoid points" to give you :)


Thank you also for the kinds words. It's wonderful you feel the same and wish the best for VeraCrypt.


Thank you also :)

I must admit their intentions seemed odd. I found it more strange that the offer of a VeraCrypt Lite for home users was not readily accepted.

All I can guess is there was an attempt by a concerned rival to drag VeraCrypt down to their level.

I truly hope Monuir remains strong in future, VeraCrypt is a "special" application, I am proud to be paranoid enough to use it :)
Jan 15, 2015 at 11:09 PM
Hi all,

First, thank you all for your participation in making VeraCrypt a better security software. I really appreciate and I do my best to continue nurturing VeraCrypt spirit born more than a year ago.

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.

Also, keyfiles will continue to be mixed with the 64-bytes internal password unless a larger password is specified.

Any thoughts?

Jan 15, 2015 at 11:44 PM
This change should keep in mind the UniCode transition. 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
Jan 16, 2015 at 5:09 AM
Edited Jan 16, 2015 at 5:31 AM
Good day, Mounir.
Thank you for the replay.
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 think it is a very good idea. But you should erase the inscription where the limit of the password is written and add another one. Like "you are not limited in the length of your password, but please do not overdo it :D
Also, keyfiles will continue to be mixed with the 64-bytes internal password unless a larger password is specified.
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
Jan 16, 2015 at 12:43 PM
algreider8 as Mounir seems happy with your request you should make a ticket for it under "issues".

This way it won't be forgotten and we can see it was you who suggested it.

Thanks for your input. :)
Jan 16, 2015 at 1:07 PM
L0ck, thanks for the idea.

Here it is:

Frankly, I don't care if Mounir will add this without knowing it was "my" idea. The most important thing for us should remain the security of our product in this hostile world. However, I understand that without the "issue", he could just forget about it.

Good day.
Jan 16, 2015 at 1:59 PM
algreider8 wrote:
I don't care if Mounir will add this without knowing it was "my" idea. The most important thing for us should remain the security of our product in this hostile world.
I understand what you mean algreider8, but you should receive the credit for your suggestion.

I voted :)
Jan 19, 2015 at 2:17 PM

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


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.
Jan 19, 2015 at 2:18 PM
Edited Jan 19, 2015 at 2:27 PM
Deleted due to duplicate posting. See posting above.
Jan 19, 2015 at 10:06 PM
Edited Jan 19, 2015 at 10:46 PM
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).
Jan 20, 2015 at 7:41 AM
Thanks commenter8 for all these inpus 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.
Jan 20, 2015 at 7:39 PM
Edited Jan 21, 2015 at 12:02 AM
Mounir, I understood that you were referring to the HMAC implementation (I inferred this from your reference to the PBKDF2 algorithm).

At this point I am concerned that the SHA-512 hashing algorithm may be incorrectly implemented. On page 15 of the Purdue cryptography lecture I linked to in my previous post, it explains the rationale for including the message (in this case, password) length at the end of the last block. This inclusion is required in order to strengthen collision resistance from "poor" due to the following scenario: Assume a real password P1 and its hash value H1. Now take a fake password P2 which has hash value H2. An attacker can easily attach extra bits to the end of P2 to force its hash value to become the same as H1, in effect spoofing the real password P1. The professor emphasizes in bold red print that "secure hash algorithms make this ploy impossible by including the length of the message in what gets hashed."

Starting on page 33 of the lecture ("Structure of Cryptographically Secure Hash Functions"), and continuing through page 47, the professor describes in great detail the official SHA-512 hashing algorithm, which by definition must include the length of the message (password) in the 16 final bytes of the last block. It seems to me that if the VeraCrypt password is 128 bytes and those 128 bytes all fit into one 128-byte SHA-512 block, and there are no other SHA-512 blocks to be hashed, then the message (password) length must not have been included in the hashing process, and thus the VeraCrypt implementation of SHA-512 does not comply with the official definition of SHA-512, which is given in the FIPS 180 document available online here: http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf

Here again is the link to the Purdue cryptography lecture: https://engineering.purdue.edu/kak/compsec/NewLectures/Lecture15.pdf
Jan 22, 2015 at 11:54 AM
Thank you again for your details comment, I really appreciate the quality of your post.
The SHA-512 and its HMAC based implementations are correct and they are tested against public test vectors at every program start-up to ensure that the implementation in not compromised and also manually by using the menu "Test Vectors".
I think it is better to look at the code of the function hmac_sha512 to avoid misunderstandings (I removed unnecessary parts, password is reprensented by the variable k and its length by lk):
    if (lk > SHA512_BLOCKSIZE)
        sha512_ctx tctx;

        sha512_begin (&tctx);
        sha512_hash ((unsigned char *) k, lk, &tctx);
        sha512_end ((unsigned char *) key, &tctx);

        k = key;
        lk = SHA512_DIGESTSIZE;
                burn (&tctx, sizeof(tctx));     // Prevent leaks

    sha512_begin (&ictx);

    /* Pad the key for inner digest */
    for (i = 0; i < lk; ++i)
        buf[i] = (char) (k[i] ^ 0x36);
    for (i = lk; i < SHA512_BLOCKSIZE; ++i)
        buf[i] = 0x36;

    sha512_hash ((unsigned char *) buf, SHA512_BLOCKSIZE, &ictx);
    sha512_hash ((unsigned char *) d, ld, &ictx);
    sha512_end ((unsigned char *) isha, &ictx);

    /**** Outer Digest ****/

    sha512_begin (&octx);

    for (i = 0; i < lk; ++i)
        buf[i] = (char) (k[i] ^ 0x5C);
    for (i = lk; i < SHA512_BLOCKSIZE; ++i)
        buf[i] = 0x5C;

    sha512_hash ((unsigned char *) buf, SHA512_BLOCKSIZE, &octx);
    sha512_hash ((unsigned char *) isha, SHA512_DIGESTSIZE, &octx);
    sha512_end ((unsigned char *) osha, &octx);
As you can see, if the password is 128 bytes long, then there is no extra hash call because the first if block in not executed. In the code after the if block, the hash calculation takes place always on buffers whose lengths is fixed and independent from the password lengths.

I think you were misled by my poor way of explaining things and I apologize for this. I should have posted the code in first message to express things more clearly.