linux-kernel - Re: [PATCH 5/5] tcp/md5: Make more generic tcp_sig

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 5 Nov 2021 11:54:02 +0200
From:   Leonard Crestez <cdleonard@...il.com>
To:     Dmitry Safonov <dima@...sta.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        David Ahern <dsahern@...nel.org>,
        Eric Dumazet <edumazet@...gle.com>
Cc:     Dmitry Safonov <0x7f454c46@...il.com>,
        Andy Lutomirski <luto@...capital.net>,
        "David S. Miller" <davem@...emloft.net>,
        Francesco Ruggeri <fruggeri@...sta.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        linux-crypto@...r.kernel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/5] tcp/md5: Make more generic tcp_sig_pool

On 11/5/21 3:49 AM, Dmitry Safonov wrote:
> Convert tcp_md5sig_pool to more generic tcp_sig_pool.
> Now tcp_sig_pool_alloc(const char *alg) can be used to allocate per-cpu
> ahash request for different hashing algorithms besides md5.
> tcp_sig_pool_get() and tcp_sig_pool_put() should be used to get
> ahash_request and scratch area.

This pool pattern is a workaround for crypto-api only being able to 
allocate transforms from user context.

It would be useful for this "one-transform-per-cpu" object to be part of 
crypto api itself, there is nothing TCP-specific here other than the 
size of scratch buffer.

> Make tcp_sig_pool reusable for TCP Authentication Option support
> (TCP-AO, RFC5925), where RFC5926[1] requires HMAC-SHA1 and AES-128_CMAC
> hashing at least.
Additional work would be required to support options of arbitrary size 
and I don't think anyone would use non-standard crypto algorithms.

Is RFC5926 conformance really insufficient?

My knowledge of cryptography doesn't go much beyond "data goes in 
signature goes out" but there are many recent arguments from that cipher 
agility is outright harmful and recent protocols like WireGuard don't 
support any algorithm choices.

> +#define TCP_SIG_POOL_MAX		8
> +static struct tcp_sig_pool_priv_t {
> +	struct tcp_sig_crypto		cryptos[TCP_SIG_POOL_MAX];
> +	unsigned int			cryptos_nr;
> +} tcp_sig_pool_priv = {
> +	.cryptos_nr = 1,
> +	.cryptos[TCP_MD5_SIG_ID].alg = "md5",
> +};

Why an array of 8? Better to use an arbitrary list.

--
Regards,
Leonard