On Thu, Jun 20, 2019 at 09:13:25AM +0800, Herbert Xu wrote:
> On Wed, Jun 19, 2019 at 06:04:17PM -0700, Eric Biggers wrote:
> >
> > > +#define ESSIV_IV_SIZEsizeof(u64) // IV size of the outer
> > > algo
> > > +#define MAX_INNER_IV_SIZE16 // max IV size of inner
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
>
> Why does the outer algorithm declare a smaller IV size? Should
On Wed, Jun 19, 2019 at 06:29:16PM +0200, Ard Biesheuvel wrote:
> diff --git a/crypto/essiv.c b/crypto/essiv.c
> new file mode 100644
> index ..45e9d10b8614
> --- /dev/null
> +++ b/crypto/essiv.c
> @@ -0,0 +1,630 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * ESSIV skcipher templ
On Wed, Jun 19, 2019 at 06:29:17PM +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.
>
> Signed-off-by: Ard Biesheuvel
> ---
> fs/crypto/Kconfig | 1 +
> fs/crypto/crypto.c
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.
> > This avoids a separate call into the
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.
> This avoids a separate call into the AES cipher for every invocation.
>
> Signed-off-by: Ard Bies
The verification is to support cases where the roothash is not secured by
Trusted Boot, UEFI Secureboot or similar technologies.
One of the use cases for this is for dm-verity volumes mounted after boot,
the root hash provided during the creation of the dm-verity volume has to
be secure and thus in
This patch set adds in-kernel pkcs7 signature checking for the roothash of
the dm-verity hash tree.
The verification is to support cases where the roothash is not secured by
Trusted Boot, UEFI Secureboot or similar technologies.
One of the use cases for this is for dm-verity volumes mounted after b
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 +++-
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
arc
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
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 fscrypt and dm-crypt and move
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 fscrypt and dm-crypt and move it into the crypto API. This will result
> in better test coverage,
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
> > > >> cryptsetup open --type plain -c null /dev/sdd test
On 19/06/2019 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
> cryptsetup open --type plain -c null /dev/sdd test -q
> or
> dms
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
> > >> dmsetup create test --table " 0 417792 crypt ciph
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 - 0
> >> /dev/sdd 0"
> >>
> >> (or just run full cryptse
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 - 0 /dev/sdd
>> 0"
>>
>> (or just run full cryptsetup testsuite)
>>
>
> Is that your mode-test script?
>
> I saw so
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
> > index 029a65afb4d7..5dc2e592077e 1
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
> index 029a65afb4d7..5dc2e592077e 100644
> --- a/crypto/essiv.c
> +++ b/crypto/essiv.c
> @@ -243,6
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
> > > transform based on a tuple of the form ',,'
> > > (or ',,'
Since dm-log-writes will record all writes, include data and metadata
writes, it can consume a lot of space.
However for a lot of filesystems, the data bio (without METADATA flag)
can be skipped for certain use case, thus we can skip them in
dm-log-writes to hugely reduce space usage.
This patch w
The new message format is:
dump_type=
The parameter of dump_type= follows the same one of constructor.
This allows us to change dump_type on the fly, making the following use
case possible:
# dmsetup create log --table 0 10485760 log-writes \
/dev/tests/dest /dev/test/log dump_type=ALL
# m
Current dm-log-writes will record all bios, no matter if the bios is
METADATA (normally what we care) or is DATA (normally we cares less for
the log-replay context).
This causes a lot of extra space required for log device. E.g write 10M,
sync, overwrite that 10M file, this would cause over 20M fo
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
> > encapsulated sync or async s
29 matches
Mail list logo
