From: Tom Rini <trini@konsulko.com>
To: Philippe REYNES <philippe.reynes@softathome.com>
Cc: Peter Robinson <pbrobinson@gmail.com>,
sjg@chromium.org, abdellatif.elkhlifi@arm.com,
u-boot@lists.denx.de
Subject: Re: [PATCH 1/4] lib: sha256: add feature sha256_hmac
Date: Wed, 17 Jul 2024 11:58:06 -0600 [thread overview]
Message-ID: <20240717175806.GS561963@bill-the-cat> (raw)
In-Reply-To: <e874bdd7-273e-465e-8516-3207db9ea245@softathome.com>
[-- Attachment #1: Type: text/plain, Size: 1655 bytes --]
On Wed, Jul 17, 2024 at 07:08:27PM +0200, Philippe REYNES wrote:
> Hi Peter,
>
> Le 16/07/2024 à 18:56, Peter Robinson a écrit :
> > This Mail comes from Outside of SoftAtHome: Do not answer, click links or open attachments unless you recognize the sender and know the content is safe.
> >
> > Hi Philippe,
> >
> > It might be useful to have a cover letter explaining what the plans
> > for this code are, great that there are tests but adding code in
> > without it being used isn't always a feature so a cover letter with
> > some details often helps with the context.
>
> You right, I should have added a cover letter.
> My goal was to add key derivation and use this feature to fill a key
> manager,
> and then provide those keys (or some of them) to the kernel. So the kernel
> may (for example) add them in the KRS.
>
> Do you know if there are some work or interest in a key manager for u-boot
> please ?
>
> >
> > Also if you're not aware there's work to integrate MBedTLS [1] and I'm
> > not sure if that also may provide the functionality.
>
> Good point, I miss it. MBedTLS has the feature of key derivation.
> https://mbed-tls.readthedocs.io/en/latest/getting_started/psa/#deriving-a-new-key-from-an-existing-key
> So unless someone wants to use key derivation without all MBedTLS,
> this serie is not very useful.
Unless you object, I would really prefer to have this been a feature
U-Boot only has with MBedTLS enabled as one of the goals with that
integration is to have U-Boot leverage existing and well
audited/monitored codebases for security sensitive code paths when
possible.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
next prev parent reply other threads:[~2024-07-17 17:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-16 15:06 [PATCH 1/4] lib: sha256: add feature sha256_hmac Philippe Reynes
2024-07-16 15:06 ` [PATCH 2/4] test: lib: add test for sha256_hamc Philippe Reynes
2024-09-20 16:01 ` Simon Glass
2024-07-16 15:06 ` [PATCH 3/4] lib: sha256: add support of key derivation Philippe Reynes
2024-09-20 16:01 ` Simon Glass
2024-07-16 15:06 ` [PATCH 4/4] test: lib: add test for " Philippe Reynes
2024-09-20 16:01 ` Simon Glass
2024-07-16 16:56 ` [PATCH 1/4] lib: sha256: add feature sha256_hmac Peter Robinson
2024-07-17 17:08 ` Philippe REYNES
2024-07-17 17:58 ` Tom Rini [this message]
2024-07-23 13:45 ` Philippe REYNES
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240717175806.GS561963@bill-the-cat \
--to=trini@konsulko.com \
--cc=abdellatif.elkhlifi@arm.com \
--cc=pbrobinson@gmail.com \
--cc=philippe.reynes@softathome.com \
--cc=sjg@chromium.org \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox