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

System Drive not decrypting

Topics: Technical Issues
May 18, 2015 at 9:23 PM
Hi, I have a very strange issue.

Firstly, I have two drives on my PC (SSD, HDD). On my SSD there are three Partitions, one for Linux and the two for Windows 7. On my HDD there is particularly my User-folder. Both Drives are encrypted with the same password, to encrypt them on Startup, because otherwise, Windows won't start.

Anyway, my Linux has overwritten the Veracrypt Bootloader, I basically fixed this and restored the Veracrypt Bootloader with the Rescue Disk (it wasn't the real Rescue Disk of this particular encryption, but I de- and encrypted my drives several times with the same pw, so I took an "older" one, which shouldn't make any difference, should it?)

Now to my problem: When I try to mount the two drives in Linux, there's no problem with the HDD, but everytime when I try to mount my SSD it says: "Incorrect keyfile(s) and/or password/PRF or not a valid volume.". And yes, I also tried it with the system encryption option. This issue appears since the Veracrypt bootloader suddenly was gone (probably because Linux has overwritten it). When I try to enter the password in my restored bootloader, it also says "wrong password". Any ideas?
May 18, 2015 at 10:40 PM

Actually, Rescue Disks are different from a system to another. Only the bootloader is common between them since the header key data are different each time.

I hope you only restored the bootloader not the key data; otherwise it will be impossible to boot/decrypt your system.

From the decryption of your issue, it appears that your Linix didn't only overwrite the bootloader but it also overwrote the hearder key data. In this case, the only solution is to use the real Rescue Disk created during the encryption of this system in order to restore the key data.
If you didn't burn/backup the Rescue Disk, then you are in big trouble.

Just a question: your SSD contains two partitions for Windows. Which one is failing to mount on Linux? I guess it is the one that you are using for Windows system and the other one should load normally (unless it was also overritten by Linux).
May 19, 2015 at 1:48 PM
Yes, I only restored the bootloader. But how is it possible, that Linux overwrote the key data?

No, it's just one Windows. There is always the normal and the System Reserved Partition with 100 MB, which is not encrypted.
May 19, 2015 at 1:52 PM
I don't know what operation you did on Linux so that it overwrote the bootloader. Can you give more details on the actions that lead to this?
If you know which Linux component is responsible for this, you can check how much data it actually wrote and from their you can deduce if it touched also the key data.
May 19, 2015 at 2:00 PM
I don't know what lead to this. But it was not the first time, that this happened. I suspect apt-get update or something like that, because that seems to be the only parallel.

What would happen, if I restore the wrong key data?
May 19, 2015 at 2:28 PM
It probably happened because of a kernel update that also force grub to write to the bootloader.

If you restore the wrong key data, the correct master key will be lost and instead you will end up with the a wrong master key. This means that you will get the wrong data when you mount the volume since the decryption will use the wrong key. In other words, data will be lost for ever.

That's why it is important to always backup the rescue disk or at its iso file and that's why VeraCrypt wizard and messages insist on this.

You can find on the internet resources related on how to configure Linux to boot along side an encrypted Windows using TrueCrypt. The same procedures apply to VeraCrypt.
May 19, 2015 at 2:43 PM
And this can not be fixed by restoring the correct keydata afterwards?
May 19, 2015 at 2:48 PM
But this sounds a bit illogical, if Linux overwrote the keydata for real, then the password should still be accepted, but the data should bei wrong, right?
May 19, 2015 at 3:26 PM
Yes, you can always fix the situation by restoring the correct key data.

The password validation is implement through the derivation of key from the password and this key is used to decrypt the key data on disk and the decrypted data consistency is check by looking for a hard coded string "VERA" and by verifying the internal CRC. If any of those checks fails, then a wrong password error is reported.
You can find the specification of this format here:

If Linux overwrote the key data, then the decrypted key data will not have the expected format and the password will be rejected.
May 19, 2015 at 3:35 PM
All right, thank you very, very much for your help!
May 19, 2015 at 9:26 PM
Ok, I now restored the keydata with an older rescue disk. Surprisingly it worked, which makes me greatly relieved, although I don't understand why. According to your information, the keydata should only be restored correctly by the one made at the specific encryption process, right?
May 20, 2015 at 12:33 PM
Yes, the key data is different from a volume to another because the key data contains the master key which is different each time.

So, you say that you used a rescue disk belonging to a system A to restore the header key data of a different system B and you were able to boot system B? Well, this is technically impossible and there are only two explanations:
  • The rescue disk you used belongs to system B and you wrongly thought that it belongs to system A.
  • The random generator on your machines is deeply flawed and you always get the same random bytes each time (I really doubt it).
May 20, 2015 at 3:27 PM
I am absolutely sure. As you know, I en- and decrypted my drives several times using always the same password. The last time I did this was about two weeks ago. The rescue disk I used, was created in february. Is there a way to show the keydata of rescue disks?
May 20, 2015 at 9:21 PM
No, there is no way to show the key data value held by the rescue disk but it can be implemented (I don't see any need for it).

As I said, it is impossible to boot a system B with the key data of a system A: this is a fact.
By the way, are you sure your system was encrypted in the first place? Maybe you just started the encryption and you hit "defer" after the first boot which would mean that no data are actually encrypted (0% encrypted shown).
May 21, 2015 at 5:50 PM
Yes, I am absolutely sure, that my system is encrypted. What do you mean by "it can be implemented"?
May 21, 2015 at 7:43 PM
Displaying the key data held by the rescue disk (or at least portion of it) can be implemented but I personally lack time to do this as I'm working on other important parts of VeraCrypt. I also think that this is only interesting for diagnosing purposes so the priority for such development is low compared to the long list of badly needed features.