Over the last months I've been working on what will eventually become DiskCryptor 2.0, and I wanted to share some of the larger changes currently under development and gather feedback before the release.

The biggest addition is undoubtedly TPM support. The goal is to allow volumes to be protected using hardware-backed secrets while still preserving DiskCryptor's traditional flexibility. TPM-backed unlocking will be available through the EFI boot components and can be combined with other authentication methods depending on the deployment scenario.

Another major area of work is a completely new Volume Header format. One of the long-standing limitations of the current format is that a volume can only be associated with a single set of credentials. The new design introduces key slots, allowing multiple independent passwords and keyfiles to unlock the same volume. This enables recovery passwords, multiple users, staged credential migration, and many other workflows that were previously difficult or impossible to implement cleanly.

To improve password-based security, the new format also introduces support for Argon2id. While strong passwords remain the best defense, Argon2id significantly increases the cost of brute-force attacks by requiring substantial memory in addition to CPU resources. This provides much stronger protection against modern GPU-accelerated cracking attacks than the legacy approaches used by many older disk encryption products.

Keyfiles are also receiving a substantial overhaul. The current implementation works, but there is considerable room for improvement. DiskCryptor 2.0 introduces a new mechanism for combining key material from multiple sources and adds support for Virtual Keyfiles, making it easier to use secrets stored in password managers or other external tools without having to manage physical key files on disk.

Reliability and recoverability have also been a major focus. One noteworthy addition is an optional header backup stored at the end of the partition, providing a built-in recovery mechanism in case the primary header becomes damaged or corrupted.

Beyond the security-related changes, there is a long list of improvements throughout the project:

• SSD-aware encryption and decryption that can skip unused sectors.

• Optional protection against accidental writes to RAW volumes.

• Faster boot-time mounting by avoiding redundant key derivation operations.

• Better support for touch-screen devices in the EFI boot environment.

• Improvements to in-place volume encryption.

• Numerous fixes for volume resizing, relocation handling, 4K-sector disks, race conditions, deadlocks, and general stability issues.

• Various UI improvements and quality-of-life features.

While there is still work left before DiskCryptor 2.0 is ready for release, the core architecture is taking shape and many of the major features are already implemented.

I'd be interested in hearing what existing DiskCryptor users think about these changes. In particular:

• Are there any TPM-related workflows you would like to see supported?

• Do you have use cases for multiple passwords or recovery credentials on the same volume?

• Are there shortcomings in the current keyfile system that you would like addressed?

• Are there other long-standing DiskCryptor limitations that should be tackled as part of the 2.0 cycle?

As always, feedback is welcome and may help shape the final release.