how to determine version of volume (clarification needed for release notes...
Open source disk encryption with strong security for the Paranoid
Brought to you by:
idrassi
Menu
▾
▴
In the release notes the following statement needs clarification: To avoid hinting whether your volumes contain a hidden volume or not, or if you depend on plausible deniability when using hidden volumes/OS, then you must recreate both the outer and hidden volumes including system encryption and hidden OS, discarding existing volumes created prior to 1.18a version of VeraCrypt.
Is there a way to determine which version was used to create a volume? (e.g. I can't remember when I created the volume)
Maybe a tool (script or binary) could be provided to test a volume/container.
The VeraCrypt Volume Format Specification does not store the version number of the software.
Do you have any archival files in the volume that would be the earliest date that you can compare to when 1.18a was released?
Otherwise if in doubt, you will have to create the volumes again.
No, I don't. I still don't understand why there's no tool to determine if one has to recreate the volume.
Apparently there's a way to determine, if there's a hidden volume (if created with earlier versions). So there should be a tool that returns either "No, you are good." or "You have to recreate the volume."
Short Version:
Ivanov Aleksey who discovered how to detect the presence of hidden volumes would not share with Mounir how he could detect the issue which is due to the way random data was created for the second header when hidden volume existed. However, the hidden volume header was always randomized but as explained, had some sort of identifying characteristics. Without the code from Ivanov Aleksey, Mounir cannot create a tool.
Long Version
Here is the VeraCrypt developer Mounir's explanation in the now defunct CodePlex thread.
https://veracrypt.codeplex.com/discussions/657302
Hi,
A little history first:
I was contacted end of July by Ivanov Aleksey to inform me that he found a way to detect the presence of hidden volumes in TrueCrypt volumes and that it also affects VeraCrypt. After many secure exchanges, he demonstrated the capability to detect hidden volumes with a rate near to 100%.
Although he didn't share with me the details of his technique which he doesn't want to make public, it was not difficult to find out what might be the cause of this: In TrueCrypt and VeraCrypt before 1.18 as explained in the Volume Format Specification, volumes that don't contain a hidden volume have a header + random data whereas volumes that contain hidden volume have two headers + random data.
Normally this difference should not be a problem because the headers are encrypted using a key derived from their respective passwords and the random data is actually the result of encryption of zeroes using a temporary random key. Thank to the properties of XTS encryption mode, the encrypted data should look random to an attacker who can not get information about the format of the data without having the password.
But it appears that this assumption is not always true and that at least it possible to build a distinguisher that would be able to detect if the volume has one header (no hidden volume) or two headers (with hidden volume).
Luckily, there is an obvious way to protect about such attack: volumes should always have two headers! When there is no volume header, we just create a "fake" hidden volume that uses a random master key. This way, the distinguisher mentioned above will always return that there is a hidden volume without being able to say if the hidden volume is a fake one or not.
This fix has been implemented in VeraCrypt 1.18a. It is not possible to apply the fix to existing volumes so users who rely on the hidden volume feature must create new volumes using the latest version of VeraCrypt and discard existing volumes. Of course, such users must install/use only VeraCrypt 1.18a or above in their machines so that the plausible deniability associated with hidden volumes is preserved: if they are coerced into revealing the hidden volume password by an entity that has the distinguisher capability mentioned above, they can reply that they created the volume using VeraCrypt 1.18a or above which created fake hidden volume header and this can be easily proved by handing out the outer volume password.
So to answer your question: If you relay on the plausible deniability of the hidden volume feature, you must update to version 1.18 on all your machines and re-create all your volumes (both outer and hidden) using this version. Changing the passwords is irrelevant to this issue so you can keep them unchanged.
Thank you very much for the detailed information. I guess this guy is selling the exploit to LEOs.
The problem is I can't recall which Veracrypt version I used to create the volume. Copying a few terabytes twice is time consuming and I hoped to avoid it.
I believe that Ivanov Aleksey did not want the exploit to be made public and he contacted Mounir to make him aware of the vulnerability in TrueCrypt/VeraCrypt which would impact any profiting on the exploit.
Ok, but if:
"Luckily, there is an obvious way to protect about such attack: volumes should always have two headers! When there is no volume header, we just create a "fake" hidden volume that uses a random master key. This way, the distinguisher mentioned above will always return that there is a hidden volume without being able to say if the hidden volume is a fake one or not."
Then why should we bother recreating a new volume to mitigate the risk? If we have a pre-1.18 volume with hidden part (the existence of which we dont want to disclose), then it has 2 headers. If we create new one with 1.18a and later, it will again has 2 headers. If there is no way to distinguish with which version the volume was created, then why bother???
Last edit: Alex 2020-07-05
Because the randomization for the hidden header pre-1.18a version is different enough to distinguish between no hidden volume was created and the existence of a hidden volume.
But:
"This way, the distinguisher mentioned above will always return that there is a hidden volume without being able to say if the hidden volume is a fake one or not."
In other words, the post 1.18a version will ALWAYS create 2 REALISTIC headers, suggesting that there always is a hidden volume (fake or not, we cant say). Which is precisely what we have in the pre1.18 volumes, when hidden volume has been created of course. So again, why bother?
If my logic is correct, the ONLY thing we can determine is if the pre-1.18a has or has not a hidden volume. But if it has, there is no way of telling whether this is a pre or after 1.18 volume, so it doesnt affect security at all. The only conclusion we can make is that, in case we find a pre 1.18 volume and it shows no traces of hidden volume, then we can conjecture that it is a pre 1.18 volume without hidden part. Thats it, nothing more.
I see your point assuming that no one can determine if the volume was created prior to the 1.18a version which as the developer pointed out would remove plausible deniability.
If you are a high value target of a government agency, I sure they know already. :)
I was thinking i was a high target back in the 80s-90s when my hormones were way more than my encryption key bits... now i am strongly against any crazy stuff like custom PIM, 100 character passwords, N keyfiles, cascaded ciphers, plausible deniability, etc.
But its just my logic and I just wanted to give the OP some peace of mind.... and an advice not to scratch his HD, reformatting, copying, etc :)
P.S. Plausible deniability is a joke in our world of "highly likely" branding and accusations.............