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]
Message-Id: <14ffcdf2-ed9f-be07-fde5-62dfb1fce4f9@linux.ibm.com>
Date:   Mon, 3 Jun 2019 09:59:53 +0200
From:   Harald Freudenberger <freude@...ux.ibm.com>
To:     Richard Weinberger <richard@....at>,
        Herbert Xu <herbert@...dor.apana.org.au>
Cc:     Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        linux-arm-kernel@...ts.infradead.org,
        linux-kernel <linux-kernel@...r.kernel.org>, linux-imx@....com,
        festevam@...il.com, kernel <kernel@...gutronix.de>,
        Sascha Hauer <s.hauer@...gutronix.de>, shawnguo@...nel.org,
        davem@...emloft.net, david <david@...ma-star.at>
Subject: Re: [RFC PATCH 1/2] crypto: Allow working with key references

On 30.05.19 09:23, Richard Weinberger wrote:
> ----- Ursprüngliche Mail -----
>> Von: "Herbert Xu" <herbert@...dor.apana.org.au>
>> An: "richard" <richard@....at>
>> CC: "Linux Crypto Mailing List" <linux-crypto@...r.kernel.org>, linux-arm-kernel@...ts.infradead.org, "linux-kernel"
>> <linux-kernel@...r.kernel.org>, linux-imx@....com, festevam@...il.com, "kernel" <kernel@...gutronix.de>, "Sascha Hauer"
>> <s.hauer@...gutronix.de>, shawnguo@...nel.org, davem@...emloft.net, "david" <david@...ma-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 <richard@....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.
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 <freude@...ux.ibm.com>

>
> Thanks,
> //richard
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ