Re: [PATCH v5 06/14] crypto: aes: fix software key-size handling

Hi James,

On 2026-07-20T04:13:44, James Hilliard <[email protected]> wrote:
> crypto: aes: fix software key-size handling
>
> The AES uclass API expresses key sizes in bits, while the common software
> AES primitives take key lengths in bytes. The software provider passes the
> uclass value through unchanged, so AES-192 and AES-256 select the AES-128
> round count and key schedule shape. Key expansion also copies the bit count
> as a byte count for every key size.
>
> Validate the uclass key size, convert it to bytes once and retain that byte
> length for the software operations. Correct the primitive API documentation
> and add NIST ECB and CBC vectors for AES-128, AES-192 and AES-256.
>
> Signed-off-by: James Hilliard <[email protected]>
>
> drivers/crypto/aes/aes-sw.c |  43 +++++++++++++-----
>  include/uboot_aes.h         |  20 ++++-----
>  test/dm/aes.c               | 107 ++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 148 insertions(+), 22 deletions(-)

> diff --git a/include/uboot_aes.h b/include/uboot_aes.h
> @@ -47,30 +47,30 @@ enum {
>   * aes_encrypt() - Encrypt single block of data with AES 128
>   *
> - * @key_size Size of the aes key (in bits)
> + * @key_len  Size of the AES key in bytes

I see stale 'with AES 128' wording in both the aes_encrypt() and
aes_decrypt() headers, though the round count now comes from the key
length. Please can you drop the '128' so the summary matches the
parameter you just corrected?

> diff --git a/drivers/crypto/aes/aes-sw.c b/drivers/crypto/aes/aes-sw.c
> @@ -12,13 +12,23 @@ struct sw_aes_priv {
>  static int prepare_aes(struct sw_aes_priv *priv)
>  {
> -     if (!priv->selected_key_size) {
> +     if (!priv->selected_key_len) {
>               log_debug("%s: AES key size not set, setup a slot first\n", __func__);
>               return 1;
>       }

How about returning a proper -errno here - it would tidy things up
while you are respinning.

In any case:

Reviewed-by: Simon Glass <[email protected]>

Regards,
Simon