From: Eric Biggers <ebiggers@kernel.org>
To: Nathan Huckleberry <nhuck@google.com>
Cc: linux-crypto@vger.kernel.org,
linux-fscrypt.vger.kernel.org@google.com,
Herbert Xu <herbert@gondor.apana.org.au>,
"David S. Miller" <davem@davemloft.net>,
linux-arm-kernel@lists.infradead.org,
Paul Crowley <paulcrowley@google.com>,
Sami Tolvanen <samitolvanen@google.com>,
Ard Biesheuvel <ardb@kernel.org>
Subject: Re: [PATCH v5 3/8] crypto: hctr2 - Add HCTR2 support
Date: Sun, 1 May 2022 11:33:26 -0700 [thread overview]
Message-ID: <Ym7SdohJAlp6pOM9@sol.localdomain> (raw)
In-Reply-To: <20220427003759.1115361-4-nhuck@google.com>
On Wed, Apr 27, 2022 at 12:37:54AM +0000, Nathan Huckleberry wrote:
> +/* The input data for each HCTR2 hash step begins with a 16-byte block that
> + * contains the tweak length and a flag that indicates whether the input is evenly
> + * divisible into blocks. Since this implementation only supports one tweak
> + * length, we precompute the two hash states resulting from hashing the two
> + * possible values of this initial block. This reduces by one block the amount of
> + * data that needs to be hashed for each encryption/decryption
> + *
> + * These precomputed hashes are stored in hctr2_tfm_ctx.
> + */
Block comments should look like this:
/*
* text
*/
i.e. there should be a newline after the "/*"
> + memset(tctx->L, 0, sizeof(tctx->L));
> + memset(hbar, 0, sizeof(hbar));
> + tctx->L[0] = 0x01;
> + crypto_cipher_encrypt_one(tctx->blockcipher, tctx->L, tctx->L);
> + crypto_cipher_encrypt_one(tctx->blockcipher, hbar, hbar);
This would be easier to read if the computations of hbar and L were separated:
memset(hbar, 0, sizeof(hbar));
crypto_cipher_encrypt_one(tctx->blockcipher, hbar, hbar);
memset(tctx->L, 0, sizeof(tctx->L));
tctx->L[0] = 0x01;
crypto_cipher_encrypt_one(tctx->blockcipher, tctx->L, tctx->L);
> +static int hctr2_hash_message(struct skcipher_request *req,
> + struct scatterlist *sgl,
> + u8 digest[POLYVAL_DIGEST_SIZE])
> +{
> + u8 padding[BLOCKCIPHER_BLOCK_SIZE];
> + struct hctr2_request_ctx *rctx = skcipher_request_ctx(req);
> + struct shash_desc *hash_desc = &rctx->u.hash_desc;
> + const unsigned int bulk_len = req->cryptlen - BLOCKCIPHER_BLOCK_SIZE;
> + struct sg_mapping_iter miter;
> + unsigned int remainder = bulk_len % BLOCKCIPHER_BLOCK_SIZE;
> + int err, i;
> + int n = 0;
> +
> + sg_miter_start(&miter, sgl, sg_nents(sgl),
> + SG_MITER_FROM_SG | SG_MITER_ATOMIC);
> + for (i = 0; i < bulk_len; i += n) {
> + sg_miter_next(&miter);
> + n = min_t(unsigned int, miter.length, bulk_len - i);
> + err = crypto_shash_update(hash_desc, miter.addr, n);
> + if (err)
> + break;
> + }
> + sg_miter_stop(&miter);
> +
> + if (err)
> + return err;
There's actually an uninitialized variable bug here. If bulk_len==0, then 'err'
never gets initialized before being checked. I'm surprised this doesn't cause a
compiler warning, but it doesn't! 'err' needs to be initialized to 0.
> +
> + if (remainder) {
> + memset(padding, 0, BLOCKCIPHER_BLOCK_SIZE);
> + padding[0] = 0x01;
'padding' can be static const:
static const u8 padding[BLOCKCIPHER_BLOCK_SIZE] = { 0x1 };
> + subreq_size = max(sizeof_field(struct hctr2_request_ctx, u.hash_desc) +
> + crypto_shash_descsize(polyval), sizeof_field(struct
> + hctr2_request_ctx, u.xctr_req) +
> + crypto_skcipher_reqsize(xctr));
This is a little hard to read; it would be better if the sizeof_field()'s were
aligned:
subreq_size = max(sizeof_field(struct hctr2_request_ctx, u.hash_desc) +
crypto_shash_descsize(polyval),
sizeof_field(struct hctr2_request_ctx, u.xctr_req) +
crypto_skcipher_reqsize(xctr));
Other than that, everything looks good. The only thing that really has to be
fixed is the uninitialized variable. After that feel free to add:
Reviewed-by: Eric Biggers <ebiggers@google.com>
- Eric
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-05-01 18:34 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-27 0:37 [PATCH v5 0/8] crypto: HCTR2 support Nathan Huckleberry
2022-04-27 0:37 ` [PATCH v5 1/8] crypto: xctr - Add XCTR support Nathan Huckleberry
2022-04-27 0:37 ` [PATCH v5 2/8] crypto: polyval - Add POLYVAL support Nathan Huckleberry
2022-04-27 0:37 ` [PATCH v5 3/8] crypto: hctr2 - Add HCTR2 support Nathan Huckleberry
2022-05-01 18:33 ` Eric Biggers [this message]
2022-05-02 18:25 ` Eric Biggers
2022-04-27 0:37 ` [PATCH v5 4/8] crypto: x86/aesni-xctr: Add accelerated implementation of XCTR Nathan Huckleberry
2022-05-01 21:31 ` Eric Biggers
2022-04-27 0:37 ` [PATCH v5 5/8] crypto: arm64/aes-xctr: " Nathan Huckleberry
2022-05-01 22:08 ` Eric Biggers
2022-04-27 0:37 ` [PATCH v5 6/8] crypto: x86/polyval: Add PCLMULQDQ accelerated implementation of POLYVAL Nathan Huckleberry
2022-05-01 20:43 ` Eric Biggers
2022-05-02 18:08 ` Eric Biggers
2022-04-27 0:37 ` [PATCH v5 7/8] crypto: arm64/polyval: Add PMULL " Nathan Huckleberry
2022-05-01 20:21 ` Eric Biggers
2022-05-02 18:11 ` Eric Biggers
2022-04-27 0:37 ` [PATCH v5 8/8] fscrypt: Add HCTR2 support for filename encryption Nathan Huckleberry
2022-05-01 18:37 ` Eric Biggers
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=Ym7SdohJAlp6pOM9@sol.localdomain \
--to=ebiggers@kernel.org \
--cc=ardb@kernel.org \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-fscrypt.vger.kernel.org@google.com \
--cc=nhuck@google.com \
--cc=paulcrowley@google.com \
--cc=samitolvanen@google.com \
/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