Re: [PATCH 02/33] lib/crypto: aes: Add ECB support

[Thomas Huth <thuth@redhat.com>]

On 07/07/2026 21.22, Eric Biggers wrote:
> On Tue, Jul 07, 2026 at 03:59:24PM +0200, Thomas Huth wrote:
>>> +Unauthenticated encryption
>>> +==========================
>>> +
>>> +Support for unauthenticated encryption and decryption, including bare stream
>>> +ciphers and other length-preserving algorithms such as block ciphers in XTS
>>> +mode.
>>
>> This sentence no verb?
> 
> It's a noun phrase that introduces what the section contains, before
> transitioning into full sentences.
> 
> I used this in all existing Documentation/crypto/libcrypto-*.rst.  It's
> also fairly common in the help text for kconfig symbols (across the
> kernel, not just the kconfig help text I've written).

Fair point for the help texts (which should be concise), but (as a 
non-native speaker) I did not expect it in doc file. Anyway, if it's already 
like this in other files, then it's certainly fine here, too.

>>> +void aes_ecb_encrypt(u8 *dst, const u8 *src, size_t len, aes_encrypt_arg key);
>>
>> Other similar functions like aes_encrypt() use the key as first argument ...
>> so maybe do the same here, too, for consistency?
> 
> For single-block AES, there's indeed already aes_encrypt(key, dst, src)
> and aes_decrypt(key, dst, src).  But for actual AEAD encryption there's
> already:
> 
>      chacha20poly1305_encrypt(dst, src, src_len, ad, ad_len, nonce, key)
>      chacha20poly1305_decrypt(dst, src, src_len, ad, ad_len, nonce, key)
>      xchacha20poly1305_encrypt(dst, src, src_len, ad, ad_len, nonce, key)
>      xchacha20poly1305_decrypt(dst, src, src_len, ad, ad_len, nonce, key)
>      chacha20poly1305_encrypt_sg_inplace(src, src_len, ad, ad_len, nonce, key)
>      chacha20poly1305_decrypt_sg_inplace(src, src_len, ad, ad_len, nonce, key)
> 
> Those follow the convention described by Jason here:
> https://lore.kernel.org/linux-crypto/aPT3dImhaI6Dpqs7@zx2c4.com/

Ok, makes sense now, thanks for the explanation! Feel free to add my:

Reviewed-by: Thomas Huth <thuth@redhat.com>

to this patch if you like.

> Note that if we decide we like this order, we could reorder the
> arguments of aes_encrypt() and aes_decrypt() to match.
Yes, maybe a good idea for more consistency in the code...

  Thomas