Jump to content

- - - - -


arsenal image mounter imdisk proxy encryption volume

  • This topic is locked This topic is locked
104 replies to this topic

#101 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15703 posts
  • Location:The Outside of the Asylum (gate is closed)

Posted 14 March 2016 - 07:18 PM

Inside hiberfil.sys? Well, it would require several things:
- To access this file, which is possible only with a direct access to the C: volume for locating and copying this file, or by copying the whole C: volume elsewhere, mounting this volume and then accessing hiberfil.sys. Anyhow, this requires administrative privileges.
- To know how Windows writes its data into hiberfil.sys, or find a way to locate the data of ProxyCrypt.
As I never tried this kind of thing, I cannot say more than that.

An example of a practical use of hiberfil.sys to do this kind of attack? I have never read that someone would have tried, so I can only say that it's possible.

Well since you actually started it :w00t: :ph34r:, this:


is just a couple hops from googling "hiberfil.sys analize" going through:





#102 v77


    Silver Member

  • Team Reboot
  • 592 posts

Posted 22 March 2016 - 02:31 PM

Argon2 has recently been provided in version 1.3. The change log says:
• The blocks are XORed with, not overwritten in the second pass and later;
• The version number byte is now 0x13.

It seems to be an answer to an attack for which the hash can be computed with 2.71 less memory and no time penalty (even if the "no time penalty" sounds like a bad joke when we think of the complexity added by the management of the unused memory blocks...).

Now, the best: produced hashes are different. Test vectors have been rebuilt, test program has been rewritten. We have a completely new algorithm, validated by nobody.
If you were using the 1.2.1 version for checking passwords, updating to 1.3 will make all the passwords unrecognized.
And accessorily, I just lost several weeks of my free time.

So I think I will wait some years, that they stop to play with their algorithm. It's good to see that issues are fixed, but for an encryption tool, I need something more stable.
Depending on the source, we have 2 different changelogs for the same version:
Version 1.3 of Argon2
Version number in encoded hash
Refactored low-level API
Visibility control for library symbols
Microsft Visual Studio solution
New bindings
Minor bug and warning fixes (no security issue)
C.1 v.1.3
• The blocks are XORed with, not overwritten in the second pass and later;
• The version number byte is now 0x13.
And by searching "Argon2" on Google, the first link (CryptoLUX) claims:
"Argon2 (version 1.3) is the winner of the Password Hashing Competition."
A pure lie. The winner of the PHC was the version 1.2.1. Despite its important design issue, it was selected as the winner. This point is definitely the more suspect in this competition.

There is really nothing I can trust in all that. So I doubt to use Argon2, whichever the version, even in a long time.

Edited by v77, 06 June 2016 - 02:04 PM.

#103 v77


    Silver Member

  • Team Reboot
  • 592 posts

Posted 23 April 2016 - 03:16 PM

As I said before my message disappears because of a restoration of the website, I am now able to put SHACAL-2 in place of Twofish.
Twofish brings nothing in comparaison to AES or Serpent. Serpent is more secure (and faster on most machines thanks to SSE2), and AES is accelerated by hardware on many machines.
SHACAL-2 works with 512-bit keys and 256-bit blocks, and it has an original structure derived from a hash function (SHA-256). It is one of the finalists of the NESSIE project, which means that it was chosen by another organization than NIST and in another political context.
Twofish will be removed in order to keep a small code size. But of course, this means that any user who uses Twofish will not be able to mount his volume with ProxyCrypt 2.0. So I wonder if there is a lot of users who are using Twofish (of course, this would also mean that there is a lot of people who are using ProxyCrypt...).

#104 v77


    Silver Member

  • Team Reboot
  • 592 posts

Posted 10 June 2016 - 11:34 PM

In order to create a new volume initialized with random data, I just benchmarked the famous CryptGenRandom function. The function fills a 1MB buffer and is called several times. It works on one thread, on a Core i7 2600k @3800. Here are my results, for various systems running in virtual machines:
10 (64-bit) : 2160 MB/s
10 (32-bit) : 1550 MB/s
8.1 (64-bit) : 404 MB/s
8.1 (32-bit) : 392 MB/s
8 (64-bit) : 405 MB/s
8 (32-bit) : 394 MB/s
7 SP1 (64-bit) : 265 MB/s
7 SP1 (32-bit) : 163 MB/s
Vista (64-bit) : 37 MB/s
Vista (32-bit) : 30 MB/s
XP64 SP2 (64-bit) : 38 MB/s
XP64 SP2 (32-bit) : 33 MB/s
XP SP3 : 30 MB/s
XP : 24 MB/s


As we can see, newer is better. :jaclaz:


But for very old systems, CryptGenRandom might be not suited to this situation. So I will have to find something else.

#105 v77


    Silver Member

  • Team Reboot
  • 592 posts

Posted 18 June 2016 - 10:50 AM

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.

Also tagged with one or more of these keywords: arsenal image mounter, imdisk, proxy, encryption, volume

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users