1.26.27 BETA Released 2025/9/20

[Enigma2Illusion]

Version 1.26 and newer VeraCrypt versions have deprecated the following features:

• TrueCrypt Mode
• HMAC-RIPEMD-160 Hash Algorithm
• GOST89 Encryption Algorithm

.
See the documentation below for remediation procedures.

Conversion Guide for VeraCrypt 1.26 and Later

---

Update on bumping minimum Windows version requirements for VeraCrypt

---

https://sourceforge.net/projects/veracrypt/files/VeraCrypt%20Nightly%20Builds/

Changes in 1.26.27 (September 20, 2025):

All OSes:

* Updated logo icons to simplified versions without extra label text.
* Updated documentation.
* Updated translations.

Windows:

* Fix rare BSOD (Blue Screen of Death) issue affecting VeraCrypt driver.
* Enhancements to the driver crash dump filter (GH PR #1590).
* Enhancement to I/O request handling in the driver.
* Added support for the Argon2id password hashing algorithm.
* Speedup mounting when PRF autodetection is selected.
* Introduced `/protectScreen` CLI switch to allow disabling screen protection in portable mode. (See documentation)
* Enhanced `/protectMemory` CLI switch with argument to allow disabling memory protection in portable mode. (See documentation)
* Add setting and CLI switch /enableIME to allow enabling Input Method Editor (IME) in Secure Desktop
* Released VeraCrypt C/C++ SDK for volume creation: [https://github.com/veracrypt/VeraCrypt-SDK](https://github.com/veracrypt/VeraCrypt-SDK)

Linux:

* Updated Ubuntu 25.04 dependency to require `libwxgtk3.2-1t64` package.
* Allowed AppImage file names to start with "veracrypt" regardless of case.
* Fixed initial width of columns in the main UI.

macOS:

* Fixed initial width of columns in the main UI.

[风之暇想]

There are two issues that have not been fixed.
https://sourceforge.net/p/veracrypt/discussion/features/thread/adb29bdd88/#ca37
https://sourceforge.net/p/veracrypt/discussion/technical/thread/5326026904/#e1a6/0af1/97d9

[Mounir IDRASSI]

@fzxx: thank you for the remainder.

Concerning the first issue: I will study it more closely. I agree that HKDF is a modern and stronger way to derive independant key. I will provide a reply after study.

Concerning the second issue: this is not an issue! if the password is wrong, VeraCrypt must try all KDF algorithms because it doesn't know the correct one (remember, there are no metadata in VeraCrypt volumes). So the time taken by trying a wrong password will be the time required for the slowest KDF to return its result (if we suppose that you have enough CPU cores to run all KDFs in parallel) plus a small overhead related to threads orchestration.

[风之暇想]

Parallel decryption should be able to increase the speed (once a thread successfully decrypts, the other threads are terminated immediately). Currently, does it seem to be decrypting in the order of algorithms?

[Mounir IDRASSI]

@fzxx: autodetection speed has been fixed already. once correct password is validated by correct KDF, other KDFs are aborted. This has been validated by myself and others on this forum.
you original issue was about wrong password taking 10 seconds instead of 2 for normal passpwrd: this is normal as I explained in previous reply since no KDF is able to decrypt the header.

[风之暇想]

For an incorrect password, parallel decryption should also take 2-5 seconds, because each algorithm almost always returns an error in around 2 seconds.

[Mounir IDRASSI]

@fzxx: in case of wrong password, VeraCrypt subsequently tries to open the hidden volume with this password. That's why you see double the time: once for normal header and when it fails it tries hidden volume header.

This is part of VeraCrypt plausible deniability approach: automatically trying normal volume followed by hidden volume.

So the case of wrong password will always be slowed no matter what we do.

[风之暇想]

With the correct password, loading the normal encrypted volume takes 2 seconds, and loading the hidden encrypted volume takes 5 seconds. It seems that this slowness occurs because the normal volume and the hidden volume are not decrypted in parallel together. Currently, the system first performs parallel decryption on the normal volume, and only after the normal volume decryption fails does it proceed to parallel decryption of the hidden volume—this sequential process leads to the delay.
It is suggested that the normal volume and the hidden volume be decrypted in parallel together. This approach will not cause the failure of plausible deniability, since the same password cannot be set for both volumes.

[Enigma2Illusion]

@idrassi

The online documentation link is broken for:

https://veracrypt.jp/en/PBKDF2.html

located under the

https://veracrypt.jp/en/Key%20Derivation%20Algorithms.html

[Mounir IDRASSI]

@enigma2illusion: thank you for spotting this. I have fixed the issue. The correct filename is pbkdf2.html in lowercase.

[风之暇想]

It seems that the document has not been synchronized to Chinese and Russian.

[Activist4219]

@idrassi sorry to intrude, but do you have any estimate for when VeraCrypt will support full-disk encryption for ARM64 devices? I’ve had a Surface Pro since the beginning of the year and would really like to go back to using VeraCrypt.

[Mounir IDRASSI]

@activist4219: unfortunately, I don't have access anymore to an ARM64 device. I'm now resorting to cloud based ARM64 VM to do testing.
Working on system encryption requires physical access to ARM64 machine and I cannot afford to buy one for VeraCrypt development.
So for now, I can do nothing on this front. If one day I get access, I will resume working on it.

[Sr Lopez]

Thank you Sir for your hard work! Much Appreciated

[Christian Welzel]

Good morning,
I’m new to this forum, and maybe I’m asking a question that has already been asked and answered elsewhere.
Since I installed “Tahoe” on macOS, I haven’t been able to access it anymore.
Will this be possible again with the new update?

[Mounir IDRASSI]

@cwelzel: can you clarify what issue do you have with VeraCrypt on macOS Tahoe? Any error message? I personally installed and tested VeraCrypt 1.26.24 on macOS Tahoe (mac Mini M1) using both macFUSE and FUSE-T and I didn't encounter any issue.

[Christian Welzel]

I got the follow message:
Unsupported macOS Version
The installed version of macFUSE is too old for the operating system. Please upgrade your macFUSE installation to one that is compatible with the currently running version of macOS.

I´m using a MacMini M4.

[Mounir IDRASSI]

@cwelzel: You should install latest macFUSE version 5.0.6 (https://macfuse.github.io/). This is what I used for my Tahoe mac Mini.

[Christian Welzel]

Thank you very much! It work´s.

[Kurt Fitzner]

For Argon2id, it shows up in the list of features for Windows but is conspicuously absent from Linux. Does this mean that Linux can no longer open a volume so created?

If this is the case, then it needs to be noted in rather large print. Linux is a common recovery platform, and if it can no longer open a Windows container/drive/system-drive that uses argon2id, then people will need to know that before they make the switch.

[Kurt Fitzner]

Just tried out the beta. Following bugs still exist:
1) Preboot-authentication overwrites password with a single * to obfuscate the length, but it does not replace the PIM with a single * - this is a very long standing bug, having existed since the beginning of EFI.
2) Booting from the rescue disk does not read DcsProp from the rescue disk - it reads from the system drive's EFI folder.

I also note that EFI bootloader is byte-for-byte identical with previous version. I take it then that Argon2id is not supported for system encryption? This makes it less of an issue not having Linux support for rescue purposes.

What does PIM mean for Argon2id? Just iteration count? Will there be any control of memory or parallelism?

[Alex R]

Hi Mounir I just wanted to mention I've been using the new argon2 KDF and it has been working great, including using a custom PIM. I'm on Windows 11 and the container is 500GB with AES(Twofish(Serpent)).

[memiker tmper]

Suggested update to add function: When the computer is turned on, the system partition password or PIM is entered without relying on the computer keyboard input?

Suggested update to add function: When the computer is turned on, the system partition password or PIM is entered without relying on the computer keyboard input?

It is estimated that some computer motherboards come with a keyboard recorder at the factory, so even the most complex passwords lose their meaning. It can be designed like this:

Method 1: Every time the system partition password is entered after the computer is turned on, a random mapping table is displayed on the screen (each mapping is different): 0 as 4, 1 as 8, 2 as 3, 3 as 0, 4 as 6, 5 as 7, 6 as 1, d as p, e as b, etc. For example, my real password is 123456de, enter: 830671pb, unlock OK!

For the hint of the mapping table, you can check 3 options: letters, numbers, special symbols. The style of the hint of the mapping table can be matched with the XML file, so that you can modify the style yourself, and it is not so easy to see that it is the password hint of Veracrypt.

Method 2: Randomly arranged letters and numbers are displayed on the screen, and you can use the mouse to click instead of keyboard key input. Disadvantages: Not as good as method 1, mouse driver compatibility issues need to be considered

Or: move the cross using keyboard arrow keys (no case the driver of the mouse).

this issue at: https://github.com/veracrypt/VeraCrypt/issues/1557

[Alex R]

I'm just curious if the Linux build will be receiving the argon2 support soon? Windows has been my primary OS for years but I'm in the process of moving to Linux so just curious on timeline. Thanks!

[John R]

Thank you for this new version. I also hope for Argon2 support for Linux.