linux-kernel - Re: [PATCH 2/2] crypto: caam - support tagged keys for skcipher algorithms

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

Message-ID: <5acc982d-77b0-3141-2689-d35cc24e36fd@nxp.com>
Date:   Mon, 21 Sep 2020 14:23:51 +0300
From:   Horia Geantă <horia.geanta@....com>
To:     Richard Weinberger <richard@....at>
Cc:     Iuliana Prodan <iuliana.prodan@....com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Aymen Sghaier <aymen.sghaier@....com>,
        davem <davem@...emloft.net>,
        Silvano Di Ninno <silvano.dininno@....com>,
        Franck Lenormand <franck.lenormand@....com>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        dl-linux-imx <linux-imx@....com>, david <david@...ma-star.at>
Subject: Re: [PATCH 2/2] crypto: caam - support tagged keys for skcipher
 algorithms

On 9/16/2020 12:50 AM, Richard Weinberger wrote:
> ----- Ursprüngliche Mail -----
>> Von: "horia geanta" <horia.geanta@....com>
>>>> How to use it with cryptsetup?
>>>> I'm asking because it is not clear to me why you are not implementing
>>>> a new kernel key type (KEYS subsystem)
>>>> to utilize tagged keys.
>>>> Many tools already support the keyctl userspace interface (cryptsetup,
>>>> fscrypt, ...).
>>>
>>> *friendly ping*
>>>
>> We didn't include the key management part in this series,
>> just the crypto API support for algorithms with protected keys,
>> to get early feedback.
>>
>> Wrt. key management:
>> The NXP vendor / downstream kernel (to be included in i.MX BSP Q3 release)
>> will have support for protected keys generation.
>> Besides this, a dedicated ioctl-based interface will allow userspace to
>> generate and export these keys. After this, user can use standard keyctl
>> to add a key (as user / logon type) in the keyring, such that it would be
>> available to dm-crypt.
>>
>> We know that adding new ioctls is frowned upon, so before trying to upstream
>> the ioctl-based solution the plan is checking the feasibility of
>> extending keyctl as David Howells suggested:
>> https://lore.kernel.org/lkml/8060.1533226481@warthog.procyon.org.uk
>> (Note the difference b/w adding new key type - which was rejected -
>> and a key "subtype extension".)
> 
> We have also a keyctl based patch series which should go upstream.
> Since we also added a new keytype, it got rejected so far.
> 
Could you please point me to the discussion?

> Do you have git repo with the WIP patches available?
> Not that we do the work twice. :-)
Unfortunately we haven't developed any code yet.

> Our patch series also supports DCP beside of CAAM.
> 
By looking at the DCP capabilities, I assume the OTP key that is copied
in the key RAM at boot time is used as KEK.

If you don't mind sharing, I could review the code.

Thanks,
Horia