@@ -338,11 +338,14 @@ Supported modes
338338
339339Currently, the following pairs of encryption modes are supported:
340340
341- - AES-256-XTS for contents and AES-256-CTS- CBC for filenames
341+ - AES-256-XTS for contents and AES-256-CBC-CTS for filenames
342342- AES-256-XTS for contents and AES-256-HCTR2 for filenames
343343- Adiantum for both contents and filenames
344- - AES-128-CBC-ESSIV for contents and AES-128-CTS-CBC for filenames
345- - SM4-XTS for contents and SM4-CTS-CBC for filenames
344+ - AES-128-CBC-ESSIV for contents and AES-128-CBC-CTS for filenames
345+ - SM4-XTS for contents and SM4-CBC-CTS for filenames
346+
347+ Note: in the API, "CBC" means CBC-ESSIV, and "CTS" means CBC-CTS.
348+ So, for example, FSCRYPT_MODE_AES_256_CTS means AES-256-CBC-CTS.
346349
347350Authenticated encryption modes are not currently supported because of
348351the difficulty of dealing with ciphertext expansion. Therefore,
@@ -351,11 +354,11 @@ contents encryption uses a block cipher in `XTS mode
351354`CBC-ESSIV mode
352355<https://en.wikipedia.org/wiki/Disk_encryption_theory#Encrypted_salt-sector_initialization_vector_(ESSIV)> `_,
353356or a wide-block cipher. Filenames encryption uses a
354- block cipher in `CTS- CBC mode
357+ block cipher in `CBC-CTS mode
355358<https://en.wikipedia.org/wiki/Ciphertext_stealing> `_ or a wide-block
356359cipher.
357360
358- The (AES-256-XTS, AES-256-CTS- CBC) pair is the recommended default.
361+ The (AES-256-XTS, AES-256-CBC-CTS ) pair is the recommended default.
359362It is also the only option that is *guaranteed * to always be supported
360363if the kernel supports fscrypt at all; see `Kernel config options `_.
361364
@@ -364,7 +367,7 @@ upgrades the filenames encryption to use a wide-block cipher. (A
364367*wide-block cipher *, also called a tweakable super-pseudorandom
365368permutation, has the property that changing one bit scrambles the
366369entire result.) As described in `Filenames encryption `_, a wide-block
367- cipher is the ideal mode for the problem domain, though CTS- CBC is the
370+ cipher is the ideal mode for the problem domain, though CBC-CTS is the
368371"least bad" choice among the alternatives. For more information about
369372HCTR2, see `the HCTR2 paper <https://eprint.iacr.org/2021/1441.pdf >`_.
370373
@@ -375,13 +378,13 @@ the work is done by XChaCha12, which is much faster than AES when AES
375378acceleration is unavailable. For more information about Adiantum, see
376379`the Adiantum paper <https://eprint.iacr.org/2018/720.pdf >`_.
377380
378- The (AES-128-CBC-ESSIV, AES-128-CTS- CBC) pair exists only to support
381+ The (AES-128-CBC-ESSIV, AES-128-CBC-CTS ) pair exists only to support
379382systems whose only form of AES acceleration is an off-CPU crypto
380383accelerator such as CAAM or CESA that does not support XTS.
381384
382385The remaining mode pairs are the "national pride ciphers":
383386
384- - (SM4-XTS, SM4-CTS- CBC)
387+ - (SM4-XTS, SM4-CBC-CTS )
385388
386389Generally speaking, these ciphers aren't "bad" per se, but they
387390receive limited security review compared to the usual choices such as
@@ -393,7 +396,7 @@ Kernel config options
393396
394397Enabling fscrypt support (CONFIG_FS_ENCRYPTION) automatically pulls in
395398only the basic support from the crypto API needed to use AES-256-XTS
396- and AES-256-CTS- CBC encryption. For optimal performance, it is
399+ and AES-256-CBC-CTS encryption. For optimal performance, it is
397400strongly recommended to also enable any available platform-specific
398401kconfig options that provide acceleration for the algorithm(s) you
399402wish to use. Support for any "non-default" encryption modes typically
@@ -407,7 +410,7 @@ kernel crypto API (see `Inline encryption support`_); in that case,
407410the file contents mode doesn't need to supported in the kernel crypto
408411API, but the filenames mode still does.
409412
410- - AES-256-XTS and AES-256-CTS- CBC
413+ - AES-256-XTS and AES-256-CBC-CTS
411414 - Recommended:
412415 - arm64: CONFIG_CRYPTO_AES_ARM64_CE_BLK
413416 - x86: CONFIG_CRYPTO_AES_NI_INTEL
@@ -433,7 +436,7 @@ API, but the filenames mode still does.
433436 - x86: CONFIG_CRYPTO_NHPOLY1305_SSE2
434437 - x86: CONFIG_CRYPTO_NHPOLY1305_AVX2
435438
436- - AES-128-CBC-ESSIV and AES-128-CTS- CBC:
439+ - AES-128-CBC-ESSIV and AES-128-CBC-CTS :
437440 - Mandatory:
438441 - CONFIG_CRYPTO_ESSIV
439442 - CONFIG_CRYPTO_SHA256 or another SHA-256 implementation
@@ -521,7 +524,7 @@ alternatively has the file's nonce (for `DIRECT_KEY policies`_) or
521524inode number (for `IV_INO_LBLK_64 policies `_) included in the IVs.
522525Thus, IV reuse is limited to within a single directory.
523526
524- With CTS- CBC, the IV reuse means that when the plaintext filenames share a
527+ With CBC-CTS , the IV reuse means that when the plaintext filenames share a
525528common prefix at least as long as the cipher block size (16 bytes for AES), the
526529corresponding encrypted filenames will also share a common prefix. This is
527530undesirable. Adiantum and HCTR2 do not have this weakness, as they are
0 commit comments