* [PATCH -stable] crypto: ccm - deal with CTR ciphers that honour iv_out
@ 2017-01-28 20:40 Ard Biesheuvel
2017-02-01 20:08 ` Ard Biesheuvel
0 siblings, 1 reply; 6+ messages in thread
From: Ard Biesheuvel @ 2017-01-28 20:40 UTC (permalink / raw)
To: linux-crypto; +Cc: herbert, Ard Biesheuvel
The skcipher API mandates that chaining modes involving IVs calculate
an outgoing IV value that is suitable for encrypting additional blocks
of data. This means the CCM driver cannot assume that req->iv points to
the original IV value when it calls crypto_ccm_auth. So pass a copy to
the skcipher instead.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
crypto/ccm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/crypto/ccm.c b/crypto/ccm.c
index b388ac6edfb9..8976ef9bc2e7 100644
--- a/crypto/ccm.c
+++ b/crypto/ccm.c
@@ -362,7 +362,7 @@ static int crypto_ccm_decrypt(struct aead_request *req)
unsigned int cryptlen = req->cryptlen;
u8 *authtag = pctx->auth_tag;
u8 *odata = pctx->odata;
- u8 *iv = req->iv;
+ u8 iv[16];
int err;
cryptlen -= authsize;
@@ -378,6 +378,7 @@ static int crypto_ccm_decrypt(struct aead_request *req)
if (req->src != req->dst)
dst = pctx->dst;
+ memcpy(iv, req->iv, sizeof(iv));
skcipher_request_set_tfm(skreq, ctx->ctr);
skcipher_request_set_callback(skreq, pctx->flags,
crypto_ccm_decrypt_done, req);
--
2.7.4
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH -stable] crypto: ccm - deal with CTR ciphers that honour iv_out
2017-01-28 20:40 [PATCH -stable] crypto: ccm - deal with CTR ciphers that honour iv_out Ard Biesheuvel
@ 2017-02-01 20:08 ` Ard Biesheuvel
2017-02-02 5:13 ` Herbert Xu
0 siblings, 1 reply; 6+ messages in thread
From: Ard Biesheuvel @ 2017-02-01 20:08 UTC (permalink / raw)
To: linux-crypto; +Cc: Herbert Xu, Ard Biesheuvel
On 28 January 2017 at 20:40, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> The skcipher API mandates that chaining modes involving IVs calculate
> an outgoing IV value that is suitable for encrypting additional blocks
> of data. This means the CCM driver cannot assume that req->iv points to
> the original IV value when it calls crypto_ccm_auth. So pass a copy to
> the skcipher instead.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> crypto/ccm.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/crypto/ccm.c b/crypto/ccm.c
> index b388ac6edfb9..8976ef9bc2e7 100644
> --- a/crypto/ccm.c
> +++ b/crypto/ccm.c
> @@ -362,7 +362,7 @@ static int crypto_ccm_decrypt(struct aead_request *req)
> unsigned int cryptlen = req->cryptlen;
> u8 *authtag = pctx->auth_tag;
> u8 *odata = pctx->odata;
> - u8 *iv = req->iv;
> + u8 iv[16];
> int err;
>
> cryptlen -= authsize;
> @@ -378,6 +378,7 @@ static int crypto_ccm_decrypt(struct aead_request *req)
> if (req->src != req->dst)
> dst = pctx->dst;
>
> + memcpy(iv, req->iv, sizeof(iv));
> skcipher_request_set_tfm(skreq, ctx->ctr);
> skcipher_request_set_callback(skreq, pctx->flags,
> crypto_ccm_decrypt_done, req);
> --
> 2.7.4
>
Herbert,
Could you please forward this patch to Linus as well? I noticed that the patch
crypto: arm64/aes-blk - honour iv_out requirement in CBC and CTR modes
is now in mainline, which means CCM is now broken on arm64, given that
the iv_out requirement for CTR apparently isn't honored by *any*
implementation, and CCM wrongly assumes that req->iv retains its value
across the call into the CTR skcipher
Thanks,
Ard.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH -stable] crypto: ccm - deal with CTR ciphers that honour iv_out
2017-02-01 20:08 ` Ard Biesheuvel
@ 2017-02-02 5:13 ` Herbert Xu
2017-02-02 8:01 ` Ard Biesheuvel
0 siblings, 1 reply; 6+ messages in thread
From: Herbert Xu @ 2017-02-02 5:13 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-crypto
On Wed, Feb 01, 2017 at 08:08:09PM +0000, Ard Biesheuvel wrote:
>
> Could you please forward this patch to Linus as well? I noticed that the patch
Sure, I will do that.
> crypto: arm64/aes-blk - honour iv_out requirement in CBC and CTR modes
>
> is now in mainline, which means CCM is now broken on arm64, given that
> the iv_out requirement for CTR apparently isn't honored by *any*
> implementation, and CCM wrongly assumes that req->iv retains its value
> across the call into the CTR skcipher
Hmm, I wonder why we don't see this breakage with the generic
CTR as it seems to do exactly the same thing.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH -stable] crypto: ccm - deal with CTR ciphers that honour iv_out
2017-02-02 5:13 ` Herbert Xu
@ 2017-02-02 8:01 ` Ard Biesheuvel
2017-02-02 9:53 ` Herbert Xu
0 siblings, 1 reply; 6+ messages in thread
From: Ard Biesheuvel @ 2017-02-02 8:01 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto
On 2 February 2017 at 05:13, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Wed, Feb 01, 2017 at 08:08:09PM +0000, Ard Biesheuvel wrote:
>>
>> Could you please forward this patch to Linus as well? I noticed that the patch
>
> Sure, I will do that.
>
>> crypto: arm64/aes-blk - honour iv_out requirement in CBC and CTR modes
>>
>> is now in mainline, which means CCM is now broken on arm64, given that
>> the iv_out requirement for CTR apparently isn't honored by *any*
>> implementation, and CCM wrongly assumes that req->iv retains its value
>> across the call into the CTR skcipher
>
> Hmm, I wonder why we don't see this breakage with the generic
> CTR as it seems to do exactly the same thing.
>
You are right: due to its construction, the CCM mode does not care
about the incremented counter because it clears the counter part of
the IV before encrypting the MAC. So this is caused by an optimization
in my code rather than the CCM code being incorrect.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH -stable] crypto: ccm - deal with CTR ciphers that honour iv_out
2017-02-02 8:01 ` Ard Biesheuvel
@ 2017-02-02 9:53 ` Herbert Xu
2017-02-02 11:39 ` Ard Biesheuvel
0 siblings, 1 reply; 6+ messages in thread
From: Herbert Xu @ 2017-02-02 9:53 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-crypto
On Thu, Feb 02, 2017 at 08:01:47AM +0000, Ard Biesheuvel wrote:
>
> You are right: due to its construction, the CCM mode does not care
> about the incremented counter because it clears the counter part of
> the IV before encrypting the MAC. So this is caused by an optimization
> in my code rather than the CCM code being incorrect.
OK so you will send me an update for the ARM64 code, right?
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH -stable] crypto: ccm - deal with CTR ciphers that honour iv_out
2017-02-02 9:53 ` Herbert Xu
@ 2017-02-02 11:39 ` Ard Biesheuvel
0 siblings, 0 replies; 6+ messages in thread
From: Ard Biesheuvel @ 2017-02-02 11:39 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto
On 2 February 2017 at 09:53, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Thu, Feb 02, 2017 at 08:01:47AM +0000, Ard Biesheuvel wrote:
>>
>> You are right: due to its construction, the CCM mode does not care
>> about the incremented counter because it clears the counter part of
>> the IV before encrypting the MAC. So this is caused by an optimization
>> in my code rather than the CCM code being incorrect.
>
> OK so you will send me an update for the ARM64 code, right?
>
Yes, on their way
Thanks,
Ard.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-02-02 11:39 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-01-28 20:40 [PATCH -stable] crypto: ccm - deal with CTR ciphers that honour iv_out Ard Biesheuvel
2017-02-01 20:08 ` Ard Biesheuvel
2017-02-02 5:13 ` Herbert Xu
2017-02-02 8:01 ` Ard Biesheuvel
2017-02-02 9:53 ` Herbert Xu
2017-02-02 11:39 ` Ard Biesheuvel
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).