Version 3.1.0

v77 — Thu, 16 Apr 2026 14:07:14 -0000

This release brings a lot of work on the performances.

The AVX executable is replaced by an AVX2 one. AVX2 allows a great speedup with Serpent and SHACAL-2: instead of encrypting 4 blocks at once, 8 blocks are now encrypted. The speedup is mitigated by XTS and the multithreading though.
Keeping an AVX1 executable makes no sense because the speedup was very limited (there was no dedicated implementation of the algorithms) and CPUs with AVX1 but no AVX2 are now rather rare. Moreover, other optimizations now make the SSE3 executable faster than the AVX1 one.

As always, unlike some other encryption softwares, the integrated benchmark (-bm) shows the true speeds of the ciphers, that is, with the XTS mode of operation which requires some computations.

Decrypt drive encrypted by other program

v77 — Mon, 29 Dec 2025 11:42:55 -0000

Each encryption software has its own protocols. ProxyCrypt can only decrypt the volumes it has created.
Of course, some softwares can decrypt data from other softwares, but it must be explicitly specified. But this type of compatibility is not very common, especially for disk encryption, because it's difficult to implement while keeping performance and reliability.

Decrypt drive encrypted by other program

Christo — Mon, 29 Dec 2025 10:56:40 -0000

Hi, I'm trying to transition from the dead project FreeOTFE to one still developped, but I'm encountering a problem when I'm trying to decrypt my encrypted drive with ProxyCrypt.
ProxyCrypt seems to recognize the encrypted drive, but when I'm entering the same password that I enter in FreeOTFE, it gives an error.
So I'm wondering whether ProxyCrypt can decrypt this drive?
Here's the output:

C:\ProxyCryptGUI2025\exe>ProxyCrypt.exe -d 2, -p 0 -v 2
AES instructions detected.
Uses 8 threads for encryption/decryption.
Sector size: 512.
Total size: 2 000 398 934 016 bytes.
2 000 398 934 016 bytes used from offset 0.
 ? Read: 8192 bytes at offset 0

Enter password:
**************
Checking password... Error. Please retry.

I'm not sure with which options the drive was encrypted, in FreeOTFE I see these settings for the drive:
Cipher: AES, Mode: XTS, Keysize: 256, blockhain: 128, Sector IV: null
And when encrypting a new file, these settings are used by default (which I assume I used):
Hash: SHA-512, Cypher: AES (256bits XTS), Sector IVs: null

Possibly it's the Hash causing a problem?
Though I tested with a volumefile created by FreeOTFE and Whirlpool hash, but here the same problem.

Scrypt PRF

RichardH — Wed, 05 Nov 2025 19:47:25 -0000

That is extremely helpful, thanks!

Changing big->little endian (both data and keys) makes the two match. 👍

Scrypt PRF

v77 — Wed, 05 Nov 2025 11:15:58 -0000

I speak of SHACAL-2 in my presentation of ProxyCrypt 2.0 here.
Not really a variant, but data are loaded in little endian format for each 32-bit word. This is very likely the cause of the difference.

By the way, I forgot that I had an archive of SHACAL-2 before my SSE2 optimization. Don't know if it can be helpful for you.

Scrypt PRF

RichardH — Tue, 04 Nov 2025 23:17:14 -0000

The XTS with 256-bit blocks stuff is definitely interesting, looking at that now.

Having some difficulty aligning SHACAL-2 output, for example, looking at your test.c

unsigned char k1[64] = {0x00, 0x00, 0x00, 0x80};
unsigned char pt1[32 * 4] = {};
[...]
printf("expected: 32B61A36A7E7A92F8D8123BBBD019E8373F4FDDADD6E4205B9ED7A29AE2B20F6\n");

the input matches a known test vector from https://github.com/weidai11/cryptopp/blob/60f81a77e0c9a0e7ffc1ca1bc438ddfa2e43b78e/TestVectors/shacal2.txt#L4

Comment: Set 1, vector 24
Key: 00000080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Plaintext: 0000000000000000000000000000000000000000000000000000000000000000
Ciphertext: 7AC85AA2C5A9A219B8E437C65913738628EE442F56BD57292C8A1B36026B6664

and that is the output my implementation is giving too.

Assuming your 4-blocks-in-one-call should give the same output for the first block, any idea why the two differ? Are you using a variant of SHACAL-2?

Scrypt PRF

RichardH — Mon, 03 Nov 2025 10:13:35 -0000

Yeah, I already extended my scrypt to support other prf's.

I focused on version 2 indeed, good to know that v1 is not worth the trouble, thanks. If you ever create v3, it might make sense to align the two 64bit counters on 8-byte boundary to make it easier to read these values cross-platform.

My initial release will support AES/Whirlpool only. Other options follow shortly in updates after that.

Proof-of-concept is working nicely, here's a screenshot taken on Windows and iPhone simulator.

Scrypt PRF

v77 — Mon, 03 Nov 2025 09:49:57 -0000

Interesting. As said, the most uncommon part is XTS with 256-bit blocks.
If you already have all the required algorithms, this scrypt implementation should be easy to handle.
For the volume header, I don't know what you have in mind but I would suggest to ignore the version 1 (HEADER_STRUCT_v1). I created ProxyCrypt 12 years ago, but the version 2 is 9 years old, so supporting the version 1 seems rather meaningless.

Scrypt PRF

RichardH — Sun, 02 Nov 2025 22:47:27 -0000

Just a FYI, as you might be interested to know that I decided to add ProxyCrypt support, which will allow accessing the contents of a disk image on iOS and macOS.

Scrypt PRF

RichardH — Fri, 31 Oct 2025 13:24:13 -0000

While I fully agree that it is technically possible to use a different hash function (or use a completely different PRF instead of HMAC for that matter), the specs for scrypt are pretty clear on HMAC-SHA256 being required, like in the RFC the algorithm starts with

> 1. Initialize an array B consisting of p blocks of 128 * r octets

   each:
    B[0] || B[1] || ... || B[p - 1] =
      PBKDF2-HMAC-SHA256 (P, S, 1, p * 128 * r)

Similary, the original paper defines a MFcrypt (which matches your usage), and then defines scrypt as a special case using HMAC-SHA256.

Anyway, it wasn't my intention to start arguing this, I was just curious why you chose a different hash function, was there a specific reason not to use SHA256?

The reason I'm interested is because I could add support for ProxyCrypt to my app Disk Decipher, which would allow accessing ProxyCrypt images on iOS/macOS platform. Most of the crypto stuff is already in there to support other formats like VeraCrypt and LUKS, just not non-standard scrypt 😀

I saw the improved XTS implementation, need some more time analyzing that. SSE2 is not available on Apple platform, but that's easy to workaround.

Recent posts to Discussion

Version 3.1.0

Decrypt drive encrypted by other program

Decrypt drive encrypted by other program

Scrypt PRF

Scrypt PRF

Scrypt PRF

Scrypt PRF

Scrypt PRF

Scrypt PRF

Scrypt PRF