[Feature] ChaCha cipher, Argon2 hash

[Tharn]

Hi,

The ChaCha20 cipher (https://cr.yp.to/chacha.html) is supposed to be a great deal more performant than the other ciphers currently available in VeraCrypt. It could be useful for low-power devices, Linux, netbooks, servers. And anything that does not run on a newer generation Intel with AES-NI.

1.20b2 Twofish on my C2D manages 280MB/s which is excellent. But a faster algorithm would still be preferable. The combination of old CPU and SSD is fairly popular.

I don't know much about Argon2 except that it's won the Password Hashing Competition. (https://github.com/P-H-C/phc-winner-argon2)

Thanks for all your work on VC!

[My1]

I would totally agreee to this. especially considering that for a system drive that should be locked down you could easily take all the RAM you can afford in pre-boot and therefore REALLY take up resources.

and of course chacha is a nice thing too.

[voyager-nx24]

ChaCha20 is a stream cipher, and I have not seen any stream cipher being used for full disk encryption. Due to FDE contraints, using stream cipher for FDE is a bad idea anyway.

https://crypto.stackexchange.com/questions/53532/has-anyone-seen-a-stream-cipher-being-used-for-fde

[My1]

okay, but even if a streamcipher isnt a pretty good choice for FDE this leaves argon2 on the list for Key derivation, especially because it was also designed for doing password-based stuff and resource-taking, unlike things like SHA-512.

[voyager-nx24]

especially because it was also designed for doing password-based stuff and resource-taking, unlike things like SHA-512.

VeraCrypt does not use SHA-512 (or any hash algorithm) as is. The hash is one of the five inputs for PBKDF2, a key derivation function.

https://www.veracrypt.fr/en/Header%20Key%20Derivation.html

If VeraCrypt simply use the hash output as is then that would be insecure, but it doesn't.

That said Argon2 (specifically Argon2d) would be a nice thing to have.

[My1]

well PBKDF2 basically works by stacking SHA512 (with HMAC but that's beside the point) or whatever selected hash function selected, where imo a dedicated thing like argon might be better

Regarding your last sentence in regards to Argon2d, I honestly wouldnt be for Argon2d but rather Argon2id.

Argon2d has the big problem of side channels, which isnt really something you want for something like this.

[Eyremba]

Yes, Argon2id would be the best, it combines both solutions.

[My1]

precisely, a2i is often used, because it doesnt have the sidechannels but a2i has tradeoff attacks, which is something we kinda dont want.

[voyager-nx24]

Well ask yourself this, is side channel attack an issue here for full disk encryption? For side channel attack to be a viable threat here, your attackers must have access to your computer.

But if your attackers do have access to your computer, there are much easier ways to defeat full disk encryption. Your attacker could install keylogger to record your password. Or he could dump your memory to search for the decryption key. In addition, if you happened to mount the encrypted drive while attackers are snooping around your computer then every file in there is up for grab. FDE only protects drive contents when the drive is offline.

On the other hand, you will want to make it really hard for people in physical possession of your encrypted drive to brute force the password. Argon2d gives you the best protection against GPU/ASIC brute force.

[Eyremba]

Argon2d gives you the best protection against GPU/ASIC brute force.

@trumpet205 and what is with Argon2id? It combines i and d, so it should be the best in this case, right?

[voyager-nx24]

Argon2id is a hybrid of Argon2i and Argon2d, using a combination of data-depending and data-independent memory accesses, which gives some of Argon2i's resistance to side-channel cache timing attacks and much of Argon2d's resistance to GPU cracking attacks.

Argon2id has properties from both d and i, but to maximize protection against a particular threat you still want to go for i or d, depending on your threat model.

I'm advocating d here because I don't consider side channel attack, more specifically timing attack, to be a viable threat here. You are running encryption software (VeraCrypt) locally (not on a shared server), and full disk encryption protects drive contents while offline. In cases like this timing attack really has no place to be. The only viable threat is cold boot attack, but that is not a timing attack to begin with.

[vstoykovbg]

We can use external application for the key stretching. I am using Scrypt-based script (SlowKDF). This is a practical workaround for old software not supporting heavy key stretching like GnuPG.

But it's not practical when the password dialogue is appearing before any OS boots when hiding the OS inside encrypted container (running it on another computer, then typing the output...).

It would be great if there is an option to choose Scrypt, Argon2, Catena, Lyra2, Makwa, yescrypt, or a mix of key stretching functions (like I am using Scrypt and sha512 in my SlowKDF).

The old hash functions that require very little RAM are easy to be brute-forced with ASICs.

The main competitor of TrueCrypt - LUKS - now supports Argon2. The popular password manager KeePassXC also added Argon2 support.

Example complex hashing (pseudocode, + is concatenation):

digest = ""

repeat N times: {
 digest = sha512(password + salt + digest) + Whirlpool(password + salt + digest)
 digest = Scrypt(digest)
 digest = sha512(password + salt + digest) + Whirlpool(password + salt + digest)
 digest = Argon2(digest)
 digest = sha512(password + salt + digest) + Whirlpool(password + salt + digest)
 digest = Catena(digest)
 digest = sha512(password + salt + digest) + Whirlpool(password + salt + digest)
 digest = Lyra2(digest)
 digest = sha512(password + salt + digest) + Whirlpool(password + salt + digest)
 digest = Makwa(digest)
 digest = sha512(password + salt + digest) + Whirlpool(password + salt + digest)
 digest = yescrypt(digest)
}

digest = password + salt + sha512(password + salt + digest)

And then digest is sent to the old code. (Oops, it would not work. There is a 128 characters limit. But a workaround can be designed.)

[0xRustlang]

Is there any update to this issue?

The popular password manager KeePassXC also added Argon2 support.

Also sorry off-topic here but KeepassXC won't encrypt data that are in memory (+ ) in opposite of original keepass (+ ) I suggest to reconsider using it. at least on windows the original keepass use much more security functions of dot net so it seems somehow more secure.(+ )

[My1]

Also sorry off-topic here but KeepassXC won't encrypt data that are in memory

where do you think that encryption key is stored tho? probably in memory. unless you want to ask the user user for a password all day long

[0xRustlang]

where do you think that encryption key is stored tho? probably in memory. unless you want to ask the user user for a password all day long

That is true for both Keepass and KeepassXC.

Also both Keepass and KeepassXC try to set their process protected and set Protections / limitations that the OS let them to do.

but the difference is Keepass encrypts the data in memory in addition of those other Protections but KeepassXC doesn't do it because of limitations of qt. [1] [2]

Although if the OS be infected there won't be much difference using encryption in memory or not but at least it is good for not so well written malwares.

[cypherbits]

Thumbs up for implementing at least Argon2id for hashing algorithms since sha512 can be accelerated on GPUs and are more easier to break. (https://blog.elcomsoft.com/2020/03/breaking-veracrypt-containers/)

[cypherbits]

Anything new on this? Having Argon2 at least would be awesome... I'm actually trying to do it myself but I just started with C a week ago...

[cypherbits]

Hi @idrassi I think implementing LibSodium on Veracrypt is a priority now:

• Argon2 is needed so people with many GPU power don't break passwords (my elcomsoft post). This should be the next feature, priority.
• Chacha20/Xchacha20 or related is needed so we could combine AES+this for speed and security for those wanting double encryption.

I have no idea about C but I will see if I can try to do it... If you are alone developing Veracrypt, remember many people would donate to a crowdfunding to hire developers.

[Neirpyc]

Given that modern ASICs can do many TH/s, with 500 000 sha512 as a PBKDF, this means an attacker can try millions of password per second with a single device. This makes high entropy passwords (>40bits) safe as of today, but the hash rate of such attacks has been greatly increased in the past 10 years, and I believe getting argon2(i|d|id) support in a near future is important to keep VeraCrypt volumes safe in the coming decades. I'd love to help implementing modern PBKDF algorithms, but I've heard some stuff about VC's hash running in Kernel Mode, and I have almost no knowledge of VC's internals. Is there any resource I could use to understand how such a feature should be implemented?

[cypherbits]

@Neirpyc If you have experience with C, you know more than me. I tried to look in the code and actually made appear Argon2 on the list with this library (https://github.com/P-H-C/phc-winner-argon2). But I ran into problems and I think we should just use the libsodium library for this. If you know C, we could work together to implement libsodium...

[Neirpyc]

@cypherbits I looked at the wiki, which gives a simple implementation, and it is long to implement but not that hard! The problem is that with VC, when an OS partition is encrypted, we have to decrypt it before we boot. Because of that, we have no OS, an cannot use OSs' functions such as malloc which makes libsodium unusable. An usual C implementation would fail for the same reason. Thus, I'd love to implement it, but I need advice and guidance from a VC experimented dev (and we've got only one dev x). Until @idrassi (or anyone who knows enough) points me to resources or specification for implementing Argon2, I cannot do anything.

[cypherbits]

Thinking about the future of the project I don't know what will happen if we only have one developer. Maintaining an encrypted boot OS option is very hard with Windows changing things constantly, there are many issues open already. So, I don't know if Veracrypt could make a crowdfunding for hiring developers or fund features... Maybe we need to remove the encrypted OS feature and keep improving containers? IDK...

[Neirpyc]

Encrypted OS is a core feature of VC. I doubt it could/should be removed.

Anyways, VC is waay ahead of other solutions, especially about Plausible Deniability. I haven't been following this project until recently, but this project is mature, and one dev doing maintenance may be enough, but more devs would be great! Also, moderators to answer and close non relevant issue could be a good thing ^^

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[cypherbits]

This is still desired, bad robot! Xd

[PleasantMachine9]

ChaCha20 is a stream cipher, and I have not seen any stream cipher being used for full disk encryption. Due to FDE contraints, using stream cipher for FDE is a bad idea anyway.

https://crypto.stackexchange.com/questions/53532/has-anyone-seen-a-stream-cipher-being-used-for-fde

Hi, actually Google released a seemingly very promising proposal on a disk encryption algorithm using ChaCha (XChaCha12):

• https://github.com/google/adiantum
• https://tosc.iacr.org/index.php/ToSC/article/view/7360/6530

It addresses the issues in your link saying "three properties that we wouldn't have with stream ciphers":

• If AES hardware is absent, AES is relatively slow, especially constant-time implementations

• Using XTS, a one-bit change to the plaintext means only a 16-byte change to the ciphertext, revealing more to the attacker than necessary.

Adiantum uses a fast hash (NH + Poly1305) and a fast stream cipher (XChaCha12) to build a construction which encrypts an entire sector at a time. On an ARM Cortex-A7 processor, Adiantum decrypts 4096-byte messages at 10.6 cycles per byte, over five times faster than AES-256-XTS. It is a "super pseudorandom permutation" over the whole sector, which means that any change to the plaintext of the sector results in an unrecognizably different ciphertext sector and vice versa.

Whole-sector encryption anyway makes more sense in many ways than 16-byte block encryption, since the software can generally only read/write a whole sector as one unit, so there is not much benefit to the smaller chunks.

[PleasantMachine9]

Also, regarding adiantum, even on an AMD Ryzen CPU it is 4-10x faster than AES-256-XTS for 4096 block size(according to their benchmark tool ran locally (with software-only instructions)~~, so it's not just a feature for old/weak CPUs~~:

Detected max CPU frequency: 3600.000 MHz
Benchmark parameters:
	bufsize		4096
	ntries		25

HPolyC-XChaCha12-AES encryption (generic)      7.678 cpb (468868 KB/s)
HPolyC-XChaCha12-AES decryption (generic)      7.795 cpb (461834 KB/s)

Adiantum-XChaCha12-AES encryption (generic)    5.759 cpb (625090 KB/s)
Adiantum-XChaCha12-AES decryption (generic)    5.843 cpb (616110 KB/s)

AES-128-XTS encryption (generic)              21.902 cpb (164368 KB/s)
AES-128-XTS decryption (generic)              36.005 cpb (99987 KB/s)

AES-256-XTS encryption (generic)              30.193 cpb (119232 KB/s)
AES-256-XTS decryption (generic)              51.588 cpb (69783 KB/s)

[Tharn]

@PleasantMachine9 Note that your results read to me like software-only. Hardware acceleration will result in much, much higher values for encryption and decryption, so this is misleading. Look at my AES value for Ryzen 3700X. I expect ChaCha12 to be several times faster than the next best software algo, so think Twofish x3 maybe. On Ryzen, software ChaCha12 is probably not going to beat hardware AES - but that's not what's great about it anyway. ChaCha is great for low-power devices or those who don't have AES-NI.

[Neirpyc]

I believe ChaCha is much more used then Twofish or Serpent.

Out of all the new encryption algorithms being developed today, this one has the best growth rate, is a part of TLS 1.3 standard, and it would not surprise me if hardware accelerated ChaCha started being deployed in the next decade.

Anothing great with ChaCha is that it is a random access stream cipher. It has all advantages of stream and block ciphers. As XTS and other cipher modes require extra computation to encrypt, ChaCha is getting not that slow comparatively, and yet it is as secure, and could support a user defined iteration count.

Also, it is very different from AES/Twogish/Serpent and all the S-Box based block ciphers, which means it is unlikely to suffer from the same flaws as the most used algorithms are.

It is very probable that it is at least as good as AES and certain it will not be broken at the same time, and for that reason, I believe it should be here, at least as a backup.

And for the future of this algorithm, Apple M1 has AES-NI, but a low-end ARM based laptop may not have such instructions which would render encryption much faster (and less power consuming) with ChaCha.

[PleasantMachine9]

Anothing great with ChaCha is that it is a random access stream cipher. It has all advantages of stream and block ciphers.

Specifically in the Adiantium scheme I linked above, I don't think that random access will work (at least not simply), but that shouldn't be a big issue beause sectors can only be read/written as a whole anyway, to my knowledge.

As the Google whitepaper says, only an entire sector can be encrypted or decrypted, as a whole unit (because any single bit flip changes the whole sector's content due to their "super pseudorandom permutation").

Note that your results read to me like software-only.

Regarding speed: I will have to check, you are probably right. With the veracrypt benchmark, it does not say if the benchmark is doing raw AES (ECB), or AES-XTS. The XTS mode has overhead compared to raw AES.

[Tharn]

I think VeraCrypt does XTS by default, since it's the most sensible mode for disk encryption.