On 18/06/2019 23:27, Ard Biesheuvel wrote:
> This series creates an ESSIV template that produces a skcipher or AEAD
> transform based on a tuple of the form ',,'
> (or ',,' for the AEAD case). It exposes the
> encapsulated sync or async skcipher/aead by passing through all operations,
> while using
Implement a template that wraps a (skcipher,cipher,shash) or
(aead,cipher,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 int
Instead of open coding the calculations for ESSIV handling, use a
ESSIV skcipher which does all of this under the hood.
Signed-off-by: Ard Biesheuvel
---
fs/crypto/Kconfig | 1 +
fs/crypto/crypto.c | 5 --
fs/crypto/fscrypt_private.h | 9 --
fs/crypto/keyinfo.c | 88
Instead of allocating a crypto skcipher tfm 'foo' and attempting to
infer the encapsulated block cipher from the driver's 'name' field,
directly parse the string that we used to allocated the tfm. These
are always identical (unless the allocation failed, in which case
we bail anyway), but using the
Replace the explicit ESSIV handling in the dm-crypt driver with calls
into the crypto API, which now possesses the capability to perform
this processing within the crypto subsystem.
Signed-off-by: Ard Biesheuvel
---
drivers/md/Kconfig| 1 +
drivers/md/dm-crypt.c | 208 +++-
This series creates an ESSIV template that produces a skcipher or AEAD
transform based on a tuple of the form ',,'
(or ',,' for the AEAD case). It exposes the
encapsulated sync or async skcipher/aead by passing through all operations,
while using the cipher/shash pair to transform the input IV into
dm-log-writes records the sequence of completion, not submission, thus
for the following sequence (W=write, C=complete):
Wa,Wb,Wc,Cc,Ca,FLUSH,FUAd,Cb,CFLUSH,CFUAd
The logged results in log device should be:
c,a,b,flush,fua
Fix the comment to give a better example.
Signed-off-by: Qu Wenruo
