Version 2.0.0 (beta)
- replaced the Twofish cipher by SHACAL-2 (Twofish no longer available)
- added the ability to use a key file, in conjunction or replacement of password
- added tuning of the scrypt key derivation function for better performances or security
- volumes can now be created with random content
- added new faster executables for CPU with AVX instructions
ProxyCrypt 2.0 is here, as a beta version.
As explained previously, SHACAL-2 now replaces Twofish. So, if you didn't use Twofish, you will be able to directly use previously created volumes.
Header backups need to be recreated.
This is all the inconveniences brought by this version.
Syntax is fully compatible.
The fact that SHACAL-2 works with 512-bit keys and 256-bit data blocks has several implications on the code of ProxyCrypt.
A new version of the volume header has been created in order to contain the bigger keys, and that's why a backup of the header now requires 576 bytes instead of 512. But thanks to a version number included in the volume header, the old headers are still supported.
The bigger data blocks have an implication on XTS, because this mode of operation works with the same block size than the one of the used cipher. But the reference code is only for 256-bit block ciphers. So, I asked a question here
and got an answer.
Unfortunately, it seems that I am the first one to use XTS with a 256-bit block cipher... Therefore there is no test vector. But I have checked the binary values that I am supposed to get for various cases, and they seems to be correct.
This implementation of SHACAL-2 is derived from the one of Crypto++
but is now optimized with SSE2 instructions. The trick is the same that the one used for Serpent: 4 blocks are encrypted at a time. This is possible because just like Serpent, SHACAL-2 works mostly with 32-bit registers.
Depending on the hardware, the speed of SHACAL-2 should be between 20 and 50% higher than Serpent.
For better performances, the data loaded and written by this implementation of SHACAL-2 is done in little-endian format. Therefore, test vectors used in the test program has been modified to reverse byte order of each 32-bit word. Of course, this does not change the computations done by the algorithm and so its cryptographic strength.
Some claim that in cryptography, we should use big-endian by default. But others claim that we should just use the fastest way to load data. So, as ProxyCrypt is not written for being compatible with other system or hardware, and as this improves the speed by several MB/s, I chose the fastest method.
For performance reasons, the key files are limited to 4KB. Extra data are ignored.
While TrueCrypt uses a hash of the key file that is then merged with the password, ProxyCrypt concatenates the file itself with the password, before submitting the whole thing to the key derivation function. I think this way is more secure, but the downside is a slowdown for large amounts of data.
Scrypt can now be tuned if you want that your password is recognized faster, or if you want more security. Check the syntax help for details.
The memory allocated by scrypt is about 'mem' * 8 Mo
(on machines with 1 core/1 thread, this is halved).
Keep in mind that if you forget your parameters, the password will not be recognized!
Up to now, ProxyCrypt relies on the format command to fill the empty space of a new volume. As the volume is filled with always the same data (0), we may think that it could introduce a cryptographic weakness, because in this case, the difference between all the encrypted blocks comes only from XTS which, moreover, is not recommended for very large amounts of data.
This issue is mitigated by the fact that as soon as the volume is used, an attacker cannot know for sure which blocks are filled with something else than 0.
So, if you have still a doubt or want to use a large and empty encrypted volume, ProxyCrypt can now fill new volumes with random data.
The method used to generate large amounts of random data at high speed relies on a 1MB block filled with random data, encrypted on itself with the cipher selected by the user, and with keys changed each time with mouse position and time stamp counter of the processor. This way, even if a key is found, this would be useless for the attacker because this would just be a temporary key used to encrypt random data. And thanks to the key change, a block cannot be deduced from the previous one.
New executables have been added, for using AVX instructions when available.
Using AVX requires the support of both the hardware and the operating system. Windows 7 SP1 or later is required. An error message can be displayed depending on the situation.
Edited by v77, 07 July 2016 - 04:24 PM.