On Thu, Jul 04, 2019 at 08:11:46PM +0200, Ard Biesheuvel wrote:
>
> To be clear, making the cipher API internal only is something that I
> am proposing but hasn't been widely discussed yet. So if you make a
> good argument why it is a terrible idea, I'm sure it will be taken
> into account.
>
>
Add an accelerated version of the 'essiv(cbc(aes),aes,sha256'
skcipher, which is used by fscrypt or dm-crypt on systems where
CBC mode is signficantly more performant than XTS mode (e.g., when
using a h/w accelerator which supports the former but not the latter)
This avoids a separate call into
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.
Reviewed-by: Milan Broz
Signed-off-by: Ard Biesheuvel
---
drivers/md/Kconfig| 1 +
drivers/md/dm-crypt.c |
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
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
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 |
The plain CBC driver and the CTS one share some code that iterates over
a scatterwalk and invokes the CBC asm code to do the processing. The
upcoming ESSIV/CBC mode will clone that pattern for the third time, so
let's factor it out first.
Signed-off-by: Ard Biesheuvel
---
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
Add a test vector for the ESSIV mode that is the most widely used,
i.e., using cbc(aes) and sha256, in both skcipher and AEAD modes
(the latter is used by tcrypt to encapsulate the authenc template
or h/w instantiations of the same)
Signed-off-by: Ard Biesheuvel
---
crypto/tcrypt.c | 9 +
On Thu, 4 Jul 2019 at 19:45, Milan Broz wrote:
>
> On 04/07/2019 16:30, Ard Biesheuvel wrote:
> > On Thu, 4 Jul 2019 at 16:28, Ard Biesheuvel
> > wrote:
> >>
> >> (+ Eric)
> >>
> >> On Thu, 4 Jul 2019 at 15:29, Milan Broz wrote:
> >>>
> >>> Hi Herbert,
> >>>
> >>> I have a question about the
On 04/07/2019 16:30, Ard Biesheuvel wrote:
> On Thu, 4 Jul 2019 at 16:28, Ard Biesheuvel wrote:
>>
>> (+ Eric)
>>
>> On Thu, 4 Jul 2019 at 15:29, Milan Broz wrote:
>>>
>>> Hi Herbert,
>>>
>>> I have a question about the crypto_cipher API in dm-crypt:
>>>
>>> We are apparently trying to deprecate
On Thu, 4 Jul 2019 at 16:28, Ard Biesheuvel wrote:
>
> (+ Eric)
>
> On Thu, 4 Jul 2019 at 15:29, Milan Broz wrote:
> >
> > Hi Herbert,
> >
> > I have a question about the crypto_cipher API in dm-crypt:
> >
> > We are apparently trying to deprecate cryto_cipher API (see the ESSIV
> > patchset),
(+ Eric)
On Thu, 4 Jul 2019 at 15:29, Milan Broz wrote:
>
> Hi Herbert,
>
> I have a question about the crypto_cipher API in dm-crypt:
>
> We are apparently trying to deprecate cryto_cipher API (see the ESSIV
> patchset),
> but I am not sure what API now should be used instead.
>
Not precisely
Hi Herbert,
I have a question about the crypto_cipher API in dm-crypt:
We are apparently trying to deprecate cryto_cipher API (see the ESSIV patchset),
but I am not sure what API now should be used instead.
See the patch below - all we need is to one block encryption for IV.
This algorithm
If a private IV wipe function fails, the code does not set the key
invalid flag. This patch moves code after the flag is set and
prevents the device resume in an inconsistent state.
Also, it allows using of a randomized key in private wipe function
(to be used later patches).
Signed-off-by:
The URL is no longer valid and the comment is obsolete anyway
(the plumb IV was never used).
Signed-off-by: Milan Broz
---
drivers/md/dm-crypt.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index c6d41a7e89c9..96ead4492787 100644
---
This IV is used in some BitLocker devices with CBC encryption mode.
NOTE: maybe we need to use another crypto API if the bare cipher
API is going to be deprecated.
Signed-off-by: Milan Broz
---
drivers/md/dm-crypt.c | 82 ++-
1 file changed, 81
Hi Mike,
Thanks for reviewing, see comments inlined.
On 7/3/19 9:21 AM, Mike Snitzer wrote:
On Tue, Jul 02 2019 at 7:14pm -0400,
Junxiao Bi wrote:
The following deadlock was caputred on 4.1, since dm_bufio_shrink_count
still had bufio lock acquired, this was already fixed by mainline. But
18 matches
Mail list logo
