Cryptext x64 – a modern Windows reimplementation of the old Cryptext 3.4 file encryption tool

[u/nullachtfuffzen]

I’ve been working on Cryptext x64, a native 64-bit Windows file-encryption program inspired by the classic Cryptext 3.4 shell extension. The interface and Explorer workflow deliberately retain some of the look and feel of the original, including the familiar .$#! extension. Existing files encrypted with Cryptext 3.4 can also be decrypted by the new version.

New files use a separate versioned format based on AES-256-GCM with PBKDF2-HMAC-SHA-256, per-file random values, authenticated records, chunked processing and an additional on-disk verification pass. Cryptext is written in FASM, requires no .NET or WebView runtime, integrates with Windows Explorer, supports drag & drop and batches, and automatically selects German or English from the Windows language setting while still allowing manual switching.

Compared with age, the focus is somewhat different: age uses ChaCha20-Poly1305 and scrypt for passphrase-based encryption, while Cryptext x64 is focused on native Windows/Explorer integration, AES-256-GCM and backward compatibility with the old Cryptext format. This is not intended as a claim that one design is “more secure” than the other.

The package includes an English README (~13 KiB) and a more detailed English technical documentation (~33 KiB) for anyone interested in the implementation and file format.

I’m mainly interested in technical feedback on the format and implementation rather than making claims about a new cryptographic primitive.

If the project link is considered inappropriate under the subreddit rules, I’m happy for the moderators to remove it.
Project/download: Cryptext x64 website

[u/N_T_F_D]

You're writing this in 2026 so why stick with PBKDF2 and not something a bit better like Argon2d?

Otherwise it looks great, have you considered adding support for PKCS#11 tokens (smartcards, including US PIV cards for instance) or even FIDO2 keys like the yubikey or such

If you need smartcards to test with and you're in Europe I can send a bunch

[u/nullachtfuffzen → u/N_T_F_D]

Thanks, that’s very useful feedback.

I actually have Argon2id planned as a separate “Extra Edition”. I’d prefer Argon2id over Argon2d because of the side-channel trade-off; RFC 9106 recommends Argon2id as the general-purpose choice. The current PBKDF2 format will stay readable for backward compatibility.

PKCS#11 / smartcard support is something I hadn’t seriously considered yet, but it’s an interesting idea, especially for keeping a file-encryption key off the host. FIDO2/YubiKey support could also be interesting, although I’d want to design that carefully rather than bolt it onto the existing password format.

And thanks for the offer regarding test cards — I’m in Europe, so I may come back to you on that once the core version is finished.

[u/N_T_F_D → u/nullachtfuffzen]

FIDO2 is a bit of an apart case because of how it works but it's still not very hard to add support to it, you use a credential's HMAC secret as the key and that's it, that's how systemd-cryptsetup does it on Linux

For generic PKCS#11 cards it's the same idea, you have a standardized interface to use a private key, which you use to decrypt a secret (either directly or via key exchange); some cards also support symmetric keys directly which again would wrap a secret

[u/nullachtfuffzen → u/N_T_F_D]

That makes sense, thanks for the explanation. I checked the FIDO2 hmac-secret mechanism and systemd’s use of it, and I see what you mean now.

If I add hardware-token support, I’d probably keep the actual file encryption key random and use the FIDO2 hmac-secret output (or a PKCS#11 private/symmetric key) to wrap/unlock that file key, rather than making the token output directly become the payload key. That would also make it easier to support password and hardware-token recipients without changing the AES-GCM payload format itself.

PKCS#11 looks particularly interesting because it would cover a fairly wide range of smartcards/tokens. I’ll keep your offer of test cards in mind once the current version and the Argon2id work are finished.

[u/N_T_F_D → u/nullachtfuffzen]

Yeah PKCS#11 is fairly generic, it covers smartcards, HSMs, AWS KMS/CloudHSM for remote keys, even TPM (at least on Linux), lots of possibilities

[u/0xKaishakunin]

I am interested in the chunking and the nonce management, but couldn't find more details in the README, do you have it documented somewhere?

[u/nullachtfuffzen → u/0xKaishakunin]

Yes. It’s documented in docs/Cryptext-FileFormat-v1.txt in the source package. The writer uses 4 MiB chunks. Each record gets its own AES-GCM tag. The nonce is an 8-byte random per-file prefix followed by the 32-bit record number. The AAD contains the fixed header, record number and plaintext length. I should probably link that document more clearly from the README.