netdev - [PATCH 0/6] crypto: api - Add support for cloning tfms

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-next>] [day] [month] [year] [list]

Date:   Thu, 13 Apr 2023 14:23:00 +0800
From:   Herbert Xu <herbert@...dor.apana.org.au>
To:     Linux Crypto Mailing List <linux-crypto@...r.kernel.org>
Cc:     David Ahern <dsahern@...nel.org>,
        Eric Dumazet <edumazet@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>,
        Jakub Kicinski <kuba@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Dmitry Safonov <dima@...sta.com>,
        Andy Lutomirski <luto@...capital.net>,
        Ard Biesheuvel <ardb@...nel.org>,
        Bob Gilligan <gilligan@...sta.com>,
        Dan Carpenter <error27@...il.com>,
        David Laight <David.Laight@...lab.com>,
        Dmitry Safonov <0x7f454c46@...il.com>,
        Eric Biggers <ebiggers@...nel.org>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Francesco Ruggeri <fruggeri05@...il.com>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        Ivan Delalande <colona@...sta.com>,
        Leonard Crestez <cdleonard@...il.com>,
        Salam Noureddine <noureddine@...sta.com>,
        netdev@...r.kernel.org
Subject: [PATCH 0/6] crypto: api - Add support for cloning tfms

Over the years, various networking-related users have needed
per-packet keys for hashing (and potentially for ciphers because
hashing can be derived from ciphers, e.g., CMAC).

Currently this is impossible to do with the Crypto API for two
reasons.  Each key is tied to a tfm object, which cannot be
allocated on the network data path (as it requires sleeping).
Secondly, various drivers rely on the fact that setkey is usually
done right after allocating a tfm object and therefore sleep in
their setkey functions.

This series tries to resolve this by making it possible to clone
an existing tfm object, thus making it possible to allocate new
tfms on the data path.

To do so you simply call crypto_clone_ahash/shash on an existing
tfm object.  Afterwards you may call setkey on it as usual.

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt