8
$\begingroup$

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?

$\endgroup$
9
  • $\begingroup$ Are you planning to implement yourself or are you limited to a specific set of algorithms? $\endgroup$
    – Maarten Bodewes
    Commented Jan 10, 2023 at 19:10
  • $\begingroup$ By the way, isn't ChaCha20 an ARX-based stream cipher? But I guess you need an ARX based block cipher. $\endgroup$
    – Maarten Bodewes
    Commented Jan 10, 2023 at 19:19
  • $\begingroup$ 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) $\endgroup$
    – Meir Maor
    Commented Jan 10, 2023 at 20:57
  • 1
    $\begingroup$ @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. $\endgroup$
    – Maarten Bodewes
    Commented Jan 10, 2023 at 21:41
  • 1
    $\begingroup$ 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. $\endgroup$
    – JanKanis
    Commented Jan 10, 2023 at 22:05

2 Answers 2

16
$\begingroup$

Adiantum1 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.1

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.)


1 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

2 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

3 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

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

5 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

$\endgroup$
5
  • $\begingroup$ 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? $\endgroup$
    – JanKanis
    Commented Jan 11, 2023 at 10:22
  • $\begingroup$ @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. $\endgroup$ Commented Jan 11, 2023 at 12:35
  • 1
    $\begingroup$ 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? $\endgroup$
    – poncho
    Commented Jan 11, 2023 at 14:21
  • $\begingroup$ @poncho Not sure any has been done. There's a proof in the paper. Sounds like it pretty much boils down as you say. $\endgroup$ Commented Jan 11, 2023 at 18:58
  • $\begingroup$ @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? $\endgroup$ Commented Jan 11, 2023 at 20:53
0
$\begingroup$

@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.

edit: The hardware accelerated version of a wide block cipher also exists, it's called HCTR2, and is available in Linux kernel 6. Thanks @PaulCrowley!

$\endgroup$
5
  • 1
    $\begingroup$ 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. $\endgroup$ Commented Jan 13, 2023 at 19:19
  • $\begingroup$ @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. $\endgroup$
    – JanKanis
    Commented Jan 17, 2023 at 20:42
  • $\begingroup$ 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. $\endgroup$ Commented Jan 18, 2023 at 16:18
  • $\begingroup$ 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 eprint.iacr.org/2004/193 and 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. $\endgroup$ Commented Jan 18, 2023 at 16:24
  • 1
    $\begingroup$ The good news is that the designers of Adiantum also tackled this problem: eprint.iacr.org/2021/1441 $\endgroup$ Commented Nov 1, 2023 at 21:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.