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

Embed the PIM into the volume header so it doesn't need to be typed in

Topics: Feature Requests
Jun 18, 2015 at 11:55 PM
The Iteration Count (or a multiplier of) should be stored in the clear inside the volume header.
The IC can be hidden (stenography) inside a randomly generated number in such a way that it is impossible to tell the number apart from a true random number:
init_genrand64(time(0));

uint32_t G = 1001; // Some upper limit on the PIM
uint32_t M = 90;  // User requested PIM (valid range: 1 - G)

loopi(20) // Loop 20 times for example
{
    uint32_t R = genrand64_int64();
    uint32_t B = R - ((R % G) - M); // Hide the PIM inside a random number
    printf("B = %08X :: B mod %d = %d\n", B, G, B % G);
}
Example output:

B = B4A22E66 :: B mod 1001 = 90
B = EB22E2F1 :: B mod 1001 = 90
B = 234C8A5D :: B mod 1001 = 90
B = E8C5359B :: B mod 1001 = 90
B = 26C71806 :: B mod 1001 = 90
B = 7BFDF27C :: B mod 1001 = 90
B = 382AD658 :: B mod 1001 = 90
B = F2FA89B3 :: B mod 1001 = 90
B = A457ADC9 :: B mod 1001 = 90
B = 8BFDCE2A :: B mod 1001 = 90
B = 2FFD9AFB :: B mod 1001 = 90
B = D9242C2D :: B mod 1001 = 90
B = 538B036D :: B mod 1001 = 90
B = 2F28A795 :: B mod 1001 = 90
B = 344A601F :: B mod 1001 = 90
B = CD89CC45 :: B mod 1001 = 90
B = 5E9FC160 :: B mod 1001 = 90
B = 6D7108DC :: B mod 1001 = 90
B = E683E957 :: B mod 1001 = 90
B = 22AA6BF7 :: B mod 1001 = 90

This will allow anyone using any software to mount the drive only needing to know the Password (or keyfiles). The Iteration Count can be selected at creation time and then forgotten by everyone needing to use the volume.
Jun 29, 2015 at 7:07 AM
I wholeheartedly agree with Brett. This way, it's possible to allow for a RANDOM iteration count the user doesn't even know. It's very difficult to remember the iteration count for every container you make. The result would be that you need to choose a single count for each container or write down each iteration count.
Coordinator
Jun 29, 2015 at 10:25 AM
Hi,

There are no plans to move away from the requirement of having no clear data in the volume header, even if it is obfuscated as in your proposal.
Moreover, your proposal can't be called steganography since VeraCrypt is open source and anyone will know the computation method and the location of the bytes encoding the iterations. Developing a statistical distinguisher for such encoding is easy, so it is like writing the data in clear in the header.

As for the PIM, it is better if the attacker doesn't know its value but even if it is known it doesn't reduce the security provided that a keyfile or a strong password are used. Thus, a user can use the same PIM value for all containers, reducing the need for memorizing different values.
Jul 28, 2015 at 11:18 PM
Moreover, your proposal can't be called steganography since VeraCrypt is open source and anyone will know the computation method and the location of the bytes encoding the iterations. Developing a statistical distinguisher for such encoding is easy, so it is like writing the data in clear in the header.
Prove it!

There is no statistical analysis that can differentiate a random number from other equally random numbers, and even though the source code is public, knowing the modular divider does not help any. Proof:

Which of these below 32-bit random numbers are my personal PIM and which are not. The source code specifies the modular divisor will be 50, and that the result will be incremented by 1 then multiplied by 10,000. Thus the smallest resulting iteration count is 10,000 and the largest is 500,000:

28C05EFA = 17k iterations
A799982C = 37k iterations
95484256 = 9k iterations
5F6FCBCA = 37k iterations
FEA57415 = 22k iterations
49CBB98C = 27k iterations
050098D6 = 7k iterations
07167EED = 48k iterations
9D5973CA = 9k iterations
1B5A1BDB = 4k iterations

So tell me which of the above 10 numbers found in the plaintext "header" of the volume are my selected PIM's and which one's are just random data found on a random drive?

It's impossible. A person could realistically choose 10k iterations, as many as 500k, and any number in between, thus knowing the source code and knowing where the data is stored is useless. No one can prove the difference between a randomly generated file and a VC volume using this location. It's just random. System Volumes already contain megabytes worth of unencrypted data and are easily detected as VC volumes, so storing the PIM in plain-text provides no security risk at all in that case.
Jul 29, 2015 at 4:46 PM
Hello Brett,

My interpretation of Mounir's reply that you quoted is that since the source code is public, the location for the iteration count will always be a hex value for a number instead of random data which should be either numeric and non-numeric character representations.

Hence, systems with multiple encrypted drives and/or partitions will all have this specific location for the iteration count as representing a number which impacts plausible deniability.

Kind Regards.
Jul 29, 2015 at 5:44 PM
Edited Jul 29, 2015 at 5:46 PM
Enigma2Illusion wrote:
Hello Brett,

My interpretation of Mounir's reply that you quoted is that since the source code is public, the location for the iteration count will always be a hex value for a number instead of random data which should be either numeric and non-numeric character representations.

Hence, systems with multiple encrypted drives and/or partitions will all have this specific location for the iteration count as representing a number which impacts plausible deniability.

Kind Regards.
You're completely missing my point. It does not matter if the location is the same, it does not matter if there are multiple volumes, it does not matter if the source-code is public. Because we're using stenography to hide/mask/seed the value stored at the fixed location it will appear as random data to anyone who looks at it even if they have the source code, have the offset, and know the modular divisor.

Plausible deniability is still equally as strong in all cases.

Finally, system volume encryption has no plausable deniability since there is the bootloader. So embedding the PIM into the already-plaintext header would not be a cause for concern to anyone.
Jul 29, 2015 at 5:59 PM
Enigma2Illusion wrote:
Hello Brett,

My interpretation of Mounir's reply that you quoted is that since the source code is public, the location for the iteration count will always be a hex value for a number instead of random data which should be either numeric and non-numeric character representations.

Hence, systems with multiple encrypted drives and/or partitions will all have this specific location for the iteration count as representing a number which impacts plausible deniability.

Kind Regards.
Actually, that's not true. Even if you have multiple encrypted drives, the iteration count can be random (within a specified range). So, none of the drives are likely to have the same iteration count.
Jul 29, 2015 at 6:07 PM
SHBouwhuis wrote:
Actually, that's not true. Even if you have multiple encrypted drives, the iteration count can be random (within a specified range). So, none of the drives are likely to have the same iteration count.
.
My point is that the location for the iteration count values are always numeric which is not true random characters.
Jul 29, 2015 at 6:27 PM
Enigma2Illusion wrote:
SHBouwhuis wrote:
Actually, that's not true. Even if you have multiple encrypted drives, the iteration count can be random (within a specified range). So, none of the drives are likely to have the same iteration count.
.
My point is that the location for the iteration count values are always numeric which is not true random characters.
my point is that the location being numeric has nothing to do with this conversation and no one said the location should be random.

Please go back and read what I've written until you understand it.
Jul 29, 2015 at 6:59 PM
**brett_ wrote:**
Enigma2Illusion wrote:
SHBouwhuis wrote:
Actually, that's not true. Even if you have multiple encrypted drives, the iteration count can be random (within a specified range). So, none of the drives are likely to have the same iteration count.
.
My point is that the location for the iteration count values are always numeric which is not true random characters.
my point is that the location being numeric has nothing to do with this conversation and no one said the location should be random.

Please go back and read what I've written until you understand it.
.
I never suggested that the location should be random. I am not sure why you jumped to that conclusion.

Mounir has already pointed out that your approach is not stenography. I am not trying to defend Mounir's statement. I am providing my opinion that your approach removes plausible deniability since not everyone uses VeraCrypt solely for system encryption.
Jul 29, 2015 at 7:28 PM
Enigma2Illusion wrote:
**brett_ wrote:**
Enigma2Illusion wrote:
SHBouwhuis wrote:
Actually, that's not true. Even if you have multiple encrypted drives, the iteration count can be random (within a specified range). So, none of the drives are likely to have the same iteration count.
.
My point is that the location for the iteration count values are always numeric which is not true random characters.
my point is that the location being numeric has nothing to do with this conversation and no one said the location should be random.

Please go back and read what I've written until you understand it.
.
I never suggested that the location should be random. I am not sure why you jumped to that conclusion.

Mounir has already pointed out that your approach is not stenography. I am not trying to defend Mounir's statement. I am providing my opinion that your approach removes plausible deniability since not everyone uses VeraCrypt solely for system encryption.
He was wrong to say it is not stenography, it is. Your opinion that it removes plausible deniability is also wrong, which is why I'd appreciate it if you just left this discussion alone. You are not attempting to understand what we are talking about and you are just confusing everyone else.
Jul 31, 2015 at 2:09 AM
The code is open source. You can fork it if you want. Mounir has made a reasonable decision not to accept your suggestion.
Jul 31, 2015 at 6:33 PM
commenter8 wrote:
The code is open source. You can fork it if you want. Mounir has made a reasonable decision not to accept your suggestion.
... one step ahead of you my friend.
Aug 1, 2015 at 11:49 AM
Hey Brett,

Can you share you changes with us/me if you manage to compile things correctly?
Aug 1, 2015 at 7:28 PM
SHBouwhuis wrote:
Hey Brett,

Can you share you changes with us/me if you manage to compile things correctly?
Of course. The only problem I think I'll run into is I'll need to buy a certificate in order to sign the new binaries so Windows will allow them to be installed. But as for compiling things etc, I've been programming ASM/C for 18+ years so that wont be an issue at all lol.
Aug 2, 2015 at 12:10 AM
brett_ , I researched a bit the available offerings of code-signing certs, and it appears that for open source projects Certum is the cheapest - 14 Euro per year.
http://certum.eu/certum/cert,offer_code_signing.xml
I have no experience dealing with that company though.
Aug 2, 2015 at 6:05 AM
It's possible to turn off the need for driver signing in x64 Windows (x86 Windows doesn't need signed drivers).

Turn OFF signed drivers:
bcdedit.exe -set loadoptions DDISABLE_INTEGRITY_CHECKS
bcdedit.exe -set TESTSIGNING ON

Turn ON signed drivers:
bcdedit.exe -set loadoptions ENABLE_INTEGRITY_CHECKS
bcdedit.exe -set TESTSIGNING OFF

Of course, it's better to keep this on out of security view point, but when push comes to shove this is possible.
Aug 2, 2015 at 8:53 PM
SHBouwhuis wrote:
It's possible to turn off the need for driver signing in x64 Windows (x86 Windows doesn't need signed drivers).

Turn OFF signed drivers:
bcdedit.exe -set loadoptions DDISABLE_INTEGRITY_CHECKS
bcdedit.exe -set TESTSIGNING ON

Turn ON signed drivers:
bcdedit.exe -set loadoptions ENABLE_INTEGRITY_CHECKS
bcdedit.exe -set TESTSIGNING OFF

Of course, it's better to keep this on out of security view point, but when push comes to shove this is possible.
Thanks. I was aware Windows allowed for unsigned drivers (it makes developing & testing them easier) but for an end-user that isn't really a good choice. ninveh's method may work out best.
Aug 27, 2015 at 1:27 PM
Would it not be preferable if the few people with coding skills good enough for such a project stuck their heads together and made a joint effort instead of fragmenting into uncounted variants?
Sep 8, 2015 at 4:14 PM
In the meantime... Is it possible to mask PIM with ** like password is masked/hidden? I do not understand why PIM has not been hidden/masked in the first place - anyone sitting next to me can see it while I type it in during boot time (not so easy for password masked with ***********). Thanks.
Sep 8, 2015 at 5:08 PM
Edited Sep 8, 2015 at 5:47 PM
The 1.14 beta masks or displays the PIM.

https://veracrypt.codeplex.com/wikipage?title=Release%20Notes
.
Mask and unmask PIM value in GUI and bootloader like the password.
.
You can download 1.14 beta from the link below.

http://sourceforge.net/projects/veracrypt/files/VeraCrypt%20Nightly%20Builds/