1.26 released for testing 21/03/2022
Open source disk encryption with strong security for the Paranoid
Brought to you by:
idrassi
Menu
▾
▴
Version 1.26 has been released for testing on Windows and installers are available at https://sourceforge.net/projects/veracrypt/files/VeraCrypt%20Nightly%20Builds/
Changes between 1.25.9 and 1.26 (21 March 2022) :
All OSes:
Windows:
Dear Mounir,
Many thanks for this new version for testing.
Would you consider carrying out a Coverity scan since one has not been carried out since January 2020 and a lot of code was added and removed in the following commit?
Implement support of Blake2s-256 hash algorithm and remove deprecated algorithms RIPEMD-160 and GOST89
Have a good evening.
Last edit: AJ B 2022-03-23
Dear Mounir,
Sorry to bother you again.
If possible, may I also request the most recent version of zlib 1.2.12 be included in a future release of VeraCrypt, please? A 17 year old CVE has been fixed within it:
https://nakedsecurity.sophos.com/2022/03/29/zlib-data-compressor-fixes-17-year-old-security-bug-patch-errr-now/
Many thanks.
Dear Mounir and the VeraCrypt team,
I wish to raise a very similar request.
I have created a ticket (#511) to request the zlib library used within VeraCrypt be updated again. Version 1.2.13 resolves a critical heap-based buffer overflow (CVSS3 score of 9.8). This vulnerability has been assigned CVE-2022-37434 :
https://nvd.nist.gov/vuln/detail/CVE-2022-37434
Many thanks.
Last edit: AJ B 2022-11-14
Hi! What about including new icons, like the ones you can find in this thread: https://sourceforge.net/p/veracrypt/discussion/features/thread/9298d888/
Hello Mounir,
The user guide for 1.26 for "Header Key Derivation, Salt, and Iteration Count" regarding non-system iterations does not match the benchmark iterations.
According to the 1.26 user guide:
To me, the second bullet point can be misinterpreted due to it implies that 500000 is used only for SHA-512 or Whirlpool for all modes of system encryption and non-system encryption and file containers.
According to the PKCS-5 PRF benchmarks, the 500000 is used for only for SHA-512 and Whirlpool for system encryption and the 500000 iterations is used for all the hash algorithms for non-system encryption and file containers.
Below is my suggestion for restating the bullets for clarity as shown below:
PS: The same possible misinterpretation exists for PIM value as shown below:
.
Below is my suggestion for restating the bullets for clarity as shown below for both the "Header Key Derivation, Salt, and Iteration Count" and PIM sections of the documentation and user guide:
Last edit: Enigma2Illusion 2022-03-22
@ajb87351: The last coverity scan was actually done on January 2020 as you can see in the screenshow below. But I agree that it is due time to trigger a new scan.
I have performed a new scan and I uploaded its output to Coverity website. I will check tomorrow the results.
@enigma2illusion: Thank you for the change suggestion. Indeed, the current wording can be confusing and your proposal is better. I will update the documentation based on it.
Dear Mounir,
Sorry, I referenced the wrong date when I wrote January 2015, you are correct and many thanks for so promptly actioning this request. I have edited my post to correct that.
Off topic: I recently upgraded my VeraCrypt file volumes from 64-character keys to 128 character keys and the process was totally seamless. I really appreciate the quality of the code you write. I’ve sent another donation to you.
Last edit: AJ B 2022-03-23
@ajb87351:Thank you for your feedback and your support!
Concerning Coverity, the new scan didn't find any serious issue (the report had many false positives as usual). I already pushed changes to address Coverity findings and the new scan results are below: Defect density has gone from 0.05 to 0.00 which is a good indicator.
Since the scan done in 2020, the number of effective lines of code used has increased by 230246 lines ("Lines of code in selected components" in Coverity report). The code base is getting larger and larger with time...
@enigma2illusion: I have applied your suggestion to the documentation and I pushed the changes, thank you.
Hi Mounir,
You are very welcome and many thanks for resolving those Coverity issues so promptly. I hope they were not too tedious.
Wow, that is a huge increase in the code base but as you say the defect density is still lower than before. Excellent work.
@idrassi
Thank you Mounir!
Mounir requesting proposals for mounting junction points in the VeraCrypt application.
https://sourceforge.net/p/veracrypt/discussion/technical/thread/1e007bdc/?limit=25#952f
It is recommended to increase the Blake3 algorithm
@fzxx : Blake3 is too fast for our usage. VeraCrypt requires the use of a hash function that has strong security properties and that is slow enough to make the cost of brute force very high. Blake2s fulfills this but Blake3 is too fast for it.
Too slow, affecting everyday use, now load the volume for about 10 seconds;Suggest: When using the file key, no 20-bit password can set any PIM.
Hi Mounir, I have been following the Veracrypt project from the very beginning when Truecrypt was still active and in vogue, but it is the first time that I intervene.
I want to thank you for all the work you continuously do on the project, I appreciate it very much. In the past I have also made some donations.
Like many I am passionate about these topics and have a question. References were always made to Blake2s and not to Blake 2b or simply to Blake 2, is there a reason for this? If I'm not mistaken Blake2s is equivalent to BLAKE-256 and Blake 2b to BLAKE-512, is there a reason why there is no reference to this latest version?
Thanks for all your work
If you install 1.26 that is currently being tested by the user community, you will find the BLAKE2s-256 references in the Help > User Guide.
The online documentation is showing the production release of 1.25.9 version.
From my research, BLAKE2s (256) is optimized for 8- to 32-bit platforms and produces digests of any size between 1 and 32 bytes.
BLAKE2b (512) is optimized for 64-bit platforms and produces digests of any size between 1 and 64 bytes.
Source:
https://www.blake2.net/
My guess is that BLAKE2s was chosen due to it could be used for all the hash modes in VeraCrypt for MBR system encryption, UEFI system encryption and non-system encryption.
The MBR system encryption uses 16-bit VeraCrypt bootloader. The size of the bootloader for MBR systems is limited to ~32 KB. Hence, the reason for only two hash algorithms are offered.
https://sourceforge.net/p/veracrypt/discussion/general/thread/e217f0ebfe/?limit=25#978a
@phoenix-rising: Thank you for the your kind words and for your support.
Concerning Blake2s choice, @enigma2illusion explanation is correct: one of the argument is the fact that Blake2s can be used for MBR system encryption.
There are two arguments that made me choose Blake2s over Blake2b:
I’m puzzled by the claim that BLAKE2s is "ASIC-resistant" and that BLAKE2b is easier to crack due to existing ASICs. Neither BLAKE2s nor BLAKE2b was designed with ASIC resistance in mind—both are optimized for speed, including on hardware. The absence of BLAKE2s ASICs seems more about market demand (e.g., BLAKE2b’s use in crypto mining) than any inherent resistance. If anything, this suggests BLAKE2s could be targeted by ASICs too, given enough incentive.
More importantly, for brute-force attacks, the hash’s output size dictates security, not ASIC availability. BLAKE2s’s 256-bit output gives 128-bit collision resistance, while BLAKE2b’s 512-bit output gives 256-bit—making BLAKE2b far harder to crack, even with ASICs speeding up the process. In VeraCrypt’s context (e.g., key derivation), the KDF’s iteration count already limits hardware advantages, so the hash’s raw strength matters more than whether ASICs exist.
@idrassi
For the VeraCrypt Rescue Disk, are all operations using either 16-bit, 32-bit or 64-bit?
For example, if the user selects decrypt system encryption, is the Rescue Disk using 16-bit for MBR and 32-bit or 64-bit for UEFI?
Last edit: Enigma2Illusion 2022-03-29
@enigma2illusion: Your understanding is correct. MBR Rescue disk is 16-bit and UEFI Rescue Disk is 32-bit/64-bit depending on the architecture of Windows running during the system encryption process.
@ajb87351: Thank you for the information about zlib new release. I was aware of the issue that was discovered but I missed the 1.2.12 release. I have just pushed the new zlib source code and I will do some tests to check that nothing is broken. I hope to be able to release 1.26 soon after finalizing some ongoing changes.
Thanks very much Mounir and there is no rush to release 1.26, at least in my opinion. Please take all the time you need.
Hello Mounir
I don't see anything about performance degradation on SSD for encrypted windows.
this problem becomes urgent as SSD usage increase.
from benchmarks i see
HDD with physical sectors 512 performance lost ~4%
HDD with physical sectors 4096 performance lost ~ 30% (for randoms I/O), i think varacrypt don't use 4kclusters on 4k sectors boundaries.
SSD logical sectors 512 performance lost ~90% (for randoms I/O)
by comparison
encrypted linux Kubuntu 20.04 (with LUKS &dm-crypt) on SSD no performance degradation seen
Have you a planning for this problem ?
best regards
I installed 1.26 x64 on top of 1.25.9 but Help>About in VeraCrypt shows version 1.25.9 is installed whereas Programs and Features (Windows 10 - 19044.1620) shows 1.26 is installed. I completely uninstalled VeraCrypt and rebooted. When I tried to install 1.26 it fails to install with this error message "The installation of the device driver has failed. Please restart windows and then try installing VeraCrypt again." The installation then rolls back.
I rebooted and tried again to install VeraCrypt 1.26 but the installer displayed the same error message.
I then installed 1.25.9 successfully.
If VeraCrypt produces a debug log during installation, I can post it if you tell me where it is.