Linux cryptographic layer development
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: Eric Biggers <ebiggers@kernel.org>, linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 04/33] lib/crypto: aes: Add CTR and XCTR support
Date: Mon, 13 Jul 2026 10:39:53 +0200	[thread overview]
Message-ID: <40932e40-a909-4b95-b739-c4727c1cc153@redhat.com> (raw)
In-Reply-To: <20260707053503.209874-5-ebiggers@kernel.org>

On 07/07/2026 07.34, Eric Biggers wrote:
> Add support for AES-CTR and AES-XCTR to the crypto library.
> 
> These will be used to provide streamlined implementations of the
> "ctr(aes)" and "xctr(aes)" crypto_skcipher algorithms.  Most users of
> "ctr(aes)" will also be able to switch to the library, which as usual
> will be simpler and faster, e.g.:
> 
>    - net/mac80211/fils_aead.c
>    - net/mac802154/llsec.c
> 
> As usual, the architecture-optimized AES-CTR and AES-XCTR code will be
> migrated into the library as well (using the hooks provided in this
> commit), eliminating lots of repetitive boilerplate code.
> 
> This is also a prerequisite for supporting AES-GCM, AES-CCM, and
> AES-HCTR2 in the crypto library.
> 
> Initial test coverage is provided by the crypto_skcipher support added
> in a later commit.  I'm planning a KUnit test suite as well.
> 
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> ---
>   .../crypto/libcrypto-unauth-encryption.rst    |  7 ++
>   include/crypto/aes-ctr.h                      | 56 +++++++++++
>   lib/crypto/Kconfig                            |  6 ++
>   lib/crypto/aes.c                              | 93 +++++++++++++++++++
>   lib/crypto/tests/Kconfig                      |  1 +
>   5 files changed, 163 insertions(+)
>   create mode 100644 include/crypto/aes-ctr.h
> 
> diff --git a/Documentation/crypto/libcrypto-unauth-encryption.rst b/Documentation/crypto/libcrypto-unauth-encryption.rst
> index fb8106034089..6aca01d715da 100644
> --- a/Documentation/crypto/libcrypto-unauth-encryption.rst
> +++ b/Documentation/crypto/libcrypto-unauth-encryption.rst
> @@ -27,6 +27,13 @@ Support for AES in the CBC and CBC-CTS modes of operation.
>   
>   .. kernel-doc:: include/crypto/aes-cbc.h
>   
> +AES-CTR and AES-XCTR
> +--------------------
> +
> +Support for AES in the CTR and XCTR modes of operation.

I guess you already have this on your radar, but just in case: It would be 
nice to turn this into a full sentence, too.

> +.. kernel-doc:: include/crypto/aes-ctr.h
> +
>   AES-ECB
>   -------
>   
> diff --git a/include/crypto/aes-ctr.h b/include/crypto/aes-ctr.h
> new file mode 100644
> index 000000000000..fa2b7d303e55
> --- /dev/null
> +++ b/include/crypto/aes-ctr.h
> @@ -0,0 +1,56 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * AES-CTR and AES-XCTR stream ciphers
> + *
> + * Copyright 2026 Google LLC
> + */
> +#ifndef _CRYPTO_AES_CTR_H
> +#define _CRYPTO_AES_CTR_H
> +
> +#include <crypto/aes.h>
> +
> +/**
> + * aes_ctr() - AES-CTR en/decryption
> + * @dst: The destination buffer.  Can be in-place or out-of-place.  For other
> + *	 overlaps the behavior is unspecified.
> + * @src: The source data
> + * @len: Number of bytes to en/decrypt
> + * @ctr: The counter.  It will be incremented by ceil(@len / AES_BLOCK_SIZE).
> + * @key: The key
> + *
> + * This implements AES in counter mode with a 128-bit big endian counter.
> + *
> + * This supports incremental en/decryption.  The length of each non-final chunk
> + * must be a multiple of AES_BLOCK_SIZE, and the updated @ctr must be passed in
> + * each time.

Maybe add some wording that ctr ideally should not be 0 for the first call, 
i.e. a "nonce" value?

> + * Context: Any context.
> + */
> +void aes_ctr(u8 *dst, const u8 *src, size_t len,
> +	     u8 ctr[at_least AES_BLOCK_SIZE], aes_encrypt_arg key);
> +
> +/**
> + * aes_xctr() - AES-XCTR en/decryption
> + * @dst: The destination buffer.  Can be in-place or out-of-place.  For other
> + *	 overlaps the behavior is unspecified.
> + * @src: The source data
> + * @len: Number of bytes to en/decrypt
> + * @ctr: The block counter.  For the first call, set it to 1.  It will be
> + *	 incremented by ceil(@len / AES_BLOCK_SIZE).
> + * @iv: The initialization vector
> + * @key: The key
> + *
> + * This implements AES in XOR Counter mode, as specified in the paper
> + * "Length-preserving encryption with HCTR2"
> + * (https://eprint.iacr.org/2021/1441.pdf).
> + *
> + * This supports incremental en/decryption.  The length of each non-final chunk
> + * must be a multiple of AES_BLOCK_SIZE, and the updated @ctr must be passed in
> + * each time.
> + *
> + * Context: Any context.
> + */
> +void aes_xctr(u8 *dst, const u8 *src, size_t len, u64 *ctr,
> +	      const u8 iv[at_least AES_BLOCK_SIZE], aes_encrypt_arg key);
> +
> +#endif /* _CRYPTO_AES_CTR_H */
> diff --git a/lib/crypto/Kconfig b/lib/crypto/Kconfig
> index c64cc3e12b57..96febc3df6d6 100644
> --- a/lib/crypto/Kconfig
> +++ b/lib/crypto/Kconfig
> @@ -47,6 +47,12 @@ config CRYPTO_LIB_AES_ECB
>   	help
>   	  The AES-ECB library functions.
>   
> +config CRYPTO_LIB_AES_CTR
> +	tristate
> +	select CRYPTO_LIB_AES
> +	help
> +	  The AES-CTR and AES-XCTR library functions.
> +
>   config CRYPTO_LIB_AESGCM
>   	tristate
>   	select CRYPTO_LIB_AES
> diff --git a/lib/crypto/aes.c b/lib/crypto/aes.c
> index 3635fbe946f3..9da274a72221 100644
> --- a/lib/crypto/aes.c
> +++ b/lib/crypto/aes.c
> @@ -6,6 +6,7 @@
>   
>   #include <crypto/aes-cbc-macs.h>
>   #include <crypto/aes-cbc.h>
> +#include <crypto/aes-ctr.h>
>   #include <crypto/aes-ecb.h>
>   #include <crypto/aes.h>
>   #include <crypto/utils.h>
> @@ -967,6 +968,98 @@ void aes_cbc_cts_decrypt(u8 *dst, const u8 *src, size_t len,
>   EXPORT_SYMBOL_GPL(aes_cbc_cts_decrypt);
>   #endif /* CONFIG_CRYPTO_LIB_AES_CBC */
>   
> +#if IS_ENABLED(CONFIG_CRYPTO_LIB_AES_CTR)
> +/*
> + * Hooks for optimized AES-CTR and AES-XCTR implementations, overridable by the
> + * architecture.  They are called with any len >= 0.  Returning false causes the
> + * fallback implementation to be used instead.
> + */
> +#ifndef aes_ctr_arch
> +static bool aes_ctr_arch(u8 *dst, const u8 *src, size_t len,
> +			 u8 ctr[AES_BLOCK_SIZE], const struct aes_enckey *key)
> +{
> +	return false;
> +}
> +#endif
> +#ifndef aes_xctr_arch
> +static bool aes_xctr_arch(u8 *dst, const u8 *src, size_t len, u64 *ctr,
> +			  const u8 iv[AES_BLOCK_SIZE],
> +			  const struct aes_enckey *key)
> +{
> +	return false;
> +}
> +#endif
> +
> +static __always_inline void inc_be128_ctr(u8 ctr[AES_BLOCK_SIZE])
> +{
> +	/* Casts to u8 are needed because of the implicit integer promotion. */
> +	if (((u8)++ctr[AES_BLOCK_SIZE - 1]) != 0)
> +		return;

Why do you handle the first value separately here? The code could be 
simplified to start with "int i = AES_BLOCK_SIZE -1" in the for-loop instead?

> +	for (int i = AES_BLOCK_SIZE - 2; i >= 0; i--) {
> +		if ((u8)++ctr[i] != 0)
> +			break;
> +	}
> +}
> +
> +void aes_ctr(u8 *dst, const u8 *src, size_t len, u8 ctr[AES_BLOCK_SIZE],
> +	     aes_encrypt_arg key)
> +{
> +	u8 keystream[AES_BLOCK_SIZE] __aligned(__alignof__(long));
> +
> +	if (likely(aes_ctr_arch(dst, src, len, ctr, key.enc_key)))
> +		return;
> +
> +	/* Handle the full blocks. */
> +	for (; len >= AES_BLOCK_SIZE; len -= AES_BLOCK_SIZE) {
> +		aes_encrypt(key, keystream, ctr);
> +		crypto_xor_cpy(dst, src, keystream, AES_BLOCK_SIZE);
> +		inc_be128_ctr(ctr);
> +		dst += AES_BLOCK_SIZE;
> +		src += AES_BLOCK_SIZE;
> +	}
> +	/* Handle any partial block at the end. */
> +	if (len) {
> +		aes_encrypt(key, keystream, ctr);
> +		crypto_xor_cpy(dst, src, keystream, len);
> +		/* Counter is incremented even with just a partial block. */
> +		inc_be128_ctr(ctr);
> +	}
> +	memzero_explicit(keystream, sizeof(keystream));
> +}
> +EXPORT_SYMBOL_GPL(aes_ctr);
> +
> +void aes_xctr(u8 *dst, const u8 *src, size_t len, u64 *ctr,
> +	      const u8 iv[AES_BLOCK_SIZE], aes_encrypt_arg key)
> +{
> +	const __le64 iv0 = get_unaligned((const __le64 *)&iv[0]);
> +	__le64 aes_input[2];
> +	u8 keystream[AES_BLOCK_SIZE] __aligned(__alignof__(long));
> +
> +	if (likely(aes_xctr_arch(dst, src, len, ctr, iv, key.enc_key)))
> +		return;
> +
> +	aes_input[1] = get_unaligned((const __le64 *)&iv[8]);
> +	/* Handle the full blocks. */
> +	for (; len >= AES_BLOCK_SIZE; len -= AES_BLOCK_SIZE) {
> +		aes_input[0] = iv0 ^ cpu_to_le64((*ctr)++);

Do we want to have a BUG_ON or WARN_ON_ONCE somewhere to check that ctr does 
not wrap around (i.e. to make sure that ctr was really 1 for the first 
call)? Something like:

	WARN_ON_ONCE((s64)(cpu_to_le64(*ctr) + len / AES_BLOCK_SIZE) < 0)

at the beginning of the function?

> +		aes_encrypt(key, keystream, (const u8 *)aes_input);
> +		crypto_xor_cpy(dst, src, keystream, AES_BLOCK_SIZE);
> +		dst += AES_BLOCK_SIZE;
> +		src += AES_BLOCK_SIZE;
> +	}
> +	/* Handle any partial block at the end. */
> +	if (len) {
> +		/* Counter is incremented even with just a partial block. */
> +		aes_input[0] = iv0 ^ cpu_to_le64((*ctr)++);
> +		aes_encrypt(key, keystream, (const u8 *)aes_input);
> +		crypto_xor_cpy(dst, src, keystream, len);
> +	}
> +	memzero_explicit(keystream, sizeof(keystream));
> +	memzero_explicit(aes_input, sizeof(aes_input));
> +}
> +EXPORT_SYMBOL_GPL(aes_xctr);
> +#endif /* CONFIG_CRYPTO_LIB_AES_CTR */
> +
>   static int __init aes_mod_init(void)
>   {
>   #ifdef aes_mod_init_arch
> diff --git a/lib/crypto/tests/Kconfig b/lib/crypto/tests/Kconfig
> index e78086f3c954..9284d0134d77 100644
> --- a/lib/crypto/tests/Kconfig
> +++ b/lib/crypto/tests/Kconfig
> @@ -146,6 +146,7 @@ config CRYPTO_LIB_ENABLE_ALL_FOR_KUNIT
>   	depends on KUNIT
>   	select CRYPTO_LIB_AES_CBC
>   	select CRYPTO_LIB_AES_CBC_MACS
> +	select CRYPTO_LIB_AES_CTR
>   	select CRYPTO_LIB_AES_ECB
>   	select CRYPTO_LIB_BLAKE2B
>   	select CRYPTO_LIB_CHACHA20POLY1305

  Thomas


  reply	other threads:[~2026-07-13  8:40 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-07  5:34 [PATCH 00/33] Library APIs for AES encryption modes Eric Biggers
2026-07-07  5:34 ` [PATCH 01/33] crypto: xts - Split out __xts_verify_key() helper Eric Biggers
2026-07-07 13:20   ` Thomas Huth
2026-07-07  5:34 ` [PATCH 02/33] lib/crypto: aes: Add ECB support Eric Biggers
2026-07-07 13:59   ` Thomas Huth
2026-07-07 19:22     ` Eric Biggers
2026-07-08  5:29       ` Thomas Huth
2026-07-07  5:34 ` [PATCH 03/33] lib/crypto: aes: Add CBC and CBC-CTS support Eric Biggers
2026-07-09 13:06   ` Thomas Huth
2026-07-07  5:34 ` [PATCH 04/33] lib/crypto: aes: Add CTR and XCTR support Eric Biggers
2026-07-13  8:39   ` Thomas Huth [this message]
2026-07-07  5:34 ` [PATCH 05/33] lib/crypto: aes: Add XTS support Eric Biggers
2026-07-13 12:15   ` Thomas Huth
2026-07-07  5:34 ` [PATCH 06/33] lib/crypto: aes: Add GCM support Eric Biggers
2026-07-07  5:34 ` [PATCH 07/33] lib/crypto: aes: Add CCM support Eric Biggers
2026-07-07  5:34 ` [PATCH 08/33] crypto: aes - Add ECB support using library Eric Biggers
2026-07-07  5:34 ` [PATCH 09/33] crypto: aes - Add CBC and CBC-CTS " Eric Biggers
2026-07-07  5:34 ` [PATCH 10/33] crypto: aes - Add CTR and XCTR " Eric Biggers
2026-07-07  5:34 ` [PATCH 11/33] crypto: aes - Add XTS " Eric Biggers
2026-07-07  5:34 ` [PATCH 12/33] crypto: aes - Add GCM " Eric Biggers
2026-07-07  5:34 ` [PATCH 13/33] crypto: aes - Add CCM " Eric Biggers
2026-07-07  5:34 ` [PATCH 14/33] x86/sev: Use new AES-GCM library Eric Biggers
2026-07-07  5:34 ` [PATCH 15/33] lib/crypto: aesgcm: Remove old " Eric Biggers
2026-07-07  5:34 ` [PATCH 16/33] crypto: aes - Remove AES-CBC-MAC support Eric Biggers
2026-07-07  5:34 ` [PATCH 17/33] lib/crypto: aes: Remove aes_cbcmac_* functions Eric Biggers
2026-07-07  5:34 ` [PATCH 18/33] fscrypt: Use aes_ecb_encrypt() for v1 key derivation Eric Biggers
2026-07-07  5:34 ` [PATCH 19/33] KEYS: encrypted: Use AES-CBC library instead of crypto_skcipher Eric Biggers
2026-07-07  5:34 ` [PATCH 20/33] KEYS: trusted: dcp: Use AES-GCM library instead of crypto_aead Eric Biggers
2026-07-07  5:34 ` [PATCH 21/33] libceph: Use AES-CBC library in ceph_aes_crypt() Eric Biggers
2026-07-07  5:34 ` [PATCH 22/33] libceph: Reimplement messenger v2 encryption using AES-GCM library Eric Biggers
2026-07-07  5:34 ` [PATCH 23/33] wifi: mac80211: Use AES-CTR library in fils_aead.c Eric Biggers
2026-07-07  5:34 ` [PATCH 24/33] wifi: mac80211: Use AES-GCM library for GMAC suite Eric Biggers
2026-07-07  5:34 ` [PATCH 25/33] wifi: mac80211: Use crypto libraries for GCMP and CCMP suites Eric Biggers
2026-07-07  5:34 ` [PATCH 26/33] macsec: Use AES-GCM library instead of crypto_aead Eric Biggers
2026-07-07  5:34 ` [PATCH 27/33] wifi: ipw2x00: Use AES-CCM library Eric Biggers
2026-07-07  5:34 ` [PATCH 28/33] mac802154: Use AES-CCM and AES-CTR libraries Eric Biggers
2026-07-07  5:34 ` [PATCH 29/33] bpf: crypto: Use AES-CBC and AES-ECB libraries Eric Biggers
2026-07-07 15:01   ` Vadim Fedorenko
2026-07-07 18:20     ` Eric Biggers
2026-07-07 22:50       ` Vadim Fedorenko
2026-07-07 23:16         ` Eric Biggers
2026-07-08 11:47           ` Vadim Fedorenko
2026-07-09 15:47             ` Eric Biggers
2026-07-09 16:46               ` Vadim Fedorenko
2026-07-07  5:35 ` [PATCH 30/33] bpf: crypto: Add AES-GCM support Eric Biggers
2026-07-07 15:02   ` Vadim Fedorenko
2026-07-07  5:35 ` [PATCH 31/33] smb: client: Use AES-GCM and AES-CCM libraries Eric Biggers
2026-07-07  5:35 ` [PATCH 32/33] ksmbd: " Eric Biggers
2026-07-07 10:51   ` Namjae Jeon
2026-07-07  5:35 ` [PATCH 33/33] net: tipc: Use AES-GCM library instead of crypto_aead 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=40932e40-a909-4b95-b739-c4727c1cc153@redhat.com \
    --to=thuth@redhat.com \
    --cc=ebiggers@kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@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