@@ -147,9 +147,8 @@ However, these ioctls have some limitations:
147147 were wiped. To partially solve this, you can add init_on_free=1 to
148148 your kernel command line. However, this has a performance cost.
149149
150- - Secret keys might still exist in CPU registers, in crypto
151- accelerator hardware (if used by the crypto API to implement any of
152- the algorithms), or in other places not explicitly considered here.
150+ - Secret keys might still exist in CPU registers or in other places
151+ not explicitly considered here.
153152
154153Full system compromise
155154~~~~~~~~~~~~~~~~~~~~~~
@@ -406,9 +405,12 @@ the work is done by XChaCha12, which is much faster than AES when AES
406405acceleration is unavailable. For more information about Adiantum, see
407406`the Adiantum paper <https://eprint.iacr.org/2018/720.pdf >`_.
408407
409- The (AES-128-CBC-ESSIV, AES-128-CBC-CTS) pair exists only to support
410- systems whose only form of AES acceleration is an off-CPU crypto
411- accelerator such as CAAM or CESA that does not support XTS.
408+ The (AES-128-CBC-ESSIV, AES-128-CBC-CTS) pair was added to try to
409+ provide a more efficient option for systems that lack AES instructions
410+ in the CPU but do have a non-inline crypto engine such as CAAM or CESA
411+ that supports AES-CBC (and not AES-XTS). This is deprecated. It has
412+ been shown that just doing AES on the CPU is actually faster.
413+ Moreover, Adiantum is faster still and is recommended on such systems.
412414
413415The remaining mode pairs are the "national pride ciphers":
414416
@@ -1326,22 +1328,13 @@ this by validating all top-level encryption policies prior to access.
13261328Inline encryption support
13271329=========================
13281330
1329- By default, fscrypt uses the kernel crypto API for all cryptographic
1330- operations (other than HKDF, which fscrypt partially implements
1331- itself). The kernel crypto API supports hardware crypto accelerators,
1332- but only ones that work in the traditional way where all inputs and
1333- outputs (e.g. plaintexts and ciphertexts) are in memory. fscrypt can
1334- take advantage of such hardware, but the traditional acceleration
1335- model isn't particularly efficient and fscrypt hasn't been optimized
1336- for it.
1337-
1338- Instead, many newer systems (especially mobile SoCs) have *inline
1339- encryption hardware * that can encrypt/decrypt data while it is on its
1340- way to/from the storage device. Linux supports inline encryption
1341- through a set of extensions to the block layer called *blk-crypto *.
1342- blk-crypto allows filesystems to attach encryption contexts to bios
1343- (I/O requests) to specify how the data will be encrypted or decrypted
1344- in-line. For more information about blk-crypto, see
1331+ Many newer systems (especially mobile SoCs) have *inline encryption
1332+ hardware * that can encrypt/decrypt data while it is on its way to/from
1333+ the storage device. Linux supports inline encryption through a set of
1334+ extensions to the block layer called *blk-crypto *. blk-crypto allows
1335+ filesystems to attach encryption contexts to bios (I/O requests) to
1336+ specify how the data will be encrypted or decrypted in-line. For more
1337+ information about blk-crypto, see
13451338:ref: `Documentation/block/inline-encryption.rst <inline_encryption >`.
13461339
13471340On supported filesystems (currently ext4 and f2fs), fscrypt can use
0 commit comments