No way to verify that the published executable does not contain any backdoors?

[sfu82]

Hello,

The vast majority of users, especially on Windows, simply download the VeraCrypt executable available on the site to install it.

And it's all the more likely with VeraCrypt since for Windows, compiling it requires installing a lot of software and following a lot of instructions (personally, after following the guide, which took me more than an hour, I still haven't managed to compile it.) https://veracrypt.fr/en/CompilingGuidelineWin.html

There is a project to make builds reproducible, this means that the compiled software, no matter who compiles it, should produce the same hash, ensuring that it matches the published source code. Projects like Tor already use it. https://reproducible-builds.org/

So I have two questions:

• Is there a way to ensure that the VeraCrypt executable, especially for Windows, does not contain any backdoor? (one could imagine that a government could have forced a person to introduce a backdoor at compile time, or else compromised their device)
• Does VeraCrypt intend to move towards reproducible builds? It requires a bit of work, but I think for such software it is worth it

[idrassi]

There are tools to perform binary diffs and I know that some people are actually using this method to compare official VeraCrypt binaries (specifically VeraCrypt Windows driver veracrypt.sys) with the ones built from source using referenced toolchain. This requires some knowledge about assembly and exprience with diassembly tools but with experience doing such diffs becomes simple. So, buiding binaries from a source code different from the official one will be easily caught and knowing the type of people following this project I doubt that such find will remain secret.

Having a reproducible build is the best way to ensure that anybody can check bijection between source code and binaries. I have looked at this few years ago and I could not find an easy way to do this (I was thinking about publishing build VMs but this is not possible for Windows because of license issues).

I checked the website you share and it is not clear how to proceed in the case of Windows build which uses Microsoft toolchain which cannot be distributed. The idea is that anybody should be able to replicate the build environment to obtain the same binaries. I certainly need more time to learn more about Windows specific approaches (especially for the driver).

Honnestly, I don't have much free time and my todo list is full. reproducible build is important but I need first to fix some long standing issues on VeraCrypt before spending time on this.

Of course, I will be more than happy is someone is able to provide the right approach that VeraCrypt build system should follow to be reproducible. Can anybody help on this?

[wendig0x]

The instructions in the VeraCrypt documentation work and can be used to compile the project.

The checksums will be different because the VeraCrypt files contain a signature, which you do not have.

To check if the binary file and the source code match, do the following:

1. compile the release sources
2. compare compiled files and files from the installation VeraCrypt image

The changes should be minimal, but they will be anyway: do not pay attention to small changes in the header (compile time stamp) and some differences at the junction of sections, because the compiler can slightly optimize and align these areas of the file.

Use programs: IDA Pro + BinDiff or Araxis Merge (binary comparison) or WinHEX

[shalft]

Veracrypt Windows binary executable file is just a GUI version that help user create encrypted partitions and on disk or file container using variety of different algorithms in different combination.

You don't have to use the binary executable program to create the encryption and to or to temporary access the encrypted content or to just decrypt.

If you know he algorithm you used to encrypt, a Linux or CLI version of the veracrypt or the MacOSX version should be able to access and modify the existing encryption on it.

Meaning, yes maybe the backdoor is in the binary, but the encryption itself should still be exactly the same whether you had created the container/partition on Linux, or on MaxOSX or Windows. Of course not all OS version support all the algorithm that you get from using the Windows Binary file, but if you really wanted to, you can just recompile the other OS version with the encryption method you prefer to use.

Plus, for Windows, your security for Veracrypt is as good as your device protection against retrieving the decryption key in RAM. So you make sure your BIOS secure and is solid. You make sure Windows BitLocker is also setup and is active to lock up when it needs to so that there is no access to the OS in any way. Don't use Windows created encryption key for BitLocker, in fact setup Windows to use your own generated encryption key to encrypt your BitLocker and user credentials storage etc..

TBH, these days the Thundebolt 4 port is able to write to an external nvme SSD at 600MB/s to 1000MB/s, so all you gotta do is make sure you have access to a toilet to flush drive or have a a blow torch handy to vaporise it before you open the door for them to come in. ^_^