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

Quick expanding

Topics: Feature Requests
Jan 20, 2016 at 8:54 AM
Unless I am missing something:
  1. When I create VeraCrypt volume I have two options: quick formatting (does not write random data) or slow formatting (writes random data).
  2. However, expander only has slow expanding option (write random data).
What about adding quick expanding option (without writing random data)?
Feb 5, 2016 at 6:15 AM
I have a number of questions about this whole concept.

When creating a new volume, why is it necessary to fill it with random data? The documentation says "Quick format [bypassing the time-consuming step of filling the new volume with random data] is much faster but may be less secure because until the whole volume has been filled with files, it may be possible to tell how much data it contains (if the space was not filled with random data beforehand."

So what? Is that the only security issue? Who cares how much encrypted data I have? My only concern is that other people can't see the data itself.

"Note that Quick Format can only be enabled when encrypting partitions/devices."

Why does the Quick Format option only apply to partitions and drives, but not file containers? (I'm only interested in creating a file container, which apparently takes the Quick Formatting option off the table and makes the question of whether I should use that option moot. :-/ )
Feb 5, 2016 at 3:06 PM
Edited Feb 5, 2016 at 9:29 PM
The disk space that was not written with random data may contain old data which can be retrieved via recovery tools.

The creation of the file container is different due to VeraCrypt needs to create the file to the size specified without error. The create file container can encounter bad disk blocks and fail. Hence the quick format is not an option. At least, that is my guess as to why file containers do not have quick format option.

The reason the amount of data written or change to volume can be a security concern to some people is if some surveillance has determined that you download a 1 GB file and that happens to match the new/change data in the volume gives the agency high probability of your actions. This may not be a concern for you.
Mar 11, 2016 at 4:13 AM
Thanks, Enigma.
  1. That's true of ANY disk space on the hard drive, whether inside or outside the container. It has nothing to do with VeraCrypt. Any user who is concerned about the security of old data on his hard drive should wipe it, using one of the many file shredding applications out there (e.g., Recuva or CCleaner).
  2. That's an interesting idea. But I thought the BIOS or the hard drive's own internal controller or something already took care of removing bad blocks from service. (And wouldn't any bad blocks or sectors on the hard drive ALSO be an issue when encrypting a partition, as opposed to a file container?)
  3. You're right -- that's not a concern for me. :-) (But thanks for the explanation.)
Anybody else (idrassi?) have any ideas why, when creating a container, you have to wait while VC writes random data to the entire container? (I don't think Boxcryptor, for example, requires its users to do that.)
Mar 11, 2016 at 7:49 AM
Edited Mar 11, 2016 at 7:59 AM
ReverendBlueJeans wrote:
That's true of ANY disk space on the hard drive, whether inside or outside the container. It has nothing to do with VeraCrypt. Any user who is concerned about the security of old data on his hard drive should wipe it, using one of the many file shredding applications out there (e.g., Recuva or CCleaner).
.
Some applications can create temporary files that contain your sensitive data. Hence, it is not a good idea to use quick format for disk/partition encryption.
.
ReverendBlueJeans wrote:
That's an interesting idea. But I thought the BIOS or the hard drive's own internal controller or something already took care of removing bad blocks from service. (And wouldn't any bad blocks or sectors on the hard drive ALSO be an issue when encrypting a partition, as opposed to a file container?)
.
Here is an article that explains in depth how drives get bad blocks and the different types of bad blocks.

http://www.howtogeek.com/173463/bad-sectors-explained-why-hard-drives-get-bad-sectors-and-what-you-can-do-about-it/

Remember, I said I was guessing as to the reason for file containers lacking the quick format option. :-)
.
ReverendBlueJeans wrote:
I don't think Boxcryptor, for example, requires its users to do that.
.
BoxCryptor is a Windows-based solution for file-by-file encryption to sync with Cloud storage and does not use containers.

https://www.boxcryptor.com/en/boxcryptor

Mounir, can you provide an explanation why quick format option cannot be used for file containers?
Mar 12, 2016 at 12:55 AM
Edited Mar 12, 2016 at 1:10 AM
...And a simple (as possible while maintaining accuracy) explanation for laypersons of how VeraCrypt works? The Introduction provides an excellent start, but a little more basic info would be even better. Like a brief explanation of why the file container has to be filled with random data, what a master key is, what header keys are and what they do and how they work, what a header key derivation function is, etc. A full-blown detailed exposition isn’t necessary – or desired -- just a basic explanation in plain English for us laypeople who are not encryption experts but are nevertheless interested in knowing the basics of how VC works. :-)

(I know some of this stuff is covered in the sections “Header Key Derivation, Salt, and Iteration Count” and “Encryption Scheme”, but it’s a bit lengthy and technical for us “normal” people. [grin])

(Oh, as for my reference to Boxcryptor....yes, it’s a file-by-file encryption system as opposed to a container-based one like TrueCrypt/VeraCrypt, but I used that as an example because some of the functionality seems similar, like the idea of encryption on the fly by dragging and dropping a plaintext file into an encrypted folder.)
Mar 26, 2016 at 1:15 PM
Its generally advised to create an encrypted volume over cryptographically sound random data to hide information about a volume.

Example,you start with a container file that takes up 100 sectors and each of of them have zeros in them.

Somebody examining this container file and sees all zeros will confidently know that the container is not is use.

Create a VeraCrypt volume and the first sector will now be in use and anybody who examines the container can see this.Since all remaining sectors
will still have zeros in them,an examiner will know that the encrypted volume has nothing in it.

Now,lets say the examiner now sees that sector 67 is also in use.If file system XYZ is known to create its file system management stuff on sector 67,the
examiner can now reasonably deduce that the VeraCrypt volume uses file system XYZ and the file system has never been used since no other sector is used.

The above shows how an encrypted volume that is created over predictable data can leak information about the contents of the encrypted volume.
Mar 26, 2016 at 1:25 PM
Edited Mar 26, 2016 at 1:26 PM
When creating a LUKS volume with cryptsetup, I usually create it, open it so it is mapped and then write /dev/zero across the entire volume; that will write the crypted version of /dev/zero for each location along the way. Then once that is finished, I use the drive normally knowing that unless the volume is fully unlocked, there is no way to tell what is and what is not in use as the entire volume is random data. But if the volume is unlocked, then discovery can be made by the "leak information", but I'm sure much more could be discovered anyway in the unlocked state.

I've created 3TB VC volumes and it took hours and hours to write to the volume before I could do anything else with it; I would think that this would be similar to writing /dev/random to the entire volume.
Mar 26, 2016 at 2:12 PM
The function that writes cryto strong random data to devices in zuluCrypt is here[1].

Line 574 creates a plain dm-crypt encryption mapper using a 64 bytes random password read from "/dev/urandom" and then 1KB at a time( line 605 ) data is written to the mapper device leading to crypto strong random data on the plain device. In my tests,your way and mine are faster than alternatives(no idea how VeraCrypt does it).

[1] https://github.com/mhogomchungu/zuluCrypt/blob/1669f6093c4835a3b29d21e41c6b81724a0dcd6a/zuluCrypt-gui/utility.cpp#L566