In the UI part, I choose simplest approach: Argon2 is added to the list of hashes. Technically it is not a hash and so in the begining I wanted to created a combobox that has {PBKDF2, Argon2) and based on the selection the list of hashes will be displayed or not. But it was complicated and not user friendly. That's why I opted for the easy solution.
Of course, I'm open to proposals for better UX/UI.
On the code part, I used the official Argon2 source code and I modified it for VeraCrypt needs. One notable change is related to the AVX2 optimization: it was proposed in C using AVX2 intrinsic but Windows driver cannot use AVX2 intrinsic!
So, I have to come with an assembly version of the AVX2 code to be able to use it in VeraCrypt driver. The approach I used to write this assembly file is document in the comment at https://sourceforge.net/p/veracrypt/code/ci/master/tree/src/Crypto/Argon2/src/opt_avx2.asm
Feedback is welcomed.
π
2
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I attached a suggestion for the UI. Correct me if I'm wrong but we are talking about two things now;
1. The hash algorithms which are used for the main encryption key(s) (as the pseudorandom mixing function for the random number generator). This is only done once when creating a volume.
2. The header key derivation from the password. Until argon2 these were always the same (ie if I choose SHA-512, then SHA-512 would be used for both). Of course this is done every time the user mounts the volume.
It's not clear to me then if I choose argon2, which hash algorithm will be used for the main encryption keys? I think the two options should be separated, with some text explaining the difference and/or linking to the relevant documentation page.
@captain150: I understand the confusion. Actually, VeraCrypt doesn't use hash algorithms directly. VeraCrypt uses what we call a PRF (Pseudo Random Function) to derive the header key that is necessary for decrypting the master key.
Until now, we had PRF instances based on PBKDF2-HMAC where HMAC may use one if the supported hash algorithms.
With the introduction of Argon2, we have a new PRF type: Argon2id.
In VeraCrypt UI, we made the shortcut PRF <=> Hash but now this is not the case.
So, normally, we should replace Hash by PRF in the format wizard like in the mount dialog and replace hash algorithm named by HMAC-XXX. I will implement this.
Concerning the random generator, in case of Argon2, BLAKE2s is used: this is because Argon2 is based on BLAKE2b and so it makes sense to use existing BLAKE2s. Ideally, we should use BLAKE2b for RNG but for now its API is not exposed to VeraCrypt. I will change this.
Thank you for your constructive feedback. I hope I clarified your points.
π
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1, I like to use the portable version, but can not disable the screenshot protection
2, when mounting, the default first press SHA-512 decryption, Argon2id has not been put behind SHA-512 in order to speed up the decryption time (my computer takes 7 seconds to mount the volume of Argon2id)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Version 1.26.25 adds the CLI switch "/protectScreen no" to VeraCrypt.exe to disable screen protection in portable mode. Did you use it? it should work.
Indeed, Argon2 should have higher priority. After some time, it will become the default. I will change the order to put after SHA-512 for automatic detection.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1, the test has successfully turned off the protection, it is recommended that you do not need to use the command, in the setup UI and save it to the configuration file
2, looking forward to setting Argon2id as the default value
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@fzxx:
Indeed, the Portable setup doesn't allow to choose configuration of memory protection and screen protection. It is a good idea to make Portable setup create an adequate configuration file. For now, memory and screen protection are not part of user configuration because they are managed at admin level. I will try to come up with a good solution for better user experience.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2025-06-26
@idrassi
Argon2id should not be the default as it should be an option for more experienced users
For new users, Argon2id may be problematic
But I could be wrong
Last edit: Anonymous 2025-06-26
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1, set the default SHA512 or Argon2id, mount volume only need 2 seconds
2, set the automatic detection, no matter which algorithm the volume needs 6-7 seconds, which is a serious problem, because set the default detection should also be prioritized SHA512, it should be mounted in 2 seconds, but it did not achieve the effect.
3, it is recommended to use multi-threaded, no need to set the default algorithm, automatic detection of any algorithm can be mounted in 2 seconds. @idrassi
@fzxx: there is already a logic in VeraCrypt drive to use multi-threading for automatic detection and then stop as soon as the correct PRF is found. But the current implementation waits until all PRFs in current thread pool finish before continuing...this is because we cannot just ignore exiting threads or abort them, we have to wait until they finish properly to avoid data corruption.
That being said, it is technically possible to have a better implementation to avoid this, it is just a matter of complexity. I need to come up with a new idea that doesn't require too much work.
We dispatch key derivation work using EncryptionThreadPoolBeginKeyDerivation and at the end we call EncryptionThreadPoolBeginReadVolumeHeaderFinalization to wait for all work items to finish in order to free memory and release resources.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@tulip-81: for now, system encryption doesn't support Argon2. But it is planned for EFI bootloader so it is coming. For MBR, it is unfortunately impossible to implement because of the constraints of the 16-bit boot environment.
π
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@fzxx: I have used OpenAI o3 and Google Gemini Pro 2.5 to see what they can propose. They both agreed that the only solution is to add cancellation logic inside the cryptographic primitives for various PRFs in order to be able to abort operations as soon as possible.
This is something I never thought about because it breaks separations between layers, and it introduces dependency between low level cryptographic components and high-level business logic.
Despite being ugly, I implemented it and it makes autodetection as fast as the correct PRF. The drawback is that the individual PRFs become a little slower because we need to check a flag periodically. But the loss of performance should not be noticeable by users.
Anyway, I have uploaded version 1.26.26 which contains this change to Nightly Builds folder.
can you please give it a try and share your feedback?
Thank you.
Trivia: Gemini Pro 2.5 has tendency to write a lot of code which ends up not being useful because of quantity of bugs. o3 is more into planning with only hints without much code, which is better.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1, you need to keep prompting the AI to achieve a certain function with the least amount of code and changes, and manually fine-tune the code according to the AI (copying some of the code)
2, v1.26.26 mount volume is already around 2.5 seconds, great
3, optimize all the code using the AI more often, so that the SSDs can reach the maximum speed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@idrassi Newly discovered an issue where entering the correct password only takes 2 seconds to successfully mount, and the wrong password gets stuck for 10 seconds before prompting an error.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Does the automatic detection changes also improve the favorites mount duration speed of multiple volumes at the same time?
Currently on older versions of VeraCrypt, the favorites mount of multiple volumes at the same time has slower mount times after the first favorite volume mounts.
EDIT:
I am unable to test the VeraCrypt beta software at this time due to I waiting on a software patch from third party vendor. I do not like to make other software changes at the same time so I know if their patch causes other issues, I know which software is the culprit.
Last edit: Enigma2Illusion 2025-06-30
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Version 1.26.26 works great on my Win11 x64, 24H2. It takes only a fraction (perhaps not even a second) longer than using SHA-512. Version 1.26.25 took about 7 secs.
Last edit: David 2025-06-30
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have pushed changes to add support for Argon2 in VeraCrypt on Windows and the test binaries for version 1.26.25 that includes it are available under https://sourceforge.net/projects/veracrypt/files/VeraCrypt%20Nightly%20Builds/Windows/
The current implementation brings the following:
In the UI part, I choose simplest approach: Argon2 is added to the list of hashes. Technically it is not a hash and so in the begining I wanted to created a combobox that has {PBKDF2, Argon2) and based on the selection the list of hashes will be displayed or not. But it was complicated and not user friendly. That's why I opted for the easy solution.
Of course, I'm open to proposals for better UX/UI.
On the code part, I used the official Argon2 source code and I modified it for VeraCrypt needs. One notable change is related to the AVX2 optimization: it was proposed in C using AVX2 intrinsic but Windows driver cannot use AVX2 intrinsic!
So, I have to come with an assembly version of the AVX2 code to be able to use it in VeraCrypt driver. The approach I used to write this assembly file is document in the comment at https://sourceforge.net/p/veracrypt/code/ci/master/tree/src/Crypto/Argon2/src/opt_avx2.asm
Feedback is welcomed.
I attached a suggestion for the UI. Correct me if I'm wrong but we are talking about two things now;
1. The hash algorithms which are used for the main encryption key(s) (as the pseudorandom mixing function for the random number generator). This is only done once when creating a volume.
2. The header key derivation from the password. Until argon2 these were always the same (ie if I choose SHA-512, then SHA-512 would be used for both). Of course this is done every time the user mounts the volume.
It's not clear to me then if I choose argon2, which hash algorithm will be used for the main encryption keys? I think the two options should be separated, with some text explaining the difference and/or linking to the relevant documentation page.
@captain150: I understand the confusion. Actually, VeraCrypt doesn't use hash algorithms directly. VeraCrypt uses what we call a PRF (Pseudo Random Function) to derive the header key that is necessary for decrypting the master key.
VeraCrypt documentation mention the use of PRF : https://veracrypt.jp/en/Encryption%20Scheme.html
Until now, we had PRF instances based on PBKDF2-HMAC where HMAC may use one if the supported hash algorithms.
With the introduction of Argon2, we have a new PRF type: Argon2id.
In VeraCrypt UI, we made the shortcut PRF <=> Hash but now this is not the case.
So, normally, we should replace Hash by PRF in the format wizard like in the mount dialog and replace hash algorithm named by HMAC-XXX. I will implement this.
Concerning the random generator, in case of Argon2, BLAKE2s is used: this is because Argon2 is based on BLAKE2b and so it makes sense to use existing BLAKE2s. Ideally, we should use BLAKE2b for RNG but for now its API is not exposed to VeraCrypt. I will change this.
Thank you for your constructive feedback. I hope I clarified your points.
Why not use BLANES3, which was officially released in 2020 and has more advantages?
Last edit: Kostja 2025-07-01
@ksp1
The question has been previously asked and answered by the developer at the link below.
https://sourceforge.net/p/veracrypt/discussion/general/thread/0cc5a5acc6/?limit=25#ad01/a220
Who created BLAKE2s in assembler, look at the link https://github.com/jkmnt/blake2s_arm_m3_asm
1, I like to use the portable version, but can not disable the screenshot protection
2, when mounting, the default first press SHA-512 decryption, Argon2id has not been put behind SHA-512 in order to speed up the decryption time (my computer takes 7 seconds to mount the volume of Argon2id)
1, the test has successfully turned off the protection, it is recommended that you do not need to use the command, in the setup UI and save it to the configuration file
2, looking forward to setting Argon2id as the default value
@fzxx:
Indeed, the Portable setup doesn't allow to choose configuration of memory protection and screen protection. It is a good idea to make Portable setup create an adequate configuration file. For now, memory and screen protection are not part of user configuration because they are managed at admin level. I will try to come up with a good solution for better user experience.
@idrassi
Argon2id should not be the default as it should be an option for more experienced users
For new users, Argon2id may be problematic
But I could be wrong
Last edit: Anonymous 2025-06-26
@selectline
I do not understand why you think Argon2id is only for more experienced users. Please explain.
1, set the default SHA512 or Argon2id, mount volume only need 2 seconds
2, set the automatic detection, no matter which algorithm the volume needs 6-7 seconds, which is a serious problem, because set the default detection should also be prioritized SHA512, it should be mounted in 2 seconds, but it did not achieve the effect.
3, it is recommended to use multi-threaded, no need to set the default algorithm, automatic detection of any algorithm can be mounted in 2 seconds.
@idrassi
@fzxx: there is already a logic in VeraCrypt drive to use multi-threading for automatic detection and then stop as soon as the correct PRF is found. But the current implementation waits until all PRFs in current thread pool finish before continuing...this is because we cannot just ignore exiting threads or abort them, we have to wait until they finish properly to avoid data corruption.
That being said, it is technically possible to have a better implementation to avoid this, it is just a matter of complexity. I need to come up with a new idea that doesn't require too much work.
For those interested, here is the culprit part of the code: https://sourceforge.net/p/veracrypt/code/ci/master/tree/src/Common/Volumes.c#l643
We dispatch key derivation work using EncryptionThreadPoolBeginKeyDerivation and at the end we call EncryptionThreadPoolBeginReadVolumeHeaderFinalization to wait for all work items to finish in order to free memory and release resources.
Maybe ask the AI to see a better option?
Argon2id is excellent news. Is it going to be implemented for the Linux version too?
Yes. All major OS platforms.
https://sourceforge.net/p/veracrypt/discussion/technical/thread/645a301988/?limit=25#4aa0
Great! Thank you.
My question is can I use Argon2id also for system encryption ? Thanks !
@tulip-81: for now, system encryption doesn't support Argon2. But it is planned for EFI bootloader so it is coming. For MBR, it is unfortunately impossible to implement because of the constraints of the 16-bit boot environment.
@fzxx: I have used OpenAI o3 and Google Gemini Pro 2.5 to see what they can propose. They both agreed that the only solution is to add cancellation logic inside the cryptographic primitives for various PRFs in order to be able to abort operations as soon as possible.
This is something I never thought about because it breaks separations between layers, and it introduces dependency between low level cryptographic components and high-level business logic.
Despite being ugly, I implemented it and it makes autodetection as fast as the correct PRF. The drawback is that the individual PRFs become a little slower because we need to check a flag periodically. But the loss of performance should not be noticeable by users.
Anyway, I have uploaded version 1.26.26 which contains this change to Nightly Builds folder.
can you please give it a try and share your feedback?
Thank you.
Trivia: Gemini Pro 2.5 has tendency to write a lot of code which ends up not being useful because of quantity of bugs. o3 is more into planning with only hints without much code, which is better.
1, you need to keep prompting the AI to achieve a certain function with the least amount of code and changes, and manually fine-tune the code according to the AI (copying some of the code)
2, v1.26.26 mount volume is already around 2.5 seconds, great
3, optimize all the code using the AI more often, so that the SSDs can reach the maximum speed.
@idrassi Newly discovered an issue where entering the correct password only takes 2 seconds to successfully mount, and the wrong password gets stuck for 10 seconds before prompting an error.
@idrassi
Does the automatic detection changes also improve the favorites mount duration speed of multiple volumes at the same time?
Currently on older versions of VeraCrypt, the favorites mount of multiple volumes at the same time has slower mount times after the first favorite volume mounts.
EDIT:
I am unable to test the VeraCrypt beta software at this time due to I waiting on a software patch from third party vendor. I do not like to make other software changes at the same time so I know if their patch causes other issues, I know which software is the culprit.
Last edit: Enigma2Illusion 2025-06-30
Version 1.26.26 works great on my Win11 x64, 24H2. It takes only a fraction (perhaps not even a second) longer than using SHA-512. Version 1.26.25 took about 7 secs.
Last edit: David 2025-06-30