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]
Date:   Tue, 10 Aug 2021 11:28:25 +0000
From:   David Gstir <david@...ma-star.at>
To:     Ahmad Fatoum <a.fatoum@...gutronix.de>
Cc:     Jarkko Sakkinen <jarkko@...nel.org>,
        Horia Geantă <horia.geanta@....com>,
        Mimi Zohar <zohar@...ux.ibm.com>,
        Aymen Sghaier <aymen.sghaier@....com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>,
        James Bottomley <jejb@...ux.ibm.com>,
        Jan Luebbe <j.luebbe@...gutronix.de>,
        Udit Agarwal <udit.agarwal@....com>,
        Sumit Garg <sumit.garg@...aro.org>,
        Eric Biggers <ebiggers@...nel.org>,
        Franck LENORMAND <franck.lenormand@....com>,
        Richard Weinberger <richard@....at>,
        James Morris <jmorris@...ei.org>, linux-kernel@...r.kernel.org,
        David Howells <dhowells@...hat.com>,
        linux-security-module@...r.kernel.org, keyrings@...r.kernel.org,
        linux-crypto@...r.kernel.org, kernel@...gutronix.de,
        linux-integrity@...r.kernel.org,
        Steffen Trumtrar <s.trumtrar@...gutronix.de>,
        "Serge E. Hallyn" <serge@...lyn.com>
Subject: Re: [PATCH 0/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys

Hi Ahmad,

> On 09.08.2021, at 12:16, Ahmad Fatoum <a.fatoum@...gutronix.de> wrote:

[...]

> If it interests you, I described[2] my CAAM+ubifs+fscrypt use case in the
> discussion thread on my fscrypt-trusted-keys v1. Jan, a colleague of mine, held a
> talk[3] on the different solutions for authenticated and encrypted storage, which
> you may want to check out.
>
> I'd really appreciate feedback here on the the CAAM parts of this series, so this can
> eventually go mainline.

Since you mention the fscrypt trusted-keys use case:

I noticed that the key length for trusted-keys is limited to
256 - 1024bit keys. fscrypt does however also support keys
with e.g. 128bit keys (AES-128-CBC-ESSIV, AES-128-CTS-CBC).
AFAIK, CAAM and TEE key blobs would also support key lengths outside the 256 - 1024bit range.

Wouldn’t it make sense to align the supported key lengths?
I.e. extend the range of supported key lengths for trusted keys.
Or is there a specific reason why key lengths below 256bit are
not supported by trusted-keys?

Cheers,
David


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ