LKML Archive on
help / color / mirror / Atom feed
From: Harald Freudenberger <>
To: Richard Weinberger <>,
	Herbert Xu <>
Cc: Linux Crypto Mailing List <>,,
	linux-kernel <>,,,
	kernel <>,
	Sascha Hauer <>,,,
	david <>
Subject: Re: [RFC PATCH 1/2] crypto: Allow working with key references
Date: Mon, 3 Jun 2019 09:59:53 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 30.05.19 09:23, Richard Weinberger wrote:
> ----- Ursprüngliche Mail -----
>> Von: "Herbert Xu" <>
>> An: "richard" <>
>> CC: "Linux Crypto Mailing List" <>,, "linux-kernel"
>> <>,,, "kernel" <>, "Sascha Hauer"
>> <>,,, "david" <>
>> 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 <>
>> 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.
The "p" in paes is because we call it "protected key aes". I think you are not limited
to the "p". What Herbert tries to point out is that you may define your own
cipher with an unique name and there you can handle your secure key references
as you like. You may use the s390 paes implementation as a starting point.

regards Harald Freudenberger <>

> Thanks,
> //richard

  reply	other threads:[~2019-06-03  8:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-29 22:48 Richard Weinberger
2019-05-29 22:48 ` [RFC PATCH 2/2] crypto: mxs-dcp: Implement reference keys Richard Weinberger
2019-05-30  2:33 ` [RFC PATCH 1/2] crypto: Allow working with key references Herbert Xu
2019-05-30  7:23   ` Richard Weinberger
2019-06-03  7:59     ` Harald Freudenberger [this message]
2019-06-03 14:15       ` Herbert Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [RFC PATCH 1/2] crypto: Allow working with key references' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).