Tried to find info on this but, to my surprise, was unable to. Tails seems to, quite effortlessly, nullify the entire plausible deniability aspect of hidden volumes. A raw drive with a normal Veracrypt volume will show up as a single partition, but the second you introduce a hidden volume, Tails then displays multiple partitions. Verified repeatedly starting with a raw disk.
I mean, isn't distinctly different behavior of normal volumes vs hidden volumes a pretty big hindrance for the whole plausible deniability thing?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With hidden, you have 2 passwords, one decoy for police/airport/iron maiden/whoever might force you to reveal pass, and the other "real" for yourself with data you care about. Mount with decoy, you will see ONLY decoy, mount with real pass and you will see both volumes. That's how it works.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Uh... actually seems like it's you that needs to rtfm there billy. First off, what you replied with has nothing at all to do with what I said. The entire purpose of the hidden volume, is that "whoever" can't say "You have a normal Veracrypt volume and a hidden one, I can see them both right now with my own eyes, give me the passwords for both."
But that's exactly what tails does, without any password entered, without any step taken AT ALL, beyond launching Tails proprietary veracrypt tool, multiple partitions are listed, both the main partition of the drive, and another partition that just happens to be the size of the hidden partition.
Tails behaves differently with a disk that has a normal volume than it does with a disk that has both a normal and a hidden volume, which is basically a big neon sign screaming THERE IS A HIDDEN VOLUME HERE. I'm not sure how much more simply I can explain it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"I can see them both right now with my own eyes, give me the passwords for both."
You have clearly no idea how hidden volume works. Hidden volume is hidden INSIDE an existing one, it is not hiden as "it does not exist at all".
Read how it works and then complain. Just because you're lost doesn't mean your compass is broken ;-) Tails is nothing special, just another linux distro. Actually I use it too with veracrypt and it works as it should.
So if you make many partitions, you will see all of them. If they are full of random data, one can belive there are encrypted data inside, but no one can ever prove there's a hidden volume in either of them, or how many levels of hidden volumes there are.
And even when you unlock with decoy pass, no one can still tell whether you unlocked with "real" password or "decoy" one.
You can also mount with both real and decoy password to fill the decoy with decoy data and veracypt will even protects your hidden data... but it is all explained in veracrypt's manual.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You can say this as many times as you wish, but at the end of the day it's meaningless. I've provided the steps to verify the issue, you arguing like a child is just wasting your time and mine.
Read how it works and then complain.
I've read how it works, so I now get to complain? Wonderful. Although I do have to say I'm not so much complaining as trying to make people aware of, potentially, a massive issue. Those are usually the types of things people want look into, you know, when their egos aren't so fragile that all they are capable of is dismissing them outright. (See what I did there? That's you).
First, Tails absolutely is something special, and not just another linux distro, specifically because it uses a custom-built tool for interacting with Veracrypt volumes, not a default Veracrypt installation. Neat huh? Isn't information neat? When you open your mind, you'll find it can process, and even store, information--crazy!
And here's the bottom line. Hidden volumes, what's not to get?
Every time I tested this issue, I started with a raw 2TB WD HDD. Raw means no partitions, no file system.
Veracrypt (Windows 10 install): Tools -> Volume Creation Wizard -> Encrypt a non-system partition/drive -> Hidden Veracrypt volume -> Normal mode -> Select RAW HDD -> **** -> Encryption Options Default -> Size, uneditable -> Password -> Large Files - Yes -> ExFAT, default cluster, or 4KB depending on what the drive is for, Quick Format obviously left unchecked. So... How does my failure to understand the concept of hidden partitions have an impact on how the application, using the default settings of the hidden partition creation wizard? Is there a certain way I should be pushing the next button?
Now, if I take the drive that I created using the steps above, and connect it to a PC, boot that PC with Tails, and launch the Tails veracrypt app, I am presented with not one, but multiple "Partitions and Drives" to unlock.
If I take the same exact make and model drive, and using the VeraCrypt Volume Creation Wizard to create a Standard VeraCrypt volume, the veracrypt tool in Tails only lists a single "Partitions and Drives" to unlock.
This has nothing to do with passwords, mounting, or any of that, and you know how you can tell? In my steps to recreate I never said you had to mount anything, or do ANYTHING AT ALL, beyond boot Tails and run the built in veracrypt app. Do you think a third party would be able to do that without your hidden volume password? Stick in a flash drive and click a single icon? I feel like they could, I really do.
I would love for someone to say "You're doing x wrong which is what is causing this" or "This is something we were unaware of" but you are doing nether. All you are doing is yelling "UR WRONG CAUSE ME SAY SO AHHH!" and that's dumb, because it accomplishes nothing. That's how you think you maintain the security of a security application? Someone reports a possible issue and you say "I don't think that's true so therefore it's not true."? Yeah, that's a terrible system.
**** When using RAW drives, my default preference, Veracrypt gives you a warning specifically stating "Warning: If you encrypt the entire device (as opposed to encrypting only a partition on it), operating systems will consider the device as new, empty, and unformatted (as it will contain no partition table)
Interesting warning huh? Someone on a forum told me, based on nothing, I was making multiple partitions and yet according to Veracrypt I haven't even made one; how 'bout that.
Last edit: indnqwiw 2019-03-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, now we're getting somewhere. This looks like a good problem description. So your 2TB encrypted drive contains partitions like /dev/sdb1, /dev/sdb2, etc, even though you encrypted the whole drive? Would you mind to create video or attach screens? Virtualbox has a good video recorder for VMs, or you can apt install vokoscreen recorder to tails.
I do not believe you, because it is technically not possible to distinguish whether there's normal volume, hidden volume, or random data, tails or not. When tails sees random data, it just offers you the possibility to mount veracrypt and from what I tested, my hidden volumes work as they should, but I'd like to be proven wrong. Btw. the veracypt mounter is a new feature of tails, use it with caution, I'd be affraid of security flaws and data corruption. Even truecrypt in "year one" had problem with data corruption.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
hidden volume - encrypted data inside another encrypted data. (main idea)
Note: It is possible to create many hidden volumes inside one nomal :) Its is up to you
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The documentation is very clear regarding hidden volumes should be impossible to be discovered when the volume is dismounted or when mounting only the outer volume.
The principle is that a VeraCrypt volume is created within another VeraCrypt volume (within the free space on the volume). Even when the outer volume is mounted, it should be impossible to prove whether there is a hidden volume within it or not, because free space on any VeraCrypt volume is always filled with random data when the volume is created* and no part of the (dismounted) hidden volume can be distinguished from random data. Note that VeraCrypt does not modify the file system (information about free space, etc.) within the outer volume in any way.
.
* Provided that all the instructions in the VeraCrypt Volume Creation Wizard have been followed and provided that the requirements and precautions listed in the subsection Security Requirements and Precautions Pertaining to Hidden Volumes are followed.
** Provided that the options Quick Format and Dynamic are disabled and provided that the volume does not contain a filesystem that has been encrypted in place (VeraCrypt does not allow the user to create a hidden volume within such a volume). For information on the method used to fill free volume space with random data, see chapter Technical Details, section VeraCrypt Volume Format Specification.
I do not see any exception conditions being met in the following link from indnqwiw tests.
I wonder if this issue you are reporting started when VeraCrypt added the ability to use exFAT filesystem starting with the VeraCrypt 1.17 version.
Would it be possible for you to repeat your tests using NTFS format and FAT?
If the problem does not exist for NTFS and FAT, then something in exFAT implementation needs to be reviewed. This would help the developer Mounir narrow down the issue if it only occurs on exFAT filesystems.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
enigma2illusion - sent you a PM with the associated screenshots. Your guess was spot on it seems, changing from exfat to fat produced the intended behavior of the hidden partition. To clairfy I've only tried exfat outer/inner (miltiple times) and fat outer/inner, no combination of exfat with fat or ntfs. I don't have any SSDs I'm in a position to wipe atm and each of these "tests" takes many hours, as you well know. I leave this possible bug in your capable hands, thanks!
Last edit: indnqwiw 2019-03-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you indnqwiw for testing the FAT format for both outer/inner volumes!
I am not the developer of VeraCrypt. Mounir Idrassi is the developer of VeraCrypt.
Do you get the same results using a small file containers?
If you get the same results when using a small file containers, this would allow you to perform various tests that will take minutes instead of hours to create the different formats.
If small file containers behave the same, this would allow Mounir to attempt to reproduce the issue quickly so he can troubleshoot the issue.
I would be happy to open a ticket and let you add your results to the ticket and this thread.
May I add the details from the PM to the ticket (minus the screenshots)? You can edit your screenshots to remove any sensitive information and attach them to the ticket once I create the ticket.
Many thanks for your willingness to test! Mounir's time to work on VeraCrypt is performed during his free time after his fulltime job, family commitments and other activities.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sounds great, just toss me the link where I should put additonal findings. Ill be able to cross NTFS off the list here in about 10 mintues, then i'll try a container - good suggestion, I hadn't actually considered even trying that =D
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@indnqwiw: thank you for this report and sorry for not giving feedback earlier. Your report came at a time when life was greatly distrupted because of the latest events.
@enigma2illusion: thank you for creating a ticket to follow on this.
I will try to reproduce the issue in order to analyze it because this is a big issue for the usage of hidden volumes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
VeraWipe is a tool to provide plausible deniability to VeraCrypt users.
Without VeraWipe it is very difficult for VeraCrypt users to be taken seriously when they claim their hard drive (which is entirely full of cryptographically random data) is just a wiped drive.
If a tool like VeraWipe exists then the user can claim they used it to wipe their hard drive. As the output of VeraWipe will look identical to VeraCrypt there is an element of doubt provided as defence.
Without VeraWipe there is no realistic plausible deniability which is why I personally consider VeraWipe a priority.
I understand and very much appreciate Mounir is practically working on VeraCrypt alone and free-time is an issue for him.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@infodan36: VeraWipe is a project that I started many years ago but I never published it because I have not had time to finalize it. I will see if I can put online at least an alpha version.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@indnqwiw: I'm unable to reproduce your issue using the same configuration as yours. I tries several disks with different sizes, using exFAT for both outer and hidden, and Tails always sees a RAW disk while displaying that it is possibly encrypted (see screenshot below)
Your posts seem to indicate that it is reproducible at will but I can't see how this can be and I don't see it on my side.
Can you post a screenshot of the partitions displayed by Tails when you insert the affect disk?
RAW disks have no partition table and since the encrypted disk is displayed with partitions then it means that the location that is usually used for partition table contains some data that was successfully partsed by Linux. This means that this RAW disk will be unusable under Tails since it will not be able to mount it correctly (the partition table is for sure wrong).
So my hypothesis is that by chance the random bytes written to the usual location of partition table were somehow valid although they should have depicted wrong partitions sizes.
This makes me believe that this issue can not be reproduced and it has nothing to do with hidden volume presence.
Anyway, if anybody is able to reproduce then I'm willing to reconsider my position (after receiving screenshots of the issue) but until then this is for me a simple case of random bytes being accepted as valid partion table by Linux without any link to hidden volumes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Tried to find info on this but, to my surprise, was unable to. Tails seems to, quite effortlessly, nullify the entire plausible deniability aspect of hidden volumes. A raw drive with a normal Veracrypt volume will show up as a single partition, but the second you introduce a hidden volume, Tails then displays multiple partitions. Verified repeatedly starting with a raw disk.
I mean, isn't distinctly different behavior of normal volumes vs hidden volumes a pretty big hindrance for the whole plausible deniability thing?
Plausible deniability not really that interesting huh? Okay then.
Wrong, RTFM!
With hidden, you have 2 passwords, one decoy for police/airport/iron maiden/whoever might force you to reveal pass, and the other "real" for yourself with data you care about. Mount with decoy, you will see ONLY decoy, mount with real pass and you will see both volumes. That's how it works.
Uh... actually seems like it's you that needs to rtfm there billy. First off, what you replied with has nothing at all to do with what I said. The entire purpose of the hidden volume, is that "whoever" can't say "You have a normal Veracrypt volume and a hidden one, I can see them both right now with my own eyes, give me the passwords for both."
But that's exactly what tails does, without any password entered, without any step taken AT ALL, beyond launching Tails proprietary veracrypt tool, multiple partitions are listed, both the main partition of the drive, and another partition that just happens to be the size of the hidden partition.
Tails behaves differently with a disk that has a normal volume than it does with a disk that has both a normal and a hidden volume, which is basically a big neon sign screaming THERE IS A HIDDEN VOLUME HERE. I'm not sure how much more simply I can explain it.
You have clearly no idea how hidden volume works. Hidden volume is hidden INSIDE an existing one, it is not hiden as "it does not exist at all".
Read how it works and then complain. Just because you're lost doesn't mean your compass is broken ;-) Tails is nothing special, just another linux distro. Actually I use it too with veracrypt and it works as it should.
So if you make many partitions, you will see all of them. If they are full of random data, one can belive there are encrypted data inside, but no one can ever prove there's a hidden volume in either of them, or how many levels of hidden volumes there are.
And even when you unlock with decoy pass, no one can still tell whether you unlocked with "real" password or "decoy" one.
You can also mount with both real and decoy password to fill the decoy with decoy data and veracypt will even protects your hidden data... but it is all explained in veracrypt's manual.
You can say this as many times as you wish, but at the end of the day it's meaningless. I've provided the steps to verify the issue, you arguing like a child is just wasting your time and mine.
I've read how it works, so I now get to complain? Wonderful. Although I do have to say I'm not so much complaining as trying to make people aware of, potentially, a massive issue. Those are usually the types of things people want look into, you know, when their egos aren't so fragile that all they are capable of is dismissing them outright. (See what I did there? That's you).
First, Tails absolutely is something special, and not just another linux distro, specifically because it uses a custom-built tool for interacting with Veracrypt volumes, not a default Veracrypt installation. Neat huh? Isn't information neat? When you open your mind, you'll find it can process, and even store, information--crazy!
And here's the bottom line. Hidden volumes, what's not to get?
Every time I tested this issue, I started with a raw 2TB WD HDD. Raw means no partitions, no file system.
Veracrypt (Windows 10 install): Tools -> Volume Creation Wizard -> Encrypt a non-system partition/drive -> Hidden Veracrypt volume -> Normal mode -> Select RAW HDD -> **** -> Encryption Options Default -> Size, uneditable -> Password -> Large Files - Yes -> ExFAT, default cluster, or 4KB depending on what the drive is for, Quick Format obviously left unchecked. So... How does my failure to understand the concept of hidden partitions have an impact on how the application, using the default settings of the hidden partition creation wizard? Is there a certain way I should be pushing the next button?
Now, if I take the drive that I created using the steps above, and connect it to a PC, boot that PC with Tails, and launch the Tails veracrypt app, I am presented with not one, but multiple "Partitions and Drives" to unlock.
If I take the same exact make and model drive, and using the VeraCrypt Volume Creation Wizard to create a Standard VeraCrypt volume, the veracrypt tool in Tails only lists a single "Partitions and Drives" to unlock.
This has nothing to do with passwords, mounting, or any of that, and you know how you can tell? In my steps to recreate I never said you had to mount anything, or do ANYTHING AT ALL, beyond boot Tails and run the built in veracrypt app. Do you think a third party would be able to do that without your hidden volume password? Stick in a flash drive and click a single icon? I feel like they could, I really do.
I would love for someone to say "You're doing x wrong which is what is causing this" or "This is something we were unaware of" but you are doing nether. All you are doing is yelling "UR WRONG CAUSE ME SAY SO AHHH!" and that's dumb, because it accomplishes nothing. That's how you think you maintain the security of a security application? Someone reports a possible issue and you say "I don't think that's true so therefore it's not true."? Yeah, that's a terrible system.
**** When using RAW drives, my default preference, Veracrypt gives you a warning specifically stating "Warning: If you encrypt the entire device (as opposed to encrypting only a partition on it), operating systems will consider the device as new, empty, and unformatted (as it will contain no partition table)
Interesting warning huh? Someone on a forum told me, based on nothing, I was making multiple partitions and yet according to Veracrypt I haven't even made one; how 'bout that.
Last edit: indnqwiw 2019-03-13
Ok, now we're getting somewhere. This looks like a good problem description. So your 2TB encrypted drive contains partitions like /dev/sdb1, /dev/sdb2, etc, even though you encrypted the whole drive? Would you mind to create video or attach screens? Virtualbox has a good video recorder for VMs, or you can apt install vokoscreen recorder to tails.
I do not believe you, because it is technically not possible to distinguish whether there's normal volume, hidden volume, or random data, tails or not. When tails sees random data, it just offers you the possibility to mount veracrypt and from what I tested, my hidden volumes work as they should, but I'd like to be proven wrong. Btw. the veracypt mounter is a new feature of tails, use it with caution, I'd be affraid of security flaws and data corruption. Even truecrypt in "year one" had problem with data corruption.
Thankfully an adult is here now, so you can move on to mindlessly raging in a different thread.
hidden volume - encrypted data inside another encrypted data. (main idea)
Note: It is possible to create many hidden volumes inside one nomal :) Its is up to you
The documentation is very clear regarding hidden volumes should be impossible to be discovered when the volume is dismounted or when mounting only the outer volume.
https://www.veracrypt.fr/en/Hidden%20Volume.html
.
I do not see any exception conditions being met in the following link from indnqwiw tests.
https://www.veracrypt.fr/en/Security%20Requirements%20for%20Hidden%20Volumes.html
@indnqwiw,
I wonder if this issue you are reporting started when VeraCrypt added the ability to use exFAT filesystem starting with the VeraCrypt 1.17 version.
Would it be possible for you to repeat your tests using NTFS format and FAT?
If the problem does not exist for NTFS and FAT, then something in exFAT implementation needs to be reviewed. This would help the developer Mounir narrow down the issue if it only occurs on exFAT filesystems.
Thanks very much for the response, I deeply appreciate it. Trying again with NTFS and FAT, will update.
enigma2illusion - sent you a PM with the associated screenshots. Your guess was spot on it seems, changing from exfat to fat produced the intended behavior of the hidden partition. To clairfy I've only tried exfat outer/inner (miltiple times) and fat outer/inner, no combination of exfat with fat or ntfs. I don't have any SSDs I'm in a position to wipe atm and each of these "tests" takes many hours, as you well know. I leave this possible bug in your capable hands, thanks!
Last edit: indnqwiw 2019-03-14
Thank you indnqwiw for testing the FAT format for both outer/inner volumes!
I am not the developer of VeraCrypt. Mounir Idrassi is the developer of VeraCrypt.
Do you get the same results using a small file containers?
If you get the same results when using a small file containers, this would allow you to perform various tests that will take minutes instead of hours to create the different formats.
If small file containers behave the same, this would allow Mounir to attempt to reproduce the issue quickly so he can troubleshoot the issue.
I would be happy to open a ticket and let you add your results to the ticket and this thread.
May I add the details from the PM to the ticket (minus the screenshots)? You can edit your screenshots to remove any sensitive information and attach them to the ticket once I create the ticket.
Many thanks for your willingness to test! Mounir's time to work on VeraCrypt is performed during his free time after his fulltime job, family commitments and other activities.
Sounds great, just toss me the link where I should put additonal findings. Ill be able to cross NTFS off the list here in about 10 mintues, then i'll try a container - good suggestion, I hadn't actually considered even trying that =D
Here is the link to the ticket.
https://sourceforge.net/p/veracrypt/tickets/267/
Thank you for performing the additional tests!
@indnqwiw: thank you for this report and sorry for not giving feedback earlier. Your report came at a time when life was greatly distrupted because of the latest events.
@enigma2illusion: thank you for creating a ticket to follow on this.
I will try to reproduce the issue in order to analyze it because this is a big issue for the usage of hidden volumes.
There is little if any plausible deniability without VeraWipe
Thank you for the link, karl leet,
I am very sorry but I did not find anything in the link ?? (aside from A hard disk wipe tool based on VeraCrypt secure engine)
What is verawipe, sounds interesting...?
Where can I find the tool please ?
Hi infodan
VeraWipe is a tool to provide plausible deniability to VeraCrypt users.
Without VeraWipe it is very difficult for VeraCrypt users to be taken seriously when they claim their hard drive (which is entirely full of cryptographically random data) is just a wiped drive.
If a tool like VeraWipe exists then the user can claim they used it to wipe their hard drive. As the output of VeraWipe will look identical to VeraCrypt there is an element of doubt provided as defence.
Without VeraWipe there is no realistic plausible deniability which is why I personally consider VeraWipe a priority.
I understand and very much appreciate Mounir is practically working on VeraCrypt alone and free-time is an issue for him.
@infodan36: VeraWipe is a project that I started many years ago but I never published it because I have not had time to finalize it. I will see if I can put online at least an alpha version.
Mounir
I am very grateful for your work on VeraCrypt and especially now you have taken an interest in VeraWipe again.
If you do release VeraWipe please make an announcement about it so VeraCrypt users see the very real benefit of your work on VeraWipe.
Thank you so much Mounir you are a crypto genius!
@indnqwiw: I'm unable to reproduce your issue using the same configuration as yours. I tries several disks with different sizes, using exFAT for both outer and hidden, and Tails always sees a RAW disk while displaying that it is possibly encrypted (see screenshot below)
Your posts seem to indicate that it is reproducible at will but I can't see how this can be and I don't see it on my side.
Can you post a screenshot of the partitions displayed by Tails when you insert the affect disk?
RAW disks have no partition table and since the encrypted disk is displayed with partitions then it means that the location that is usually used for partition table contains some data that was successfully partsed by Linux. This means that this RAW disk will be unusable under Tails since it will not be able to mount it correctly (the partition table is for sure wrong).
So my hypothesis is that by chance the random bytes written to the usual location of partition table were somehow valid although they should have depicted wrong partitions sizes.
This makes me believe that this issue can not be reproduced and it has nothing to do with hidden volume presence.
Anyway, if anybody is able to reproduce then I'm willing to reconsider my position (after receiving screenshots of the issue) but until then this is for me a simple case of random bytes being accepted as valid partion table by Linux without any link to hidden volumes.