Score:6

Crypto

Fast cipher without needing hardware support (like ChaCha20) for disk encryption

JanKanis

1/10/24, 4:31 PM

On my old laptop, ChaCha20 is quite a bit faster than AES as there is no hardware acceleration for AES. But for disk encryption AES based schemes seem to be the only option, as a stream cipher like ChaCha20 cannot directly be used for disk encryption. Is it possible to use ChaCha20 in some other way/mode to make it suitable for disk encryption? Or are there any good block ciphers (maybe ARX ciphers?) around that are as fast as ChaCha20 without hardware support that could be used to accelerate the disk encryption?

332

2 + 9

arx

chacha

Maarten Bodewes

1/10/24, 7:10 PM

Are you planning to implement yourself or are you limited to a specific set of algorithms?

0

Reply

Maarten Bodewes

1/10/24, 7:19 PM

By the way, isn't ChaCha20 an ARX-based stream cipher? But I guess you need an ARX based block cipher.

0

Reply

Meir Maor

1/10/24, 8:57 PM

usually when reading from disk you would read at least a 4KB block. and with that size I see no problem with using a stream cipher each block encrypted independently. with it's own IV(not necessarily stored explictly)

0

Reply

Maarten Bodewes

1/10/24, 9:41 PM

@MeirMaor As long as an adversary cannot compare in time that is, otherwise you either need to store the IV (tricky with disk encryption) or you'd leak the XOR of the two plaintext.

1

Reply

JanKanis

1/10/24, 10:05 PM

I'm not planning to implement it myself, this question is more on what I should look out for to be supported in the future, or if there are any fundamental reasons why this won't happen.

1

Reply

Maarten Bodewes

1/10/24, 11:55 PM

That's a good enough reason. Sorry to make another comment, but another option is maybe hardware support from the HDD or SSD. A lot of these things have AES acceleration build in. Most HDD encryption seems to err on the side of security (with support of e.g. Serpent), but that doesn't mean that lightweight crypto doesn't have a place here.

0

Reply

JanKanis

1/11/24, 12:01 AM

ChaCha20 is an ARX stream cipher, which is why it is fast without hardware support, but stream ciphers are AFAIK not suitable for disk encryption. They leak XORs of plaintexts when observed over time, and they allow an attacker to flip individual bits of plaintext. AES-XTS only allows an attacker to randomize 128 bits of plaintext which is marginally better. So some way to turn a stream cipher into a block cipher would solve this question. Or turning just ChaCha20 into a block cipher.

0

Reply

JanKanis

1/11/24, 12:06 AM

Using hardware that supports AES is the practical solution of course, as basically all modern processors do. But I'm specifically asking here w.r.t. old hardware that doesn't support AES in hardware. I guess hardware AES in disk controllers is older than in processors, but relying on a disk's built-in encryption has the drawback of needing to trust the manufacturer as the implementation cannot be scrutinized. (And there have been serious implementation mistakes in the past.)

0

Reply

LightBit

1/11/24, 7:02 PM

Speck128 is probably fastest software block cipher. It is ARX.

0

Reply

Score:12

Crypto

Taylor R Campbell

1/11/24, 12:41 AM

Adiantum¹ is a wide-block cipher built out of ChaCha12, NH-Poly1305, and—for only a small part of the computation—AES. Being a wide-block cipher, Adiantum can encrypt, for example, entire 512-byte or 4096-byte disk sectors at a time. For each disk sector, Adiantum calls the AES permutation only once, so even constant-time software AES takes a small fraction of the Adiantum computation time.

Adiantum is reasonably fast, many times faster than constant-time software AES-XTS or AES-CBC on many machines; see the paper for performance measurements. The security of Adiantum as a tweakable block cipher is proven to be related to the security of ChaCha12 as a PRF and AES as a PRP, with additional advantage quadratic in the number of blocks (due to possible internal Poly1305 collisions), and is safe for exabytes of data in 4096-byte blocks under a single key; see Theorem 1 for the details and Sec. 6.5 for specific usage limits.¹

Android and NetBSD have adopted Adiantum for disk encryption on machines without hardware AES acceleration.^2,3,4 In the NetBSD kernel, AES is computed using constant-time software on machines without hardware AES acceleration.^4,5

Caveat: Adiantum is designed for disk encryption, which reuses the same key over a long period of time for many sectors being rewritten. Unlike the ChaCha or Poly1305 components it uses, Adiantum incurs a high cost to changing keys or handling many keys at once—not relevant to disk encryption. So it's not very general-purpose. (The same authors proposed HPolyC, at lower throughput but cheaper key agility by using just Poly1305 and not NH.) The disk encryption threat model is also very weak—it is only designed to protect secrets against theft or recycling of your disk, so it does nothing to detect forgery.

(Disclosure: I wrote NetBSD's Adiantum and AES code and made the proposal to adopt Adiantum.)

_{¹ Paul Crowley and Eric Biggers, Adiantum: length-preserving encryption for entry-level processors. IACR Transactions on Symmetric Cryptology, 2018(4), 39–61.
https://doi.org/10.13154/tosc.v2018.i4.39-61}

_{² Paul Crowley and Eric Biggers, Introducing Adiantum: Encryption for the Next Billion Users. Google Security Blog, 2019-02-07.
https://security.googleblog.com/2019/02/introducing-adiantum-encryption-for.html}

_{³ NetBSD Manual Pages: cgd(4) -- cryptographic disk driver. NetBSD 10.0_BETA, August 16, 2020.
https://man.netbsd.org/NetBSD-10.0-STABLE/cgd.4}

_{⁴ Taylor R Campbell, AES leaks, cgd ciphers, and vector units in the kernel. NetBSD tech-kern mailing list, 2020-06-17, message-id ⟨[email protected]⟩.
https://mail-index.netbsd.org/tech-kern/2020/06/18/msg026505.html}

_{⁵ Taylor R Campbell, Rework AES in kernel to finally address CVE-2005-1797. NetBSD commit: src/sys, 2020-06-29.
https://mail-index.netbsd.org/source-changes/2020/08/14/msg120525.html}

+ 5

JanKanis

1/11/24, 10:22 AM

Great! This seems to be exactly what I was looking for. Being a wide-block cipher Adiantum offers even better security than AES-XTS. Do you have any idea how Adiantum compares performance-wise against hardware accelerated AES-XTS?

0

Reply

Taylor R Campbell

1/11/24, 12:35 PM

@JanKanis My very rough guess is Adiantum probably achieves about half or a third the throughput of hardware AES-XTS on the same CPU (but still probably higher throughput than variable-time software AES-XTS), assuming reasonably vectorized ChaCha and Poly1305 software. I don't have measurements handy, though, and if I did they would probably be on different hardware from you, so don't quote me on that; I suggest you take some measurements yourself on the hardware and software of interest to you.

0

Reply

poncho

1/11/24, 2:21 PM

What public cryptanalysis has been done against Adiantum? Do you have a security proof reducing it to the strength of ChaCha/Poly1305/AES? If neither, why do you advocate it as being secure?

1

Reply

samuel-lucas6

1/11/24, 6:58 PM

@poncho Not sure any has been done. There's [a proof](https://old.reddit.com/r/crypto/comments/zly9x0/is_anybody_else_concerned_about_the_lack_of/) in the paper. Sounds like it pretty much boils down as you say.

0

Reply

Taylor R Campbell

1/11/24, 8:53 PM

@poncho Citation 1 already has the security reduction of Adiantum to ChaCha12 and AES. I edited the answer to cite the specific theorem in the paper and to sketch concrete usage limits. Does that address your question?

0

Reply

Score:0

Crypto

JanKanis

1/11/24, 11:27 PM

@TaylorRCampbell Your answer is incredible! Not only does it answer the question, but Adiantum is already available on my Linux laptop, ready to be used, I don't even have to install anything. Someone just had to tell me about it (because cryptsetup benchmark does not show all the useful ciphers by default). And adiantum is strictly more secure than AES-XTS because a single ciphertext bit flip randomizes the entire disk sector.

On my old Core i3 CPU @ 2.53GHz I have these benchmarks with for ci in xchacha12,aes-adiantum-plain64 xchacha20,aes-adiantum-plain64 aes-xts-plain64; cryptsetup benchmark -c $ci; end (output edited for readability)

# Tests are approximate using memory only (no storage IO).
#            Algorithm |       Key |      Encryption |      Decryption
xchacha12,aes-adiantum        256b       532,5 MiB/s       538,9 MiB/s
xchacha20,aes-adiantum        256b       441,2 MiB/s       447,0 MiB/s
               aes-xts        256b       124,7 MiB/s       125,2 MiB/s

On my more modern Core i7 @ 2.70 GHz: (highest numbers from multiple runs)

# Tests are approximate using memory only (no storage IO).
#            Algorithm |       Key |      Encryption |      Decryption
xchacha12,aes-adiantum        256b      1066,9 MiB/s      1107,6 MiB/s
xchacha20,aes-adiantum        256b       935,8 MiB/s       951,5 MiB/s
               aes-xts        256b      2189,9 MiB/s      2213,3 MiB/s

(For anyone considering using adiantum for disk encryption, the xchacha20 variant uses more rounds for the chacha cipher and thus has more of a security margin. It is recommended unless you absolutely can't tolerate its performance over the xchacha12 variant, e.g. on a smartwatch. Currently both are secure, but new discoveries in cryptanalysis would potentially break xchacha12 earlier if it ever came to that.)

Now I also want to use adiantum with AES instead of ChaCha on my newer computers for the better security it gives. Guess I'll need to ask on unix.stackexchange about that, as aes-ctr,aes-adiantum-plain64 or something similar doesn't seem to exist in my kernel yet.

+ 4

Taylor R Campbell

1/13/24, 7:19 PM

A variant of Adiantum with AES-CTR instead of XChaCha12 is unlikely to match the performance of hardware-accelerated AES-XTS, and is likely to weaken security both because AES-CTR is lower-security than XChaCha12 (due to PRF/PRP-switching and to the lower security margin of AES vs ChaCha12), and because you have to consider not only the NH-Poly1305 collisions between disk sectors but also the AES-CTR counter collisions between any blocks within disk sectors. You really need a different design for an AES-based wide-block cipher.

1

Reply

JanKanis

1/17/24, 8:42 PM

@TaylorRCampbell Maybe AES-CTR is not the right choice, and sure Adiantum will add some overhead from the extra hashes compared to e.g. AES-XTS, but I would really like a proper wide block cipher for my disk encryption that can make use of hardware acceleration, and replacing the ciphers (and maybe the hash) in Adiantum appears straightforward and at least secure enough.

0

Reply

Taylor R Campbell

1/18/24, 4:18 PM

You can't simply drop in AES-CTR for XChaCha12 here. They have different syntax: 128-bit input (AES) vs 256-bit input (XChaCha12), and Adiantum relies on >128-bit input. There is a way you could do it (use (n + c) mod 2^128 instead of n || c as the input) but that substantively changes the security, invalidating the theorem in the Adiantum paper; you have to do the analysis over again, and getting all the details right for (n + c) mod 2^128 is very difficult. Top cryptographers have gotten this stuff wrong. It's not to be casually tinkered with.

0

Reply

Taylor R Campbell

1/18/24, 4:24 PM

The Adiantum security theorem is relatively straightforward. The corresponding thoerem for the obvious way to substitute AES-CTR for XChaCha12 is not If you can spot the errors in https://eprint.iacr.org/2004/193 and https://eprint.iacr.org/2017/168, then you might be in a position to write a paper proving a security theorem for your variant of Adiantum with AES-CTR...which I guarantee you will have worse security than the original Adiantum even if you don't make a mistake in the theorem/proof. Maybe there's a good tweakable wide-block cipher design built out of AES but I don't know any.

0

Reply

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Fast cipher without needing hardware support (like ChaCha20) for disk encryption

Fast cipher without needing hardware support (like ChaCha20) for disk encryption

Post an answer