Commit be1eb7f7 authored by Ard Biesheuvel's avatar Ard Biesheuvel Committed by Mike Snitzer

crypto: essiv - create wrapper template for ESSIV generation

Implement a template that wraps a (skcipher,shash) or (aead,shash) tuple
so that we can consolidate the ESSIV handling in fscrypt and dm-crypt and
move it into the crypto API. This will result in better test coverage, and
will allow future changes to make the bare cipher interface internal to the
crypto subsystem, in order to increase robustness of the API against misuse.
Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
Tested-by: default avatarMilan Broz <gmazyland@gmail.com>
Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
parent c1499a04
...@@ -568,6 +568,34 @@ config CRYPTO_ADIANTUM ...@@ -568,6 +568,34 @@ config CRYPTO_ADIANTUM
If unsure, say N. If unsure, say N.
config CRYPTO_ESSIV
tristate "ESSIV support for block encryption"
select CRYPTO_AUTHENC
help
Encrypted salt-sector initialization vector (ESSIV) is an IV
generation method that is used in some cases by fscrypt and/or
dm-crypt. It uses the hash of the block encryption key as the
symmetric key for a block encryption pass applied to the input
IV, making low entropy IV sources more suitable for block
encryption.
This driver implements a crypto API template that can be
instantiated either as a skcipher or as a aead (depending on the
type of the first template argument), and which defers encryption
and decryption requests to the encapsulated cipher after applying
ESSIV to the input IV. Note that in the aead case, it is assumed
that the keys are presented in the same format used by the authenc
template, and that the IV appears at the end of the authenticated
associated data (AAD) region (which is how dm-crypt uses it.)
Note that the use of ESSIV is not recommended for new deployments,
and so this only needs to be enabled when interoperability with
existing encrypted volumes of filesystems is required, or when
building for a particular system that requires it (e.g., when
the SoC in question has accelerated CBC but not XTS, making CBC
combined with ESSIV the only feasible mode for h/w accelerated
block encryption)
comment "Hash modes" comment "Hash modes"
config CRYPTO_CMAC config CRYPTO_CMAC
......
...@@ -147,6 +147,7 @@ obj-$(CONFIG_CRYPTO_USER_API_AEAD) += algif_aead.o ...@@ -147,6 +147,7 @@ obj-$(CONFIG_CRYPTO_USER_API_AEAD) += algif_aead.o
obj-$(CONFIG_CRYPTO_ZSTD) += zstd.o obj-$(CONFIG_CRYPTO_ZSTD) += zstd.o
obj-$(CONFIG_CRYPTO_OFB) += ofb.o obj-$(CONFIG_CRYPTO_OFB) += ofb.o
obj-$(CONFIG_CRYPTO_ECC) += ecc.o obj-$(CONFIG_CRYPTO_ECC) += ecc.o
obj-$(CONFIG_CRYPTO_ESSIV) += essiv.o
ecdh_generic-y += ecdh.o ecdh_generic-y += ecdh.o
ecdh_generic-y += ecdh_helper.o ecdh_generic-y += ecdh_helper.o
......
This diff is collapsed.
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment