From: Eric Biggers <ebiggers@kernel.org>
To: linux-crypto@vger.kernel.org
Subject: [RFC/RFT PATCH 11/18] crypto: arm64/cbcmac - handle empty messages in same way as template
Date: Sun, 31 Mar 2019 13:04:21 -0700 [thread overview]
Message-ID: <20190331200428.26597-12-ebiggers@kernel.org> (raw)
In-Reply-To: <20190331200428.26597-1-ebiggers@kernel.org>
From: Eric Biggers <ebiggers@google.com>
My patches to make testmgr fuzz algorithms against their generic
implementation detected that the arm64 implementations of "cbcmac(aes)"
handle empty messages differently from the cbcmac template. Namely, the
arm64 implementations return the encrypted initial value, but the cbcmac
template returns the initial value directly.
This isn't actually a meaningful case because any user of cbcmac needs
to prepend the message length, as CCM does; otherwise it's insecure.
However, we should keep the behavior consistent; at the very least this
makes testing easier.
Do it the easy way, which is to change the arm64 implementations to have
the same behavior as the cbcmac template.
For what it's worth, ghash does things essentially the same way: it
returns its initial value when given an empty message, even though in
practice ghash is never passed an empty message.
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
arch/arm64/crypto/aes-glue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/crypto/aes-glue.c b/arch/arm64/crypto/aes-glue.c
index 692cb75f2ca2f..f0ceb545bd1ee 100644
--- a/arch/arm64/crypto/aes-glue.c
+++ b/arch/arm64/crypto/aes-glue.c
@@ -707,7 +707,7 @@ static int cbcmac_final(struct shash_desc *desc, u8 *out)
struct mac_tfm_ctx *tctx = crypto_shash_ctx(desc->tfm);
struct mac_desc_ctx *ctx = shash_desc_ctx(desc);
- mac_do_update(&tctx->key, NULL, 0, ctx->dg, 1, 0);
+ mac_do_update(&tctx->key, NULL, 0, ctx->dg, (ctx->len != 0), 0);
memcpy(out, ctx->dg, AES_BLOCK_SIZE);
--
2.21.0
next prev parent reply other threads:[~2019-03-31 20:06 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-31 20:04 [RFC/RFT PATCH 00/18] crypto: fuzz algorithms against their generic implementation Eric Biggers
2019-03-31 20:04 ` [RFC/RFT PATCH 01/18] crypto: x86/poly1305 - fix overflow during partial reduction Eric Biggers
2019-04-01 7:52 ` Martin Willi
2019-03-31 20:04 ` [RFC/RFT PATCH 02/18] crypto: crct10dif-generic - fix use via crypto_shash_digest() Eric Biggers
2019-03-31 20:04 ` [RFC/RFT PATCH 03/18] crypto: x86/crct10dif-pcl " Eric Biggers
2019-03-31 20:04 ` [RFC/RFT PATCH 04/18] crypto: skcipher - restore default skcipher_walk::iv on error Eric Biggers
2019-04-08 6:23 ` Herbert Xu
2019-04-08 17:27 ` Eric Biggers
2019-04-09 6:37 ` Herbert Xu
2019-03-31 20:04 ` [RFC/RFT PATCH 05/18] crypto: skcipher - don't WARN on unprocessed data after slow walk step Eric Biggers
2019-03-31 20:04 ` [RFC/RFT PATCH 06/18] crypto: chacha20poly1305 - set cra_name correctly Eric Biggers
2019-04-01 7:57 ` Martin Willi
2019-03-31 20:04 ` [RFC/RFT PATCH 07/18] crypto: gcm - fix incompatibility between "gcm" and "gcm_base" Eric Biggers
2019-04-01 15:56 ` Eric Biggers
2019-03-31 20:04 ` [RFC/RFT PATCH 08/18] crypto: ccm - fix incompatibility between "ccm" and "ccm_base" Eric Biggers
2019-04-02 15:48 ` Sasha Levin
2019-03-31 20:04 ` [RFC/RFT PATCH 09/18] crypto: streebog - fix unaligned memory accesses Eric Biggers
2019-03-31 21:47 ` Vitaly Chikunov
2019-04-02 16:15 ` Vitaly Chikunov
2019-04-02 16:57 ` Eric Biggers
2019-03-31 20:04 ` [RFC/RFT PATCH 10/18] crypto: cts - don't support empty messages Eric Biggers
2019-03-31 20:04 ` Eric Biggers [this message]
2019-03-31 20:04 ` [RFC/RFT PATCH 12/18] crypto: testmgr - expand ability to test for errors Eric Biggers
2019-03-31 20:04 ` [RFC/RFT PATCH 13/18] crypto: testmgr - identify test vectors by name rather than number Eric Biggers
2019-03-31 20:04 ` [RFC/RFT PATCH 14/18] crypto: testmgr - add helpers for fuzzing against generic implementation Eric Biggers
2019-03-31 20:04 ` [RFC/RFT PATCH 15/18] crypto: testmgr - fuzz hashes against their " Eric Biggers
2019-03-31 20:04 ` [RFC/RFT PATCH 16/18] crypto: testmgr - fuzz skciphers " Eric Biggers
2019-03-31 20:04 ` [RFC/RFT PATCH 17/18] crypto: testmgr - fuzz AEADs " Eric Biggers
2019-03-31 20:04 ` [RFC/RFT PATCH 18/18] crypto: run initcalls for generic implementations earlier Eric Biggers
2019-04-08 5:53 ` Herbert Xu
2019-04-08 17:44 ` Eric Biggers
2019-04-09 6:24 ` Herbert Xu
2019-04-09 18:16 ` Eric Biggers
2019-04-11 6:26 ` Herbert Xu
2019-04-08 6:44 ` [RFC/RFT PATCH 00/18] crypto: fuzz algorithms against their generic implementation Herbert Xu
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=20190331200428.26597-12-ebiggers@kernel.org \
--to=ebiggers@kernel.org \
--cc=linux-crypto@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 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).