On 18 July 2017 at 09:39, Herbert Xu <herb...@gondor.apana.org.au> wrote:
> On Mon, Jul 10, 2017 at 02:45:48PM +0100, Ard Biesheuvel wrote:
>> There are quite a number of occurrences in the kernel of the pattern
>>
>> if (dst != src)
>> memcpy(dst,
called crypto_xor_cpy(),
taking separate input and output arguments. This removes the need for
the separate memcpy().
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
---
arch/arm/crypto/aes-ce-glue.c | 4 +---
arch/arm/crypto/aes-neonbs-glue.c | 5 ++---
arch/arm64/cryp
rrences of crypto_xor() involving a memcpy() to
use a new API function crypto_xor_cpy() which combines the two operations.
v2: - keep existing crypto_xor() as-is, and add crypto_xor_cpy() for the
cases where a redundant memcpy() can be eliminated.
Ard Biesheuvel (2):
crypto/algapi -
In preparation of introducing crypto_xor_cpy(), which will use separate
operands for input and output, modify the __crypto_xor() implementation,
which it will share with the existing crypto_xor(), which provides the
actual functionality when not using the inline version.
Signed-off-by: Ard
and first input operands in crypto_xor().
While we're at it, fold in the memcpy()s that can now be made redundant.
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
---
arch/arm/crypto/aes-ce-glue.c | 4 +---
arch/arm/crypto/aes-neonbs-glue.c | 9 +++--
arch/arm64/crypto/aes-
ccurrences of crypto_xor() to use a separate
output argument.
Ard Biesheuvel (2):
crypto/algapi - use separate dst and src operands for __crypto_xor()
crypto/algapi - make crypto_xor() take separate dst and src arguments
arch/arm/crypto/aes-ce-glue.c | 4 +---
arch/arm/crypto/aes-neonbs-
In preparation of updating crypto_xor() [which is what the crypto API
exposes to other subsystems] to use separate operands for input and
output, first modify the __crypto_xor() implementation that provides
the actual functionality when not using the inline version.
Signed-off-by: Ard Biesheuvel
> On 19 Jul 2018, at 12:09, Kees Cook wrote:
>
> On Wed, Jul 18, 2018 at 7:55 PM, Ard Biesheuvel
> wrote:
>> I have only build tested it, so if you make sure that it does not break
>> anything, please go ahead.
>
> I can give it a spin; what's the best w
> On 19 Jul 2018, at 11:51, Kees Cook wrote:
>
> On Wed, Jul 18, 2018 at 8:19 AM, Ard Biesheuvel
> wrote:
>> On 18 July 2018 at 23:50, Ard Biesheuvel wrote:
>>>> On 18 July 2018 at 05:59, Arnd Bergmann wrote:
>>>>> On Sun, Jul 15, 2018 at 6:2
On 20 July 2018 at 00:50, Mark Brown wrote:
> On Thu, Jul 19, 2018 at 11:08:52PM +0900, Ard Biesheuvel wrote:
>
>> But this will only be the case if the accelerator is capable of doing
>> the IV generation and en/decryption of multiple contiguous sectors in
>> a sin
On 20 July 2018 at 20:45, Mark Brown wrote:
> On Fri, Jul 20, 2018 at 10:02:21AM +0900, Ard Biesheuvel wrote:
>> On 20 July 2018 at 00:50, Mark Brown wrote:
>
>> > Existing hardware can definitely do the IV generation and I believe that
>> > it can chain multiple se
On 18 July 2018 at 05:59, Arnd Bergmann wrote:
> On Sun, Jul 15, 2018 at 6:28 AM, Kees Cook wrote:
>>
>> After my ahash to shash conversions, only ccm is left as an ahash
>> user, since it actually uses sg. But with the hard-coded value reduced
>> to 376, this doesn't trip the frame warnings any
On 18 July 2018 at 23:50, Ard Biesheuvel wrote:
> On 18 July 2018 at 05:59, Arnd Bergmann wrote:
>> On Sun, Jul 15, 2018 at 6:28 AM, Kees Cook wrote:
>>>
>>> After my ahash to shash conversions, only ccm is left as an ahash
>>> user, since it actually us
On 19 July 2018 at 00:33, Arnd Bergmann wrote:
> On Wed, Jul 18, 2018 at 5:19 PM, Ard Biesheuvel
> wrote:
>> On 18 July 2018 at 23:50, Ard Biesheuvel wrote:
>>> On 18 July 2018 at 05:59, Arnd Bergmann wrote:
>>>> On Sun, Jul 15, 2018 at 6:28 AM, Kees Cook
On 18 July 2018 at 19:59, Arnd Bergmann wrote:
> On Wed, Jul 18, 2018 at 9:30 AM, Xiongfeng Wang
> wrote:
>>
>> I tested the performance of software implemented ciphers before and after
>> applying this patchset. The performance didn't change much except for
>> slight regression when writting.
On 22 July 2018 at 22:39, Gilad Ben-Yossef wrote:
> Hi there,
>
> Sorry for delay in response - the patch set was sent just as we shut
> down the office for moving to a new location... :-)
>
> On Fri, Jul 20, 2018 at 2:45 PM, Mark Brown wrote:
>> On Fri, Jul 20, 2018
On 19 July 2018 at 19:55, Xiongfeng Wang wrote:
> Hi,
>
> On 2018/7/18 23:34, Ard Biesheuvel wrote:
>> On 18 July 2018 at 19:59, Arnd Bergmann wrote:
>>> On Wed, Jul 18, 2018 at 9:30 AM, Xiongfeng Wang
>>> wrote:
>>>>
>>>> I test
On 19 July 2018 at 12:13, Ard Biesheuvel wrote:
>
>> On 19 Jul 2018, at 12:09, Kees Cook wrote:
>>
>> On Wed, Jul 18, 2018 at 7:55 PM, Ard Biesheuvel
>> wrote:
>>> I have only build tested it, so if you make sure that it does not break
>>> anything
On 24 July 2018 at 18:49, Kees Cook wrote:
> From: Ard Biesheuvel
>
> In the quest to remove all stack VLA usage from the kernel[1], this
> drops AHASH_REQUEST_ON_STACK by preallocated the ahash request area
> with the skcipher area (which are not used at the same time).
>
On 21 September 2018 at 07:45, Herbert Xu wrote:
> On Thu, Sep 13, 2018 at 10:51:30AM +0200, Ondrej Mosnacek wrote:
>> This patchset contains a corner-case fix and several improvements for
>> the LRW template.
>>
>> The first patch fixes an out-of-bounds array access (and subsequently
>>
On Tue, 25 Sep 2018 at 18:12, Arnd Bergmann wrote:
>
> On Tue, Aug 7, 2018 at 11:18 PM Kees Cook wrote:
> >
> > In the quest to remove all stack VLA usage from the kernel[1], this uses
> > the new upper bound for the stack buffer. Also adds a sanity check.
> >
> > [1]
> >
On Wed, 26 Sep 2018 at 10:54, Arnd Bergmann wrote:
>
> On Wed, Sep 26, 2018 at 10:44 AM Ard Biesheuvel
> wrote:
> >
> > On Tue, 25 Sep 2018 at 18:12, Arnd Bergmann wrote:
> > >
> > > On Tue, Aug 7, 2018 at 11:18 PM Kees Cook wrote:
> > > >
ready found the similar message in fs/crypto/keyinfo.c to be
> very useful.
>
> Signed-off-by: Eric Biggers
Acked-by: Ard Biesheuvel
> ---
> drivers/md/dm-crypt.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
er: verity: sha256 using implementation "sha256-ce"
>
> We've already found the similar message in fs/crypto/keyinfo.c to be
> very useful.
>
> Signed-off-by: Eric Biggers
Acked-by: Ard Biesheuvel
> ---
> drivers/md/dm-verity-target.c | 9 +
> 1 file changed,
On Sat, 15 Jun 2019 at 20:19, Milan Broz wrote:
>
> On 14/06/2019 10:34, Ard Biesheuvel wrote:
> > This series is presented as an RFC for a couple of reasons:
> > - it is only build tested
> > - it is unclear whether this is the right way to move away from the use of
&
On Mon, 17 Jun 2019 at 12:58, Ard Biesheuvel wrote:
>
> On Mon, 17 Jun 2019 at 12:39, Milan Broz wrote:
> >
> > On 17/06/2019 11:15, Ard Biesheuvel wrote:
> > >> I will also add that going the skcipher route rather than shash will
> > >> allow hardware
On Mon, 17 Jun 2019 at 16:35, Milan Broz wrote:
>
> On 17/06/2019 15:59, Ard Biesheuvel wrote:
> >
> > So my main question/showstopper at the moment is: which modes do we
> > need to support for ESSIV? Only CBC? Any skcipher? Or both skciphers
> > and AEADs?
>
>
On Mon, 17 Jun 2019 at 12:39, Milan Broz wrote:
>
> On 17/06/2019 11:15, Ard Biesheuvel wrote:
> >> I will also add that going the skcipher route rather than shash will
> >> allow hardware tfm providers like CryptoCell that can do the ESSIV
> >> part in hardwa
-crypt case. I also tested the aead case in a virtual machine,
but it definitely needs some wider testing from the dm-crypt experts.
Cc: Herbert Xu
Cc: Eric Biggers
Cc: dm-devel@redhat.com
Cc: linux-fscr...@vger.kernel.org
Cc: Gilad Ben-Yossef
Cc: Milan Broz
Ard Biesheuvel (4):
crypto: essiv
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
internal to the crypto subsystem, in order to increase
robustness of the API against misuse.
Note that especially the AEAD handling is a bit complex, and is tightly
coupled to the way dm-crypt combines AEAD based on the authenc() template
with the ESSIV handling.
Signed-off-by: Ard Biesheuvel
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 string allows us to use it in the
allocation, which is something we will need when switching to the
'essiv' crypto API template.
Signed-off-by: Ard Biesheuvel
---
drivers/md/dm-crypt.c | 35 +---
1 file changed, 15 insertions(+), 20 deletions(-)
diff --git a/drivers/md/dm
On Wed, 19 Jun 2019 at 08:56, Milan Broz wrote:
>
> 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
> &
On Mon, 17 Jun 2019 at 19:05, Milan Broz wrote:
>
> On 17/06/2019 16:39, Ard Biesheuvel wrote:
> >>
> >> In other words, if you add some additional limit, we are breaking backward
> >> compatibility.
> >> (Despite the configuration is "wrong"
On Wed, 19 Jun 2019 at 13:01, Milan Broz wrote:
>
> On 19/06/2019 11:14, Ard Biesheuvel wrote:
> > Apologies, this was a rebase error on my part.
> >
> > Could you please apply the hunk below and try again?
> >
> > diff --git a/crypto/essiv.c b/crypto/essiv.c
Add a test vector for the ESSIV mode that is the most widely used,
i.e., using cbc(aes) and sha256.
Signed-off-by: Ard Biesheuvel
---
crypto/tcrypt.c | 9 +
crypto/testmgr.c | 6 +
crypto/testmgr.h | 208
3 files changed, 223 insertions(+)
diff --git a/crypto/tcrypt.c
Add an accelerated version of the 'essiv(cbc(aes),aes,sha256)'
skcipher, which is used by fscrypt, and in some cases, by dm-crypt.
This avoids a separate call into the AES cipher for every invocation.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/aes-glue.c | 129
internal to the crypto subsystem, in order to increase
robustness of the API against misuse.
Signed-off-by: Ard Biesheuvel
---
crypto/Kconfig | 4 +
crypto/Makefile | 1 +
crypto/essiv.c | 630
3 files changed, 635 insertions(+)
diff --git a/crypto/Kconfig b/crypto
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
Cc: Gilad Ben-Yossef
Cc: Milan Broz
Ard Biesheuvel (6):
crypto: essiv - create wrapper template for ESSIV generation
fs: crypto: invoke crypto API for ESSIV handling
md: dm-crypt: infer ESSIV block cipher from cipher string directly
md: dm-crypt: switch to ESSIV crypto API template
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 string allows us to use it in the
allocation, which is something we will need when switching to the
'essiv' crypto API template.
Signed-off-by: Ard Biesheuvel
---
drivers/md/dm-crypt.c | 35 +---
1 file changed, 15 insertions(+), 20 deletions(-)
diff --git a/drivers/md/dm
On Wed, 19 Jun 2019 at 17:18, Ondrej Mosnáček wrote:
>
> Hi Ard,
>
> ut 18. 6. 2019 o 23:28 Ard Biesheuvel napísal(a):
> > Implement a template that wraps a (skcipher,cipher,shash) or
> > (aead,cipher,shash) tuple so that we can consolidate the ESSIV handling
> > in
On Wed, 19 Jun 2019 at 13:33, Milan Broz wrote:
>
> On 19/06/2019 13:16, Ard Biesheuvel wrote:
> >> Try
> >> cryptsetup open --type plain -c null /dev/sdd test -q
> >> or
> >> dmsetup create test --table " 0 417792 crypt cipher_null-ecb -
On Wed, 19 Jun 2019 at 14:36, Ard Biesheuvel wrote:
>
> On Wed, 19 Jun 2019 at 13:33, Milan Broz wrote:
> >
> > On 19/06/2019 13:16, Ard Biesheuvel wrote:
> > >> Try
> > >> cryptsetup open --type plain -c null /dev/sdd test -q
> > >> or
On Wed, 19 Jun 2019 at 14:49, Ard Biesheuvel wrote:
>
> On Wed, 19 Jun 2019 at 14:36, Ard Biesheuvel
> wrote:
> >
> > On Wed, 19 Jun 2019 at 13:33, Milan Broz wrote:
> > >
> > > On 19/06/2019 13:16, Ard Biesheuvel wrote:
> > > >> Try
&g
On Thu, 20 Jun 2019 at 00:37, Eric Biggers wrote:
>
> On Wed, Jun 19, 2019 at 06:29:21PM +0200, Ard Biesheuvel wrote:
> > Add an accelerated version of the 'essiv(cbc(aes),aes,sha256)'
> > skcipher, which is used by fscrypt, and in some cases, by dm-crypt.
> > Thi
On Thu, 20 Jun 2019 at 03:14, Herbert Xu wrote:
>
> On Wed, Jun 19, 2019 at 06:04:17PM -0700, Eric Biggers wrote:
> >
> > > +#define ESSIV_IV_SIZE sizeof(u64) // IV size of the
> > > outer algo
> > > +#define MAX_INNER_IV_SIZE 16 // max IV size of inner algo
> >
>
On Thu, 20 Jun 2019 at 13:22, Milan Broz wrote:
>
> On 19/06/2019 18:29, 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
> &
On Thu, 20 Jun 2019 at 14:53, Herbert Xu wrote:
>
> On Thu, Jun 20, 2019 at 09:30:41AM +0200, Ard Biesheuvel wrote:
> >
> > Is this the right approach? Or are there better ways to convey this
> > information when instantiating the template?
> > Also, it seems to me
On Thu, 20 Jun 2019 at 15:02, Ard Biesheuvel wrote:
>
> On Thu, 20 Jun 2019 at 14:53, Herbert Xu wrote:
> >
> > On Thu, Jun 20, 2019 at 09:30:41AM +0200, Ard Biesheuvel wrote:
> > >
> > > Is this the right approach? Or are there better ways to convey this
On Wed, 19 Jun 2019 at 09:11, Ard Biesheuvel wrote:
>
> On Wed, 19 Jun 2019 at 08:56, Milan Broz wrote:
> >
> > On 18/06/2019 23:27, Ard Biesheuvel wrote:
> > > This series creates an ESSIV template that produces a skcipher or AEAD
> > > tr
On Fri, 21 Jun 2019 at 03:07, Herbert Xu wrote:
>
> On Thu, Jun 20, 2019 at 03:53:45PM +0200, Ard Biesheuvel wrote:
> >
> > We'd need at least 512 and 4k for dm-crypt, but I don't think the
> > sector size is limited at all tbh
>
> In that case my preference would
On Fri, 21 Jun 2019 at 09:01, Milan Broz wrote:
>
> On 20/06/2019 15:52, Ard Biesheuvel wrote:
> >>>> Does this include configurations that combine authenc with essiv?
> >>>
> >>> Hm, seems that we are missing these in luks2-integrity-test. I'll a
On Fri, 21 Jun 2019 at 09:06, Ard Biesheuvel wrote:
>
> On Fri, 21 Jun 2019 at 09:01, Milan Broz wrote:
> >
> > On 20/06/2019 15:52, Ard Biesheuvel wrote:
> > >>>> Does this include configurations that combine authenc with essiv?
> > >>>
&
From: Ard Biesheuvel
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
From: Ard Biesheuvel
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
From: 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
From: Ard Biesheuvel
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
From: Ard Biesheuvel
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
From: Ard Biesheuvel
Add a test vector for the ESSIV mode that is the most widely used,
i.e., using cbc(aes) and sha256.
Signed-off-by: Ard Biesheuvel
---
crypto/tcrypt.c | 9 +
crypto/testmgr.c | 6 +
crypto/testmgr.h | 208
3 files changed, 223 insertions(+)
diff
On Thu, 20 Jun 2019 at 15:40, Herbert Xu wrote:
>
> On Thu, Jun 20, 2019 at 03:02:04PM +0200, Ard Biesheuvel wrote:
> >
> > It also depend on how realistic it is that we will need to support
> > arbitrary sector sizes in the future. I mean, if we decide today that
>
On Thu, 20 Jun 2019 at 15:14, Milan Broz wrote:
>
> On 20/06/2019 14:09, Milan Broz wrote:
> > On 20/06/2019 13:54, Ard Biesheuvel wrote:
> >> On Thu, 20 Jun 2019 at 13:22, Milan Broz wrote:
> >>>
> >>> On 19/06/2019 18:29, Ard Biesheuvel wrote:
On Fri, 21 Jun 2019 at 10:09, Ard Biesheuvel wrote:
>
> From: Ard Biesheuvel
>
...
>
> - given that hardware already exists that can perform en/decryption including
> ESSIV generation of a range of blocks, it would be useful to encapsulate
> this in the ESSIV template,
On Mon, 17 Jun 2019 at 11:20, Herbert Xu wrote:
>
> On Mon, Jun 17, 2019 at 11:15:01AM +0200, Ard Biesheuvel wrote:
> >
> > Ah yes, thanks for reminding me. There was some debate in the past
> > about this, but I don't remember the details.
>
> I think there w
On Mon, 17 Jun 2019 at 10:52, Gilad Ben-Yossef wrote:
>
> On Sun, Jun 16, 2019 at 11:44 PM Eric Biggers wrote:
> >
> > [+Cc dm-devel and linux-fscrypt]
> >
> > On Fri, Jun 14, 2019 at 10:34:01AM +0200, Ard Biesheuvel wrote:
> > > This series is pres
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
into the AES cipher for every invocation.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/aes-glue.c | 123
arch/arm64/crypto/aes-modes.S | 29 -
2 files changed, 151 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/crypto/aes-glue.c b/arch/arm64/crypto/aes-glue.c
the string allows us to use it in the
allocation, which is something we will need when switching to the
'essiv' crypto API template.
Reviewed-by: Milan Broz
Signed-off-by: Ard Biesheuvel
---
drivers/md/dm-crypt.c | 41 +---
1 file changed, 18 insertions(+), 23 deletions(-)
diff
internal to the crypto subsystem, in order to increase
robustness of the API against misuse.
Signed-off-by: Ard Biesheuvel
---
crypto/Kconfig | 28 +
crypto/Makefile | 1 +
crypto/essiv.c | 640
3 files changed, 669 insertions(+)
diff --git a/crypto/Kconfig b/crypto
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
---
arch/arm64/crypto/aes
Xu
Cc: Eric Biggers
Cc: dm-devel@redhat.com
Cc: linux-fscr...@vger.kernel.org
Cc: Gilad Ben-Yossef
Cc: Milan Broz
Ard Biesheuvel (7):
crypto: essiv - create wrapper template for ESSIV generation
fs: crypto: invoke crypto API for ESSIV handling
md: dm-crypt: infer ESSIV block cipher from
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
(+ 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
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:
>
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 depreca
On Thu, 4 Jul 2019 at 20:30, 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
On Fri, 5 Jul 2019 at 05:08, Herbert Xu wrote:
>
> 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
Add a test vector for the ESSIV mode that is the most widely used,
i.e., using cbc(aes) and sha256.
Signed-off-by: Ard Biesheuvel
---
crypto/tcrypt.c | 9 +
crypto/testmgr.c | 6 +
crypto/testmgr.h | 213
3 files changed, 228 insertions(+)
diff --git a/crypto/tcrypt.c
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
---
arch/arm64/crypto/aes
Cortex-A57 (AMD Seattle)
Code can be found here
https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=essiv-v5
Cc: Herbert Xu
Cc: Eric Biggers
Cc: dm-devel@redhat.com
Cc: linux-fscr...@vger.kernel.org
Cc: Gilad Ben-Yossef
Cc: Milan Broz
Ard Biesheuvel (7):
crypto: essiv
internal to the crypto subsystem, in order to increase
robustness of the API against misuse.
Signed-off-by: Ard Biesheuvel
---
crypto/Kconfig | 4 +
crypto/Makefile | 1 +
crypto/essiv.c | 636
3 files changed, 641 insertions(+)
diff --git a/crypto/Kconfig b/crypto
Add an accelerated version of the 'essiv(cbc(aes),aes,sha256'
skcipher, which is used by fscrypt, and in some cases, by dm-crypt.
This avoids a separate call into the AES cipher for every invocation.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/aes-glue.c | 123
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 | 200
the string allows us to use it in the
allocation, which is something we will need when switching to the
'essiv' crypto API template.
Signed-off-by: Ard Biesheuvel
---
drivers/md/dm-crypt.c | 35 +---
1 file changed, 15 insertions(+), 20 deletions(-)
diff --git a/drivers/md/dm
On Wed, 3 Jul 2019 at 00:06, Ard Biesheuvel wrote:
>
> On Tue, 2 Jul 2019 at 23:55, Eric Biggers wrote:
> >
> > Hi Ard,
> >
> > On Tue, Jul 02, 2019 at 06:48:10PM +0200, Ard Biesheuvel wrote:
> > > Instead of open coding the calculations for ESSIV handling
On Tue, 2 Jul 2019 at 23:55, Eric Biggers wrote:
>
> Hi Ard,
>
> On Tue, Jul 02, 2019 at 06:48:10PM +0200, Ard Biesheuvel wrote:
> > Instead of open coding the calculations for ESSIV handling, use a
> > ESSIV skcipher which does all of this under the hood.
> >
>
On Mon, 1 Jul 2019 at 10:59, Milan Broz wrote:
>
> On 28/06/2019 17:21, Ard Biesheuvel wrote:
> > 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 wit
On Fri, 28 Jun 2019 at 20:00, Eric Biggers wrote:
>
> On Fri, Jun 28, 2019 at 05:21:07PM +0200, Ard Biesheuvel wrote:
> > diff --git a/fs/crypto/keyinfo.c b/fs/crypto/keyinfo.c
> > index dcd91a3fbe49..f39667d4316a 100644
> > --- a/fs/crypto/keyinfo.c
> > +++ b/fs/
On Mon, 1 Jul 2019 at 10:59, Milan Broz wrote:
>
> On 28/06/2019 17:21, Ard Biesheuvel wrote:
> > 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 wit
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
: Herbert Xu
Cc: Eric Biggers
Cc: dm-devel@redhat.com
Cc: linux-fscr...@vger.kernel.org
Cc: Gilad Ben-Yossef
Cc: Milan Broz
Ard Biesheuvel (7):
crypto: essiv - create wrapper template for ESSIV generation
fs: crypto: invoke crypto API for ESSIV handling
md: dm-crypt: infer ESSIV block cipher
the string allows us to use it in the
allocation, which is something we will need when switching to the
'essiv' crypto API template.
Reviewed-by: Milan Broz
Signed-off-by: Ard Biesheuvel
---
drivers/md/dm-crypt.c | 41 +---
1 file changed, 18 insertions(+), 23 deletions(-)
diff
internal to the crypto subsystem, in order to increase
robustness of the API against misuse.
Signed-off-by: Ard Biesheuvel
---
crypto/Kconfig | 28 +
crypto/Makefile | 1 +
crypto/essiv.c | 640
3 files changed, 669 insertions(+)
diff --git a/crypto/Kconfig b/crypto
into the AES cipher for every invocation.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/aes-glue.c | 123
arch/arm64/crypto/aes-modes.S | 29 -
2 files changed, 151 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/crypto/aes-glue.c b/arch/arm64/crypto/aes-glue.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
---
arch/arm64/crypto/aes
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
1 - 100 of 199 matches
Mail list logo
