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

>4GB files on outer container under Linux.


When formatting for a hidden partition the user is prompted whether to allow >4GB files on the hidden partition but is not asked for the outer partition. I'd like to have a virtualbox VM folder on an outer partition but it gets truncated.

file attachments


idrassi wrote Nov 15, 2014 at 10:23 PM

During the creating of the outer partition, you have the possibility to select NTFS as the file system in the "Volume Format" window. By default, it is set to FAT in order to save space for the hidden volume but the user can select NTFS if he needs to store files > 4GB.

You certainly didn't pay attention to this option during the creation process.

The drawback of selecting NTFS for the outer volume is that the maximum available size of the hidden volume can be very small. This is explained in the FAQ at the following link:

Do you confirm that you didn't select NTFS for the outer volume?

famewolf wrote Nov 16, 2014 at 3:01 AM

I submit that I'm not the one who needs to pay attention.

I'm using Linux so NTFS would not be available however EXT3/4 would. Attached are screenshots of the install process to a 128mb jumpdrive(whole device install) I just did to confirm once again the user is not given a choice of filesystem for the OUTER container although they are for the INNER container(see crypt14.png).

idrassi wrote Nov 16, 2014 at 11:55 AM

Since there was no indication concerning Linux in the first post, I supposed it was about Windows.
It's not easy to analyze the context of an issue without details about the version and platform used, and I receive so many false issues that consume a lot of time.

I'm sorry if you felt attacked by my comment, it was done because Windows was on my mind and it happens often to users to miss this configuration part of the filesystem of the outer volume. I hope you understand the context of this comment and that it was not a personal attack.

In the future, I'll always ask for detailed information concerning the version, platform and hardware configuration before further analysis. This will avoid any confusion or mix-ups.

Concerning your issue, indeed under Linux it is not possible to choose the filesystem using the GUI because it is always formatted as FAT.
This is done this way because of we need to be able to scan the cluster bitmap of the outer volume in order to determine the maximum allowed size for the hidden volume and we don't know how to do that with filesystems other than FAT on Linux. On Windows, we can also scan the cluster bitmap of NTFS filesystems thanks to specific Windows APIs.

The documentation explains the need for such scan (you can look here). It is almost impossible to manually calculate the correct maximum size of the hidden volume that would ensure that data will not be overwritten.

From here, we have two possibilities:
  1. Implement the manual scan of cluster bitmaps of other filesystems like Ext3/Ext4 or even NTFS. This is not a easy task and we welcome any contribution on this. The method to modify is CoreBase::GetMaxHiddenVolumeSize in src/Core/CoreBase.cpp (link to the code).
  2. Offer the possibility to the user to select any filesystem for the outer volume and let him choose the maximum size of the hidden volume if the selected filesystem is different from FAT. In this, there is a big chance that the value entered will wrong and that data will be overwritten but we can put a warning about this.
The second is the easiest way but the data loss risk exist and even if we put a warning about it, most users will find unacceptable.

Any thoughts on this?

Thank you for bringing up this issue.

famewolf wrote Nov 16, 2014 at 5:27 PM

I assumed all the distro's/architecture's used the same gui but I should have included the info in my original post for clarity.

Well Linux has the ability to r/w ntfs but I'm not sure how stable an implementation it is so one possibility is to allow ntfs as a choice. As far as the size to make the inner container....have you considered creating the outer container to max size, creating the inner container with a user selected value of say up to MAX - 10% (or some such) and THEN populate the outer partition, using the protect option, with files? This has the added possibility of allowing you to support any filesystem the user's platform allows.

I don't know about typical usage but if I want to have a vm on my encrypted partition that is callable from the host pc then I really need to also be able to have a different vm on the outer container that would boot when the outer password is given for plausible deny-ability. If you build the inner partition while the outer is still empty than various utilities like hdparm, df etc can be used to get the "total free" capacity of the device.

I also wondered at the possibility of being able to mount both the inner and the outer container's at the same time....why? Because we need to keep the outer files looking like they are being accessed....if the outer container is mounted and every file shows a time/date stamp of 6 months ago it's also a giveaway for plausible deny-ability. An alternative (and I assume windows has something similar) is to use "touch" to update the date/time stamp on a random percentage of files on the outer container each time the inner container is accessed.

You may already be doing this but I've seen other applications such as virtualbox that can use a command like "vboxmanage filename.vdi compact" to shrink a virtual hard disk image by compressing all the space that has been zero filled...if under your current method you were to zero fill the outer container then populate files would it simplify your task of identifying what space was available? The compact command also only shrinks "contiguous free space" and I assume the source is available since it has an open source version.

idrassi wrote Nov 16, 2014 at 8:23 PM

Thank you for your feedback and these ideas.

The technical aspects of the handling hidden volumes securely are a little complex and it is not possible to have the degree of flexibility that you are suggesting.

A good starting point about understanding hidden volume internals:
Basically, we need a fixed layout for the data of hidden volume and outer volume. The size of the hidden volume you specify must indicate the size from the end of the volume that contains free sector where we can store hidden volume. This layout can't change afterwards.

That's why we need the outer volume to be populate BEFORE the creation of the hidden volume in order to have a safe layout of data. Of course, usually the chosen size of the hidden volume is lower than the maximum allowed size in order to make it possible to write data to the outer volume after the creation of the hidden volume.

We are aware of the NTFS support in Linux. The need is to implement the scan of the cluster bitmap of an NTFS volume and we are not aware of an implementation of this. Certainly, it could be possible to look at the NTFS kernel drive for Linux and see if its implementation can give ideas on how to implement this on our side. As I said, any contribution is welcomed and we would really appreciate any help on implementation such low level feature.

One point that must be kept in mind when trying to reuse the code of the other projects is licensing: basically VeraCrypt inherited the TrueCrypt license and it is as such incompatible with GPL. Most available implementation on Linux are licensed under GPL and because of this we can't just take the source code as it is. Of course, it can be a basis to understand the technical solution by we have to implement everything from scratch.

Concerning the issue of timestamp, I agree that it must be updated. This is something outside the scope of VeraCrypt as we don't interact with the filesystem ourselves. It is the responsibility of the user to handle this.

Unfortunately, it is not easy to implement a secure solution that also offers flexibility. Any new ideas are welcome especially on the low level side in order to come up with new innovative technical solutions.