linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Nathan Huckleberry <nhuck@google.com>
Cc: linux-crypto@vger.kernel.org,
	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>
Subject: Re: [RFC PATCH 1/7] crypto: xctr - Add XCTR support
Date: Wed, 26 Jan 2022 21:28:22 -0800	[thread overview]
Message-ID: <YfItdqtnwhaxpz89@sol.localdomain> (raw)
In-Reply-To: <20220125014422.80552-2-nhuck@google.com>

On Mon, Jan 24, 2022 at 07:44:16PM -0600, Nathan Huckleberry wrote:
> Add a generic implementation of XCTR mode as a template.  XCTR is a
> blockcipher mode similar to CTR mode.  XCTR uses XORs and little-endian
> addition rather than big-endian arithmetic which makes it slightly
> faster on little-endian CPUs.  It is used as a component to implement
> HCTR2.
>
> 
> More information on XCTR mode can be found in the HCTR2 paper:
> https://eprint.iacr.org/2021/1441.pdf

The other advantage (besides being faster on little-endian CPUs) of XCTR over
CTR is that on practical input sizes, XCTR never needs to deal with integer
overflows, and therefore is less likely to be implemented incorrectly.  It is in
the paper, but it's worth emphasizing.

> +static void crypto_xctr_crypt_final(struct skcipher_walk *walk,
> +				   struct crypto_cipher *tfm, u32 byte_ctr)
> +{
> +	unsigned int bsize = crypto_cipher_blocksize(tfm);
> +	unsigned long alignmask = crypto_cipher_alignmask(tfm);
> +	u8 ctr[MAX_CIPHER_BLOCKSIZE];
> +	u8 ctrblk[MAX_CIPHER_BLOCKSIZE];
> +	u8 tmp[MAX_CIPHER_BLOCKSIZE + MAX_CIPHER_ALIGNMASK];
> +	u8 *keystream = PTR_ALIGN(tmp + 0, alignmask + 1);
> +	u8 *src = walk->src.virt.addr;
> +	u8 *dst = walk->dst.virt.addr;
> +	unsigned int nbytes = walk->nbytes;
> +	u32 ctr32 = byte_ctr / bsize + 1;
> +
> +	u32_to_le_block(ctr, ctr32, bsize);
> +	crypto_xor_cpy(ctrblk, ctr, walk->iv, bsize);
> +	crypto_cipher_encrypt_one(tfm, keystream, ctrblk);
> +	crypto_xor_cpy(dst, keystream, src, nbytes);
> +}

How about limiting it to a 16-byte block size for now?  That would simplify the
implementation.  You can enforce the block size in crypto_xctr_create().

> +static struct crypto_template crypto_xctr_tmpl[] = {
> +	{
> +		.name = "xctr",
> +		.create = crypto_xctr_create,
> +		.module = THIS_MODULE,
> +	}
> +};

This is defining an array containing 1 crypto_template.  It should just define a
crypto_template struct on its own (not an array).

- Eric

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-01-27  5:29 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-25  1:44 [RFC PATCH 0/7] crypto: HCTR2 support Nathan Huckleberry
2022-01-25  1:44 ` [RFC PATCH 1/7] crypto: xctr - Add XCTR support Nathan Huckleberry
2022-01-27  5:28   ` Eric Biggers [this message]
2022-01-27  9:42   ` Ard Biesheuvel
2022-01-27 19:26     ` Eric Biggers
2022-01-27 19:43       ` Ard Biesheuvel
2022-01-25  1:44 ` [RFC PATCH 2/7] crypto: polyval - Add POLYVAL support Nathan Huckleberry
2022-01-27  5:19   ` Eric Biggers
2022-01-25  1:44 ` [RFC PATCH 3/7] crypto: hctr2 - Add HCTR2 support Nathan Huckleberry
2022-01-27  5:08   ` Eric Biggers
2022-01-27  5:20     ` Herbert Xu
2022-01-27  5:36       ` Eric Biggers
2022-01-27  5:40         ` Herbert Xu
2022-01-27  5:44           ` Herbert Xu
2022-01-27  6:41             ` Eric Biggers
2022-01-27  6:35   ` Eric Biggers
2022-02-01 18:25     ` Eric Biggers
2022-01-27  9:29   ` Ard Biesheuvel
2022-01-27 19:20     ` Eric Biggers
2022-01-25  1:44 ` [RFC PATCH 4/7] crypto: x86/aesni-xctr: Add accelerated implementation of XCTR Nathan Huckleberry
2022-01-25  1:44 ` [RFC PATCH 5/7] crypto: arm64/aes-xctr: " Nathan Huckleberry
2022-01-28 14:10   ` Ard Biesheuvel
2022-02-07 10:00     ` Ard Biesheuvel
2022-01-25  1:44 ` [RFC PATCH 6/7] crypto: x86/polyval: Add PCLMULQDQ accelerated implementation of POLYVAL Nathan Huckleberry
2022-02-01 18:18   ` Eric Biggers
2022-02-03  3:28   ` Eric Biggers
2022-01-25  1:44 ` [RFC PATCH 7/7] crypto: arm64/polyval: Add PMULL " Nathan Huckleberry

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=YfItdqtnwhaxpz89@sol.localdomain \
    --to=ebiggers@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=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;
as well as URLs for NNTP newsgroup(s).