All of lore.kernel.org
 help / color / mirror / Atom feed
From: Milan Broz <gmazyland@gmail.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
	<linux-crypto@vger.kernel.org>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Eric Biggers <ebiggers@google.com>,
	device-mapper development <dm-devel@redhat.com>,
	linux-fscrypt@vger.kernel.org,
	Gilad Ben-Yossef <gilad@benyossef.com>
Subject: Re: [PATCH v9 3/7] md: dm-crypt: switch to ESSIV crypto API template
Date: Mon, 12 Aug 2019 15:51:07 +0200	[thread overview]
Message-ID: <7b3365a9-42ca-5426-660f-e87898bb9f7a@gmail.com> (raw)
In-Reply-To: <CAKv+Gu_d+3NsTKFZbS+xeuxf5uCz=ENmPX-a=s-2kgLrW4d7cQ@mail.gmail.com>

On 12/08/2019 09:50, Ard Biesheuvel wrote:
> On Mon, 12 Aug 2019 at 10:44, Milan Broz <gmazyland@gmail.com> wrote:
>>
>> On 12/08/2019 08:54, Ard Biesheuvel wrote:
>>> On Mon, 12 Aug 2019 at 09:33, Milan Broz <gmazyland@gmail.com> wrote:
>>>> Try for example
>>>> # cryptsetup luksFormat /dev/sdc -c aes-cbc-essiv:sha256 --integrity hmac-sha256 -q -i1
>>>>
>>>> It should produce Crypto API string
>>>>   authenc(hmac(sha256),essiv(cbc(aes),sha256))
>>>> while it produces
>>>>   essiv(authenc(hmac(sha256),cbc(aes)),sha256)
>>>> (and fails).
>>>>
>>>
>>> No. I don't know why it fails, but the latter is actually the correct
>>> string. The essiv template is instantiated either as a skcipher or as
>>> an aead, and it encapsulates the entire transformation. (This is
>>> necessary considering that the IV is passed via the AAD and so the
>>> ESSIV handling needs to touch that as well)
>>
>> Hm. Constructing these strings seems to be more confusing than dmcrypt mode combinations :-)
>>
>> But you are right, I actually tried the former string (authenc(hmac(sha256),essiv(cbc(aes),sha256)))
>> and it worked, but I guess the authenticated IV (AAD) was actually the input to IV (plain sector number)
>> not the output of ESSIV? Do I understand it correctly now?
>>
> 
> Indeed. The former string instantiates the skcipher version of the
> ESSIV template, and so the AAD handling is omitted, and we end up
> using the plain IV in the authentication rather than the encrypted IV.
> 
> So when using the latter string, does it produce any error messages
> when it fails?

The error is
table: 253:1: crypt: Error decoding and setting key

and it is failing in crypt_setkey() int this  crypto_aead_setkey();

And it is because it now wrongly calculates MAC key length.
(We have two keys here - one for length-preserving CBC-ESSIV encryption
and one for HMAC.)

This super-ugly hotfix helps here... I guess it can be done better :-)

diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index e9a0093c88ee..7b06d975a2e1 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -2342,6 +2342,9 @@ static int crypt_ctr_auth_cipher(struct crypt_config *cc, char *cipher_api)
        char *start, *end, *mac_alg = NULL;
        struct crypto_ahash *mac;
 
+       if (strstarts(cipher_api, "essiv(authenc("))
+               cipher_api += strlen("essiv(");
+
        if (!strstarts(cipher_api, "authenc("))
                return 0;
 
Milan

WARNING: multiple messages have this Message-ID (diff)
From: Milan Broz <gmazyland@gmail.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	Eric Biggers <ebiggers@google.com>,
	linux-fscrypt@vger.kernel.org,
	Gilad Ben-Yossef <gilad@benyossef.com>,
	device-mapper development <dm-devel@redhat.com>,
	"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
	<linux-crypto@vger.kernel.org>
Subject: Re: [dm-devel] [PATCH v9 3/7] md: dm-crypt: switch to ESSIV crypto API template
Date: Mon, 12 Aug 2019 15:51:07 +0200	[thread overview]
Message-ID: <7b3365a9-42ca-5426-660f-e87898bb9f7a@gmail.com> (raw)
In-Reply-To: <CAKv+Gu_d+3NsTKFZbS+xeuxf5uCz=ENmPX-a=s-2kgLrW4d7cQ@mail.gmail.com>

On 12/08/2019 09:50, Ard Biesheuvel wrote:
> On Mon, 12 Aug 2019 at 10:44, Milan Broz <gmazyland@gmail.com> wrote:
>>
>> On 12/08/2019 08:54, Ard Biesheuvel wrote:
>>> On Mon, 12 Aug 2019 at 09:33, Milan Broz <gmazyland@gmail.com> wrote:
>>>> Try for example
>>>> # cryptsetup luksFormat /dev/sdc -c aes-cbc-essiv:sha256 --integrity hmac-sha256 -q -i1
>>>>
>>>> It should produce Crypto API string
>>>>   authenc(hmac(sha256),essiv(cbc(aes),sha256))
>>>> while it produces
>>>>   essiv(authenc(hmac(sha256),cbc(aes)),sha256)
>>>> (and fails).
>>>>
>>>
>>> No. I don't know why it fails, but the latter is actually the correct
>>> string. The essiv template is instantiated either as a skcipher or as
>>> an aead, and it encapsulates the entire transformation. (This is
>>> necessary considering that the IV is passed via the AAD and so the
>>> ESSIV handling needs to touch that as well)
>>
>> Hm. Constructing these strings seems to be more confusing than dmcrypt mode combinations :-)
>>
>> But you are right, I actually tried the former string (authenc(hmac(sha256),essiv(cbc(aes),sha256)))
>> and it worked, but I guess the authenticated IV (AAD) was actually the input to IV (plain sector number)
>> not the output of ESSIV? Do I understand it correctly now?
>>
> 
> Indeed. The former string instantiates the skcipher version of the
> ESSIV template, and so the AAD handling is omitted, and we end up
> using the plain IV in the authentication rather than the encrypted IV.
> 
> So when using the latter string, does it produce any error messages
> when it fails?

The error is
table: 253:1: crypt: Error decoding and setting key

and it is failing in crypt_setkey() int this  crypto_aead_setkey();

And it is because it now wrongly calculates MAC key length.
(We have two keys here - one for length-preserving CBC-ESSIV encryption
and one for HMAC.)

This super-ugly hotfix helps here... I guess it can be done better :-)

diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index e9a0093c88ee..7b06d975a2e1 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -2342,6 +2342,9 @@ static int crypt_ctr_auth_cipher(struct crypt_config *cc, char *cipher_api)
        char *start, *end, *mac_alg = NULL;
        struct crypto_ahash *mac;
 
+       if (strstarts(cipher_api, "essiv(authenc("))
+               cipher_api += strlen("essiv(");
+
        if (!strstarts(cipher_api, "authenc("))
                return 0;
 
Milan

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

WARNING: multiple messages have this Message-ID (diff)
From: Milan Broz <gmazyland@gmail.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	Eric Biggers <ebiggers@google.com>,
	linux-fscrypt@vger.kernel.org,
	Gilad Ben-Yossef <gilad@benyossef.com>,
	device-mapper development <dm-devel@redhat.com>,
	"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
	<linux-crypto@vger.kernel.org>
Subject: Re: [PATCH v9 3/7] md: dm-crypt: switch to ESSIV crypto API template
Date: Mon, 12 Aug 2019 15:51:07 +0200	[thread overview]
Message-ID: <7b3365a9-42ca-5426-660f-e87898bb9f7a@gmail.com> (raw)
In-Reply-To: <CAKv+Gu_d+3NsTKFZbS+xeuxf5uCz=ENmPX-a=s-2kgLrW4d7cQ@mail.gmail.com>

On 12/08/2019 09:50, Ard Biesheuvel wrote:
> On Mon, 12 Aug 2019 at 10:44, Milan Broz <gmazyland@gmail.com> wrote:
>>
>> On 12/08/2019 08:54, Ard Biesheuvel wrote:
>>> On Mon, 12 Aug 2019 at 09:33, Milan Broz <gmazyland@gmail.com> wrote:
>>>> Try for example
>>>> # cryptsetup luksFormat /dev/sdc -c aes-cbc-essiv:sha256 --integrity hmac-sha256 -q -i1
>>>>
>>>> It should produce Crypto API string
>>>>   authenc(hmac(sha256),essiv(cbc(aes),sha256))
>>>> while it produces
>>>>   essiv(authenc(hmac(sha256),cbc(aes)),sha256)
>>>> (and fails).
>>>>
>>>
>>> No. I don't know why it fails, but the latter is actually the correct
>>> string. The essiv template is instantiated either as a skcipher or as
>>> an aead, and it encapsulates the entire transformation. (This is
>>> necessary considering that the IV is passed via the AAD and so the
>>> ESSIV handling needs to touch that as well)
>>
>> Hm. Constructing these strings seems to be more confusing than dmcrypt mode combinations :-)
>>
>> But you are right, I actually tried the former string (authenc(hmac(sha256),essiv(cbc(aes),sha256)))
>> and it worked, but I guess the authenticated IV (AAD) was actually the input to IV (plain sector number)
>> not the output of ESSIV? Do I understand it correctly now?
>>
> 
> Indeed. The former string instantiates the skcipher version of the
> ESSIV template, and so the AAD handling is omitted, and we end up
> using the plain IV in the authentication rather than the encrypted IV.
> 
> So when using the latter string, does it produce any error messages
> when it fails?

The error is
table: 253:1: crypt: Error decoding and setting key

and it is failing in crypt_setkey() int this  crypto_aead_setkey();

And it is because it now wrongly calculates MAC key length.
(We have two keys here - one for length-preserving CBC-ESSIV encryption
and one for HMAC.)

This super-ugly hotfix helps here... I guess it can be done better :-)

diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index e9a0093c88ee..7b06d975a2e1 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -2342,6 +2342,9 @@ static int crypt_ctr_auth_cipher(struct crypt_config *cc, char *cipher_api)
        char *start, *end, *mac_alg = NULL;
        struct crypto_ahash *mac;
 
+       if (strstarts(cipher_api, "essiv(authenc("))
+               cipher_api += strlen("essiv(");
+
        if (!strstarts(cipher_api, "authenc("))
                return 0;
 
Milan

  reply	other threads:[~2019-08-12 13:51 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-10  9:40 [PATCH v9 0/7] crypto: switch to crypto API for ESSIV generation Ard Biesheuvel
2019-08-10  9:40 ` Ard Biesheuvel
2019-08-10  9:40 ` [PATCH v9 1/7] crypto: essiv - create wrapper template " Ard Biesheuvel
2019-08-10  9:40   ` Ard Biesheuvel
2019-08-10  9:40 ` [PATCH v9 2/7] fs: crypto: invoke crypto API for ESSIV handling Ard Biesheuvel
2019-08-10  9:40   ` Ard Biesheuvel
2019-08-10  9:40 ` [PATCH v9 3/7] md: dm-crypt: switch to ESSIV crypto API template Ard Biesheuvel
2019-08-10  9:40   ` Ard Biesheuvel
2019-08-12  6:33   ` Milan Broz
2019-08-12  6:33     ` Milan Broz
2019-08-12  6:33     ` [dm-devel] " Milan Broz
2019-08-12  6:54     ` Ard Biesheuvel
2019-08-12  6:54       ` Ard Biesheuvel
2019-08-12  6:54       ` [dm-devel] " Ard Biesheuvel
2019-08-12  7:44       ` Milan Broz
2019-08-12  7:44         ` Milan Broz
2019-08-12  7:44         ` Milan Broz
2019-08-12  7:50         ` Ard Biesheuvel
2019-08-12  7:50           ` Ard Biesheuvel
2019-08-12  7:50           ` [dm-devel] " Ard Biesheuvel
2019-08-12 13:51           ` Milan Broz [this message]
2019-08-12 13:51             ` Milan Broz
2019-08-12 13:51             ` [dm-devel] " Milan Broz
2019-08-12 14:19             ` Ard Biesheuvel
2019-08-12 14:19               ` Ard Biesheuvel
2019-08-12 14:19               ` [dm-devel] " Ard Biesheuvel
2019-08-10  9:40 ` [PATCH v9 4/7] crypto: essiv - add tests for essiv in cbc(aes)+sha256 mode Ard Biesheuvel
2019-08-10  9:40   ` Ard Biesheuvel
2019-08-10  9:40 ` [PATCH v9 5/7] crypto: arm64/aes-cts-cbc - factor out CBC en/decryption of a walk Ard Biesheuvel
2019-08-10  9:40   ` Ard Biesheuvel
2019-08-10  9:40 ` [PATCH v9 6/7] crypto: arm64/aes - implement accelerated ESSIV/CBC mode Ard Biesheuvel
2019-08-10  9:40   ` Ard Biesheuvel
2019-08-10  9:40   ` [dm-devel] " Ard Biesheuvel
2019-08-10  9:40 ` [PATCH v9 7/7] md: dm-crypt: omit parsing of the encapsulated cipher Ard Biesheuvel
2019-08-10  9:40   ` Ard Biesheuvel
2019-08-10  9:40   ` [dm-devel] " Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7b3365a9-42ca-5426-660f-e87898bb9f7a@gmail.com \
    --to=gmazyland@gmail.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=dm-devel@redhat.com \
    --cc=ebiggers@google.com \
    --cc=gilad@benyossef.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-fscrypt@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.