Add BLAKE2b-512 as a Hash Algorithm Option

[Marcos Morar]

Hi,

I’d like to propose adding support for the BLAKE2b-512 hash algorithm in VeraCrypt for use with HMAC.

• BLAKE2b-512 offers a 512-bit output (256-bit collision resistance), matching Whirlpool’s strength. It’s based on the SHA-3 finalist BLAKE, with a proven track record of cryptanalysis since 2012, and no known practical attacks exist as of 2025.
• Its optimized for 64-bit platforms, BLAKE2b is faster than SHA-512 and Whirlpool, which could improve mounting times without compromising security.
• While VeraCrypt currently uses BLAKE2s-256, adding BLAKE2b-512 would offer a 512-bit option for those prioritizing a larger security margin, complementing existing choices like Whirlpool and SHA-512.

I understand Whirlpool and SHA-512 are solid, but BLAKE2b-512’s speed and modern design could enhance VeraCrypt’s flexibility for security-conscious users like me who prefer non-NSA alternatives. It’s already widely adopted in tools like WireGuard and Argon2, showing its practical reliability.

Thanks for considering!

Best regards!

[Enigma2Illusion]

I believe that currently VeraCrypt still supports 32-bit Windows 10.

https://sourceforge.net/p/veracrypt/discussion/general/thread/0cc5a5acc6/?limit=25#0206/f71e

https://sourceforge.net/p/veracrypt/discussion/general/thread/0cc5a5acc6/?limit=25#0206/cde1

Perhaps offer BLAKE2b-512 as an option only on 64-bit OSes.

[Marcos Morar]

While it’s true that VeraCrypt supports 32-bit systems and BLAKE2b is optimized for 64-bit architectures, the relevance of 32-bit systems is fading fast. Most modern hardware has shifted to 64-bit, and this trend will only accelerate.

BLAKE2b, with its 512-bit output, offers a stronger security margin, particularly against future threats like quantum computing, where larger hash sizes bolster resilience (e.g., resisting collision attacks reduced to around 170 bits for BLAKE2b vs. around 85 bits for BLAKE2s under Grover’s algorithm). BLAKE2s’s 256-bit output is secure today, but BLAKE2b provides better future-proofing.

You are right, rather than limiting the codebase to BLAKE2s, why not offer an optional 64-bit-only build including BLAKE2b? This could coexist with the current 32-bit-compatible version, giving users flexibility: legacy support for those who need it, and a forward-looking option for the growing 64-bit majority. It’s a practical compromise that aligns VeraCrypt with both current realities and emerging cryptographic demands.

[Marcos Morar]

Hi!

I just wanted to kindly follow up on the feature request. I was wondering if there’s any feedback on whether it’s been accepted, rejected, postponed, or perhaps considered for a short-term or long-term update? Thanks for your time and efforts!

[Kurt Fitzner]

A 512 bit hash doesn't offer any security margin in VeraCrypt over a 256 bit hash. The hash is used solely to derive the (256 bit) header keys from the passphrase.

Where collision resistance is an issue, it's true that a hash of length n only offers n/2 bits of security. However hashes are not used in VeraCrypt in any way that exposes that limitation. Hashes are not used in VeraCrypt in a way that requires collision resistance.

Blake2S is as secure as SHA512 in this context. If you ask me, more so. ChaCha20's use of diagonal bit mixing is nothing short of brilliant, and it is the primitive at the heart of Blake2S.

What I would like to see is ChaCha20 adapted for use in a block setting. It is really a block cipher at its heart anyway, with (luckily enough) 512-bit blocks. If you removed its counter and treated the entire 128-bit nonce in some key-derived way. In fact, it would greatly simplify a lot of the work that XTS has to do to operate on disk blocks. The security reduction for XTS relies on the tweak being independent of the plaintext. A KDF‑derived nonce that is uniformly random satisfies that requirement, so the standard XTS security proofs carry over.

ChaCha20-XTS would provide unassailable trust in a blazingly fast cipher.

[Marcos Morar]

Thank you for your thoughtful response Kurt. I completely understand your point that the security benefits of a 512-bit hash like BLAKE2b-512 are minimal in PBKDF2-HMAC for deriving 256-bit keys, where iteration count (via PIM) and password entropy are the real bottlenecks.

With VeraCrypt introducing Argon2id as a KDF option, the pfuture-proofing advantages I was aiming for with BLAKE2b-512 in PBKDF2 have largely lost their relevance. Argon2id’s memory-hard design, built on BLAKE2b, offers superior resistance to GPU/ASIC attacks, addressing modern security needs far beyond what a hash tweak could achieve.

I fully back your feature request for ChaCha20-XTS, aybe create a separate feature request thread for it?