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

Allow using "blocks range" within storage device to create/mount encrypted volume

Topics: Feature Requests
Dec 3, 2015 at 10:50 AM
The idea is simple: allow using "data coordinates" within storage media (file, disk partition etc) to use for creating/mounting hidden volumes.

Example. I have storage file 10MiB long (1024*1024 = 1048576 bytes). Then hypothetical command would look like

veracrypt -createrange 10240:512000 file.ext -password test -hash sha512 -encryption serpent -filesystem ext4

The above would use existing file file.ext, and creare encrypted volume starting at byte offset 10240 and ending at byte offset 512000 within the file.

This feature could add some more possibility to keep multiple volumes within container media without any trace where they are located.
Dec 22, 2015 at 11:50 AM
Edited Dec 22, 2015 at 2:51 PM
This sound interesting, I had a similar idea :

with veracrypt you can encrypt an empty-partitionless Hard Drive,
by choosing "encrypt a non-system partition/drive"
and then select the Device that doesn't have any partition.
Veracrypt will encrypt the whole drive.

but what if we add an option like an OFFSET
for the beginning of the volume on the drive

The encryption wouldn't start at 0 byte, but somewhere else.
like for example you type in the OFFSET : 1 099 511 627 776 byte
so the volume would start at 1 099 511 627 776.
and only you can know.

of course you would need to encrypt the whole disk first,
and say "I used a secure erase software",
so nobody could find a pattern or a zone on the drive that's different.

So, in the end, the offset would add a layer of deniability

And it doesn't seem "hard" to implement.

what do you think ?
Dec 22, 2015 at 1:01 PM
I guess I dont get the idea, but what happens if you defrag the disk?
Dec 22, 2015 at 2:39 PM
Edited Dec 22, 2015 at 2:49 PM
@Alex512 : sorry for my english, I edited my first post.

just imagine a normal Whole disk Encryption of veracrypt
but with an offset setting. nothing more.

defrag won't do any damage since it will happen only once you mount the volume.
Dec 22, 2015 at 4:48 PM
dodospiegel: OK, but after its mounted and after defrag, then your first sector will be re-positioned and your next login should fail?
Dec 23, 2015 at 3:33 AM
Edited Dec 23, 2015 at 3:57 AM
hmm No.
Let's take a normal veracrypt volume named blabla.tc,
sitting on a normal HDD with a partition, let's name it D

when you mount D:\blabla.tc to E
Windows will show a new partition in the list, E:\
you can defrag E:\, it won't move the first sector of blabla.tc,
it will move what's between the first and last sector.

or maybe I should take the example of a RAW partition encryption,
when partition 1 is 500GB and Partition 2 is 1500GB
you encrypt partition 2,
you mount it as E:\
you defrag it, that doesn't mean the first sector of partition 2 is being moved,
but everything inside partition 2 is.

just like when you defrag a normal disk, it doesn't move the MBR

So in our case, with a offset, the first sector stay at position 1 099 511 627 776
what's defragmenting is inside the first and last sector of this "hidden" part of the disk.
Dec 23, 2015 at 8:20 PM
Hehe:) lets see....

in your first example.... if (when) you defrag D:..... u r busted .... i think....
Dec 24, 2015 at 2:07 AM
"busted" ?
why do you say that ?
yes, in the first example, we can defrag the partition where's located the blabla.tc file that is a veracrypt volume,
so if we defrag D:\ , all files moves, but is doesn't changes the bytes of blabla.tc
and the volume still can be mounted, nothing unusual here. I do that all the time. the header doesn't change byte, it changed location.
so nothing is busted even if the volume has been moved.

but in the case of a partitionless drive, there's nothing to defrag.
so nothing will move. so the hidden partition with the offset doesn't change location.

but don't confuse veracrypt file that is location on a partition and hidden partition that is located on a partitionless drive.

I think you're confused with multiple things...

...and I don't think I'm wrong about my feature :P

maybe I should make a drawing
Dec 24, 2015 at 9:02 AM
@Alex512 In most cases, Veracrypt volume is either within file (container), or within entire partition.

If offset is taken within every media, optimizing disk won't destroy the "offset-hidden" volume (since file will only me moved in its entirety).

if it's on partition - I suppose no one does optimize "empty" partition, so the offset-hidden volume won't be damaged.

@dodospiegel Thanks for supporting the feature request!
Dec 24, 2015 at 9:37 AM
@dodospiegel & quainta : ok, you might be right, but still, suppose you are right about the defragmentation issue..... what enhancement of the security model does that provide? In my opinion - none! You have to remember the offset(starting) point and pass it together with your password at login right? Well, this offset number you have to remember, if you just add it at the end of your password (without offsetting) then it will equal the same possible combinations in terms of bruteforce resistance. The PIM is a bit different, because the iterations slow down the hashing process, while in your case it really makes no difference - so why just make VC more complicated without achieving anything?

p.s. One could always invent some more "security enhancements"..... for instance.... when doing the iterations, one could instruct the software to hash with a different hash algorithm, say the 256789th round thereby changing completely the end hash output. So lets say instead of iterating 500000 times SHA1, you can iterate 256789 times SHA1 then 1 round SHA2 and then the remaining rounds again with SHA1. Bearing in mind that you have to remember this number (256789), do you think this is a real security enhancement (this is not a rhetorical question)?
Dec 24, 2015 at 3:35 PM
Edited Dec 24, 2015 at 3:40 PM
What this add is better plausible deniability.
the security part is taken care by your password/pim/keyfile/algorithm, I'm not talking about security.


Right now with Veracrypt or Truecrypt, plausible deniability is achieved with hidden volume with a volume/partition.
So an adversary could easy say "what's the second password I know you have one"

In the case of offsetting, you could make plenty of hidden partition in the partitionless drive :

Q1- Adversary ask you what's this empty Hard Drive :
  • You say : I did a secure erase of this drive using a random write process; not using currently
Q2- We have detected (somehow) that you where using veracrypt, give us the password of both outer and hidden volume
  • You give them the 2 password of a decoy outer and hidden volume. and the offset if you did use the option.
  • The real outer/hidden volume would be at another offset.
  • or the real could be in a third or fourth or more outer/hidden volume that are at any other offset.
nobody could know how many hidden volume there is : Enhanced Plausible Deniability

You could even put the decoy volume to overlap the real volume. but that's risky for the data.


again, not talking about security or attack. just plausible deniability.
Dec 24, 2015 at 4:36 PM
dodospiegel, you are somehow then replicating my earlier suggestion: https://veracrypt.codeplex.com/discussions/646758
although by a bit different approach?
Dec 24, 2015 at 4:48 PM
Edited Dec 24, 2015 at 4:49 PM
Yep, I already read your thread before posting here ;)
I just added a way (or another way) to do it, with empty drive.
I hope they feature one of your, quainta's or my idea.
Jan 23, 2016 at 6:04 AM
@Alex512 In all honesty, I don't see any flaws in additional feature I mentioned.

Those unwilling to use it, simply do not use it (the default values would mean use entire span of the media holding the encrypted volume).

The issue of disk defragmenting doesn't seem a problem. Encrypted volume is either a file (in which case it will be moved entirely, so no problem to use the offset within file to mount it) or partition/entire raw device (in which case it is not subject to defragmentation)

Other benefits have been already mentioned above (if media hiding the volume is large enough, it will add significant efforts to guessing where the actual data are.

Since this feature is advanced, "common" VeraCrypt users will not use it, that simple.
Jan 25, 2016 at 6:42 PM
@quainta, i agree with you :)

However.... from a mathematical point of view, it does NOT provide any additional security if we bear in mind that you have to remember the offset position. If you want me i will explain why?
Jan 25, 2016 at 11:14 PM
@Alex512 Let me do the math for you.

Assume we have 10Gb (gibibyte) container file holding 1Gb VeraCrypt volume (let's make adversary's life simpler and assume they already know the volume's size and PIM value which, in real life, would not be so).

The above trivial example makes it obvious that adversary will have to check up to 9,663,676,416 more combinations to find the actual volume and access data.

Now please repeat again about additional security. Let me also tell you that we do not talk about average person who cannot even create strong enough password, let alone remember non-standard PIM counter and, possibly, additional offset:length pair.

If person is concerned about security, remembering two additional numbers doesn't make their life much harder.

Conclusion. The proposal is easy to implement and it 8does* bring much more security and options for plausible deniability. I suppose there will be interested parties to fork the VeraCrypt and implement the feature, if original developer(s) are not interested. No problem with that.
Jan 26, 2016 at 11:39 AM
@quainta,

i couldnt really figure out where did you take this number (9,663,676,416) from, bytes, bits, sectors?... but thats not important.... i assume it is correct.... but in order for you to decrypt your own volume, you will have to memorize and enter the offset number (upto 9,663,676,416)..... so in the current version of VC, if you just append your offset number at the end of your password, then bruteforcing it will require exactly 9,663,676,416 more combinations to complete :)
Jan 26, 2016 at 2:43 PM
@ALex512 That number is just the number of bytes in 9Gb. That simple.
if you just append your offset number at the end of your password
Have you read the OP? I haven't said about appending the offset:length to password. They are passed as separate command-line parameter.
bruteforcing it will require exactly 9,663,676,416 more combinations to complete :)
Wrong, read above why. The offset:length is a separate parameter. So you don't add that number, you multiple time required to bruteforce (in the worst possible case) by that number. Feel the difference.

As I said, the proposal has been stated and I assume someone can use it on a fork or similar piece of software.

Thanks for your time.
Jan 27, 2016 at 7:31 AM
@quainta,

I didnt say the offset number value is to be appended to the password. I am just saying that as you have to memorize the offset number and enter it somewhere, you will achieve the same enhancement in terms of bruteforce if you just add that number at the end (or start or wherever) of your current password with the current version of VC.

Mathematically (unfortunately), there is no way to add N bits of "entropy" to your initial input (be it password, pim number, offset position number, etc.) and achieve even N+1 required operations for the bruteforce attack on your system, unless you use artificial iterations (or other similar operations such as the PIM iterations in VC), that will slow down the mounting process.

As to plausible deniability however, your suggested method can be eventually indeed used in a very smart way...
Jan 27, 2016 at 8:52 AM
@Alex512

Looks like you totally misunderstand the idea. The idea is to locate, within container (file or raw device), of size M, encrypted volume of size N (N < M).

That gives (M - N) possibilities to locate actual position of encrypted data. Other encryption parameters known, it would require up to (M - N) times as much time to decrypt the volume.

This is about hiding the actual volume location and thus nullifying bruteforcing attempts if location is guessed incorrectly. If you only know PIM and password, you will have to try up to (M - N) times before you actually find and decrypt it.

I hope this time you understand the idea.
Jan 27, 2016 at 9:25 AM
quainta wrote:
@Alex512

Looks like you totally misunderstand the idea. The idea is to locate, within container (file or raw device), of size M, encrypted volume of size N (N < M).
correct
That gives (M - N) possibilities to locate actual position of encrypted data. Other encryption parameters known, it would require up to (M - N) times as much time to decrypt the volume.
i would say it would require up to M possibilities to locate the start of the file (equals to M times more combinations to bruteforce)
This is about hiding the actual volume location and thus nullifying bruteforcing attempts if location is guessed incorrectly. If you only know PIM and password, you will have to try up to (M - N) times before you actually find and decrypt it.
Yes, but if one tries to bruteforce it, he will try all M possible locations of the start of the hidden file, thereby multiplying the possible possibilities by M. Add M to your password and you get the same :)
Jan 28, 2016 at 1:36 AM
@Alex512 Adding the counter (from 1 to M-N) to the password only gives the same raise in attempts amount. That's the only similarity.

Note that if the actual encrypted volume location is not known within the container media, adversary would efficiently waste their time trying to bruteforce the junk data. As far as I know, the only way to make sure this is encrypted volume is to try to decipher it the regular way. If password and/or PIM are unknown, that can make adversary's task much more time-consuming.

So, now only to wait and see whether anyone is interested to implement it.

Implementation notes: if adversary can keep track of container media changes, it would also be reasonable to overwrite with high entropy random generator other parts of the media (containing no information), to make it harder to guess where actual data are located.