----- Ursprüngliche Mail ----- > Von: "Herbert Xu" <herb...@gondor.apana.org.au> > An: "richard" <rich...@nod.at> > CC: "Linux Crypto Mailing List" <linux-crypto@vger.kernel.org>, > linux-arm-ker...@lists.infradead.org, "linux-kernel" > <linux-ker...@vger.kernel.org>, linux-...@nxp.com, feste...@gmail.com, > "kernel" <ker...@pengutronix.de>, "Sascha Hauer" > <s.ha...@pengutronix.de>, shawn...@kernel.org, da...@davemloft.net, "david" > <da...@sigma-star.at> > Gesendet: Donnerstag, 30. Mai 2019 04:33:57 > Betreff: Re: [RFC PATCH 1/2] crypto: Allow working with key references
> On Thu, May 30, 2019 at 12:48:43AM +0200, Richard Weinberger wrote: >> Some crypto accelerators allow working with secure or hidden keys. >> This keys are not exposed to Linux nor main memory. To use them >> for a crypto operation they are referenced with a device specific id. >> >> This patch adds a new flag, CRYPTO_TFM_REQ_REF_KEY. >> If this flag is set, crypto drivers should tread the key as >> specified via setkey as reference and not as regular key. >> Since we reuse the key data structure such a reference is limited >> by the key size of the chiper and is chip specific. >> >> TODO: If the cipher implementation or the driver does not >> support reference keys, we need a way to detect this an fail >> upon setkey. >> How should the driver indicate that it supports this feature? >> >> Signed-off-by: Richard Weinberger <rich...@nod.at> > > We already have existing drivers doing this. Please have a look > at how they're doing it and use the same paradigm. You can grep > for paes under drivers/crypto. Thanks for the pointer. So the preferred way is defining a new crypto algorithm prefixed with "p" and reusing setkey to provide the key reference. Thanks, //richard