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

Veracrypt 1.0e rejecting my passcode

Topics: Technical Issues, Users Discussion
Feb 2, 2015 at 7:14 AM
Greetings. I did a FDE on Windows 7 (new WD HDD) with Veracrypt 1.0e about a month ago . Successfully accessed my OS on about 100 attempts. Now Veracrypt has stopped accepting my passcode. Hard drive shows up on a different machine and is healthy. I am certain the passcode is correct as I have been using it for a long period. Repair option 3 (restore key data) rejects my passcode as well. Neither will it accept the passcode for permanent decryption. I even attempted accessing the HD's files by opening it on a different machine by mounting without pre-boot authentication. No luck there.

Any suggestions on how I should proceed with this problem? Side note: I was a user of Truecrypt FDE for many years. Never had an issue of this type with TC. Thank you!
Coordinator
Feb 2, 2015 at 10:17 AM
Hi,

As with any other computer program, VeraCrypt doesn't change its behavior if the input parameters are the same (input parameters here are password and volume header).

Since it doesn't work anymore, this means that either the passsord is not the same or the header has been corrupted.

You seem to be certain that the password is the same so the other left possibility is that the header has been corrupted.

Question: are you able to boot using the rescue disk created during the encryption process? You didn't mention this in your message where you only talk about the repair option.

If the password is indeed correct, then you should be able to boot using the rescue disk created during the encryption process.
If even with the rescue disk you are not able to boot then I'm afraid that the only plausible explanation is that you forgot your password or at least you are mixing some characters.

Thus the boot test with the rescue disk is very important to validate the cause of your issue.

Concerning TrueCrypt, I remember many posts on their forum where people reported similar issues concerning the fact that their password is not accepted anymore. These messages were often deleted since it comes either from people forgetting their password or from corrupted disks for which nothing can be done.
Feb 3, 2015 at 7:51 AM
Idrassi, thanks for your speedy reply. I am absolutely certain that the passcode is correct, as I had been using it with no issues for a period of a month or so, two or three times every day. Furthermore, I wrote the passcode down on paper prior to the FDE process for future reference. The passcode I successfully used for a month matched perfectly the hand-written passcode. I have tried many dozens of times to access my OS with no success. Yes, I did create a rescue disk during the encryption process. Using this disk, I was unsuccessful in restoring the volume header and unsuccessful in permanently decrypting the system partition. In both instances, "incorrect password" was the message. Is there anything else I could be overlooking?
Coordinator
Feb 3, 2015 at 8:31 AM
Hi,

I guess you also tried booting using the rescue disk. Right?

Anyway, the rescue disk contains a copy of the original header and if the original password is used then it will be recognized. This is a mathematical certainty :-)

Since it doesn't work with the rescue disk who is guaranteed to have never changed, the only explanation is that the rescue disk is not feed with the correct password (logical deduction again)

You are sure that you are typing the same password. So, in order to keep up with the logical reasoning, the only possibility is that what you type on the keyboard doesn't arrive as it is to the bootloader program running from the riscue disk.

Have you changed the keyboard lately?

I'm afraid this is the maximum I can go with a logical analysis...something is missing because if we take them all the elements together we arrive to a paradox!

Feb 5, 2015 at 9:13 AM
Yes, absolutely, I have been using the rescue disk, and I have been attempting a direct boot from the rescue disk. I only own notebooks, so the keyboard has not changed. I have even removed the encrypted HDD and placed it in another notebook (to test from a different keyboard) and attempted a boot from the rescue disk. In all instances, "incorrect password" is the outcome. The passcode is one I have used for many years every day on various machines, and on the current HDD that I cannot open, I have used it for about a month. Furthermore, it is the ONLY passcode I use both my machines. So, my entering a wrong passcode is not a possibility. There was nothing unusual about the last successful machine start or shutdown, no power surges. I believe you are correct by saying the header has become corrupt. But why won't the rescue disk repair this? This might be a clue to the problem: I noticed that during the testing phase of the FDE process, the passcode was rejected many times before finally being accepted. Is there a possible connection between these two events?
Feb 5, 2015 at 10:57 AM
Edited Feb 5, 2015 at 11:09 AM
Good questions Jason, regarding what you said about:
"why won't the rescue disk repair it, and during the testing phase of the FDE process, the passcode was rejected many times before finally being accepted".

@idrassi,
something related concerning the header.

I remember Truecrypt stored a second copy of the header on the back of the drive. That being said, it was never really necessary to make backups of the header on data drives, and I thought this applied to system encrypted drives as well. Does VeraCrypt store a second copy of the header towards the end of the drive? I'm not even sure where to find this in the documentation.
Coordinator
Feb 5, 2015 at 7:56 PM
It is not normal at all that the rescue disk reject the correct password. I would say it is impossible unless there is bug or the RAM/CPU is malfunctioning.

This is the first such report of a rescue disk refusing a correct password. If there was a bug in the VeraCrypt, it would most certainly have been discovered by many others who use FDE on different type of hardware. Moreover, it is very suspicious that the "passcode was rejected many times before finally being accepted". This is simply unheard of and technically impossible unless there is an issue with the RAM/CPU.

A plausible hypothesis is that your RAM provokes errors and is malfunctioning (probably the error affects only the first 64KB segment used by the BIOS) That would explain the erratic behavior on your machine. You can boot on an Ubuntu CD for example and choose "Test Memory".

You already tested from another machine and it didn't work...this is puzzling. Do the two machine have the same keyboard layout? Are you using a US QWERTY keyboard?

One thing to know is that the password for system encryption must be entered using US layout. This is the default when booting. The trick is that if your keyboard is not US QWERTY (for example French AZERTY like myself), then every key you type is mapped to its equivalent in the US keyboard (for example, '%' in French keyboard translates to '"' and '&' becomes '1'). This may play tricks to users if there use digits in there password and if they don't use the numeric keypad of they keyboard. For example, if we take the French keyboard as an example again:
  • if you type the digit 1 using the numeric keypad, it will be translated to 1. The same holds for all digits entered via numeric key pad.
  • if you type the digit 1 using SHIFT and the key above A, then it will be translated to '!'. And here comes the potential problem.
So, when entering the password for system encryption, what matters is not the value of the keys your are pressing but the keys themselves!!! As the French keyboard example shows, if your password contains digits, you must enter these digits using the same method used during the creation of the volume, either numeric key pad or SHIFT combined with other keys.

Are you in this type of situations?

@movingkey: For system encryption, there is no backup header at the end of the drive. The reason is that we can't perform the needed file system shrink operation while Windows is running. For non-system encryption, the shrink operation is done first to ensure that all data are put at the beginning of the drive, leaving all free space at the end so that we have a place to put the backup header. That's why the rescue disk is very important for system encryption.
Feb 5, 2015 at 9:28 PM
Edited Feb 6, 2015 at 9:39 PM
Thanks idrassi
I was not aware of that. Makes sense. Thanks

@JasonBrengel

Did you ever run the memory test? Also, keep in mind, if your power supply is failing, it can cause voltage issues with your memory and cause corruption. Sometimes even the regulators on the mother board can go out of range. All kinds of things can happen. Everything else seems normal?