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: <881550786.93213.1600206653402.JavaMail.zimbra@nod.at>
Date:   Tue, 15 Sep 2020 23:50:53 +0200 (CEST)
From:   Richard Weinberger <richard@....at>
To:     horia geanta <horia.geanta@....com>
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>,
        linux-imx <linux-imx@....com>, david <david@...ma-star.at>
Subject: Re: [PATCH 2/2] crypto: caam - support tagged keys for skcipher
 algorithms

----- 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.

Do you have git repo with the WIP patches available?
Not that we do the work twice. :-)
Our patch series also supports DCP beside of CAAM.

Thanks,
//richard

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ