[PATCH net-next v2] xfrm: add ARIA CBC and CTR support

[PATCH net-next v2] xfrm: add ARIA CBC and CTR support

[Hong In-su]

The kernel crypto API already provides ARIA implementations, but XFRM
does not have algorithm descriptors for them. Consequently, ARIA cannot
be selected for ESP through XFRM.

Add XFRM algorithm descriptors for CBC and RFC3686 CTR modes using the
existing cbc(aria) and rfc3686(ctr(aria)) crypto algorithms.

The CBC and CTR modes have been tested with IPsec using strongSwan.

Signed-off-by: Hong In-su <his1415@pribit.com>
---
Changes in v2:
- Drop the duplicate "aria" compatibility alias from the CTR entry.
- Use a 128-bit default key size for CBC.
- Document that the CTR default key size includes the 32-bit nonce.

v1: https://lore.kernel.org/netdev/20260909054530.7861-1-his1415@pribit.com/

 net/xfrm/xfrm_algo.c | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/net/xfrm/xfrm_algo.c b/net/xfrm/xfrm_algo.c
index 70434495f23f..7ed84220ad5d 100644
--- a/net/xfrm/xfrm_algo.c
+++ b/net/xfrm/xfrm_algo.c
@@ -512,6 +512,33 @@ static struct xfrm_algo_desc ealg_list[] = {
 		.sadb_alg_maxbits = 256
 	}
 },
+{
+	.name = "cbc(aria)",
+	.compat = "aria",
+
+	.uinfo = {
+		.encr = {
+			.geniv = "echainiv",
+			.blockbits = 128,
+			.defkeybits = 128,
+		}
+	},
+
+	.pfkey_supported = 0,
+},
+{
+	.name = "rfc3686(ctr(aria))",
+
+	.uinfo = {
+		.encr = {
+			.geniv = "seqiv",
+			.blockbits = 128,
+			.defkeybits = 160, /* 128-bit key + 32-bit nonce */
+		}
+	},
+
+	.pfkey_supported = 0,
+},
 {
 	.name = "cbc(twofish)",
 	.compat = "twofish",
-- 
2.43.0

Re: [PATCH net-next v2] xfrm: add ARIA CBC and CTR support

[Sabrina Dubroca]

Note: for IPsec patches, the subject prefix should be [PATCH ipsec] or
[PATCH ipsec-next] instead of net/net-next (with the same
bugfix/feature split).

2026-09-16, 02:31:35 +0000, Hong In-su wrote:
> The kernel crypto API already provides ARIA implementations, but XFRM
> does not have algorithm descriptors for them. Consequently, ARIA cannot
> be selected for ESP through XFRM.
> 
> Add XFRM algorithm descriptors for CBC and RFC3686 CTR modes using the
> existing cbc(aria) and rfc3686(ctr(aria)) crypto algorithms.

Why only those, and not for example gcm(aria)? (just to mention one
that I know is a "valid" combination, since it's used in ktls, but I
guess all the combinations that are supported for AES would also be
valid)

> The CBC and CTR modes have been tested with IPsec using strongSwan.
> 
> Signed-off-by: Hong In-su <his1415@pribit.com>
> ---
> Changes in v2:
> - Drop the duplicate "aria" compatibility alias from the CTR entry.
> - Use a 128-bit default key size for CBC.
> - Document that the CTR default key size includes the 32-bit nonce.
> 
> v1: https://lore.kernel.org/netdev/20260909054530.7861-1-his1415@pribit.com/
> 
>  net/xfrm/xfrm_algo.c | 27 +++++++++++++++++++++++++++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/net/xfrm/xfrm_algo.c b/net/xfrm/xfrm_algo.c
> index 70434495f23f..7ed84220ad5d 100644
> --- a/net/xfrm/xfrm_algo.c
> +++ b/net/xfrm/xfrm_algo.c
> @@ -512,6 +512,33 @@ static struct xfrm_algo_desc ealg_list[] = {
>  		.sadb_alg_maxbits = 256
>  	}
>  },
> +{
> +	.name = "cbc(aria)",
> +	.compat = "aria",

I missed v1 and the bot's feedback, but I'm wondering: Steffen, do we
still want to add "compat" names for new algorithms? SM3/SM4 are the
only additions post-2010 that got an alias. It saves a few characters
on the way in, and then we get the full name back during dumps, which
is probably more confusing than helpful.

-- 
Sabrina