Skip to content

Commit 2f944c6

Browse files
committed
fscrypt: write CBC-CTS instead of CTS-CBC
Calling CBC with ciphertext stealing "CBC-CTS" seems to be more common than calling it "CTS-CBC". E.g., CBC-CTS is used by OpenSSL, Crypto++, RFC3962, and RFC6803. The NIST SP800-38A addendum uses CBC-CS1, CBC-CS2, and CBC-CS3, distinguishing between different CTS conventions but similarly putting the CBC part first. In the interest of avoiding any idiosyncratic terminology, update the fscrypt documentation and the fscrypt_mode "friendly names" to align with the more common convention. Changing the "friendly names" only affects some log messages. The actual mode constants in the API are unchanged; those call it simply "CTS". Add a note to the documentation that clarifies that "CBC" and "CTS" in the API really mean CBC-ESSIV and CBC-CTS, respectively. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Eric Biggers <[email protected]>
1 parent d3a7bd4 commit 2f944c6

File tree

2 files changed

+18
-15
lines changed

2 files changed

+18
-15
lines changed

Documentation/filesystems/fscrypt.rst

Lines changed: 15 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -338,11 +338,14 @@ Supported modes
338338

339339
Currently, 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

347350
Authenticated encryption modes are not currently supported because of
348351
the 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)>`_,
353356
or 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
356359
cipher.
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.
359362
It is also the only option that is *guaranteed* to always be supported
360363
if 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
365368
permutation, has the property that changing one bit scrambles the
366369
entire 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
369372
HCTR2, 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
375378
acceleration 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
379382
systems whose only form of AES acceleration is an off-CPU crypto
380383
accelerator such as CAAM or CESA that does not support XTS.
381384

382385
The remaining mode pairs are the "national pride ciphers":
383386

384-
- (SM4-XTS, SM4-CTS-CBC)
387+
- (SM4-XTS, SM4-CBC-CTS)
385388

386389
Generally speaking, these ciphers aren't "bad" per se, but they
387390
receive limited security review compared to the usual choices such as
@@ -393,7 +396,7 @@ Kernel config options
393396

394397
Enabling fscrypt support (CONFIG_FS_ENCRYPTION) automatically pulls in
395398
only 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
397400
strongly recommended to also enable any available platform-specific
398401
kconfig options that provide acceleration for the algorithm(s) you
399402
wish to use. Support for any "non-default" encryption modes typically
@@ -407,7 +410,7 @@ kernel crypto API (see `Inline encryption support`_); in that case,
407410
the file contents mode doesn't need to supported in the kernel crypto
408411
API, 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
521524
inode number (for `IV_INO_LBLK_64 policies`_) included in the IVs.
522525
Thus, 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
525528
common prefix at least as long as the cipher block size (16 bytes for AES), the
526529
corresponding encrypted filenames will also share a common prefix. This is
527530
undesirable. Adiantum and HCTR2 do not have this weakness, as they are

fs/crypto/keysetup.c

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -23,7 +23,7 @@ struct fscrypt_mode fscrypt_modes[] = {
2323
.blk_crypto_mode = BLK_ENCRYPTION_MODE_AES_256_XTS,
2424
},
2525
[FSCRYPT_MODE_AES_256_CTS] = {
26-
.friendly_name = "AES-256-CTS-CBC",
26+
.friendly_name = "AES-256-CBC-CTS",
2727
.cipher_str = "cts(cbc(aes))",
2828
.keysize = 32,
2929
.security_strength = 32,
@@ -38,7 +38,7 @@ struct fscrypt_mode fscrypt_modes[] = {
3838
.blk_crypto_mode = BLK_ENCRYPTION_MODE_AES_128_CBC_ESSIV,
3939
},
4040
[FSCRYPT_MODE_AES_128_CTS] = {
41-
.friendly_name = "AES-128-CTS-CBC",
41+
.friendly_name = "AES-128-CBC-CTS",
4242
.cipher_str = "cts(cbc(aes))",
4343
.keysize = 16,
4444
.security_strength = 16,
@@ -53,7 +53,7 @@ struct fscrypt_mode fscrypt_modes[] = {
5353
.blk_crypto_mode = BLK_ENCRYPTION_MODE_SM4_XTS,
5454
},
5555
[FSCRYPT_MODE_SM4_CTS] = {
56-
.friendly_name = "SM4-CTS-CBC",
56+
.friendly_name = "SM4-CBC-CTS",
5757
.cipher_str = "cts(cbc(sm4))",
5858
.keysize = 16,
5959
.security_strength = 16,

0 commit comments

Comments
 (0)