From: Eric Biggers <ebiggers@kernel.org>
To: Stephan Mueller <smueller@chronox.de>
Cc: herbert@gondor.apana.org.au, mathew.j.martineau@linux.intel.com,
dhowells@redhat.com, linux-crypto@vger.kernel.org,
linux-fscrypt@vger.kernel.org, linux-kernel@vger.kernel.org,
keyrings@vger.kernel.org
Subject: Re: [PATCH 5/5] fs: use HKDF implementation from kernel crypto API
Date: Thu, 7 Jan 2021 10:47:56 -0800 [thread overview]
Message-ID: <X/dXXEThAgankGIG@gmail.com> (raw)
In-Reply-To: <a32b424e18672300ed4a72cade1dbbfd0d5bd6a5.camel@chronox.de>
On Thu, Jan 07, 2021 at 08:49:52AM +0100, Stephan Mueller wrote:
> > > -int fscrypt_init_hkdf(struct fscrypt_hkdf *hkdf, const u8 *master_key,
> > > +int fscrypt_init_hkdf(struct fscrypt_hkdf *hkdf, u8 *master_key,
> > > unsigned int master_key_size);
> >
> > It shouldn't be necessary to remove const here.
>
> Unfortunately it is when adding the pointer to struct kvec
> >
> > >
> > > /*
> > > @@ -323,7 +323,7 @@ int fscrypt_init_hkdf(struct fscrypt_hkdf *hkdf, const
> > > u8 *master_key,
> > > #define HKDF_CONTEXT_INODE_HASH_KEY 7 /* info=<empty> */
> > >
> > > int fscrypt_hkdf_expand(const struct fscrypt_hkdf *hkdf, u8 context,
> > > - const u8 *info, unsigned int infolen,
> > > + u8 *info, unsigned int infolen,
> > > u8 *okm, unsigned int okmlen);
> >
> > Likewise. In fact some callers rely on 'info' not being modified.
>
> Same here.
If the HKDF API will have a quirk like this, it's better not to "leak" it into
the prototypes of these fscrypt functions. Just add the needed casts in
fscrypt_init_hkdf() and fscrypt_hkdf_expand().
> > > - err = crypto_shash_setkey(hmac_tfm, prk, sizeof(prk));
> > > + err = crypto_hkdf_setkey(hmac_tfm, seed, ARRAY_SIZE(seed));
> > > if (err)
> > > goto err_free_tfm;
> >
> > It's weird that the salt and key have to be passed in a kvec.
> > Why not just have normal function parameters like:
> >
> > int crypto_hkdf_setkey(struct crypto_shash *hmac_tfm,
> > const u8 *key, size_t keysize,
> > const u8 *salt, size_t saltsize);
>
> I wanted to have an identical interface for all types of KDFs to allow turning
> them into a template eventually. For example, SP800-108 KDFs only have one
> parameter. Hence the use of a kvec.
But the API being provided is a library function specifically for HKDF.
So there's no need to make it conform to some other API.
- Eric
next prev parent reply other threads:[~2021-01-07 18:48 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-04 21:45 [PATCH 0/5] Add KDF implementations to crypto API Stephan Müller
2021-01-04 21:47 ` [PATCH 1/5] crypto: Add key derivation self-test support code Stephan Müller
2021-01-04 21:47 ` [PATCH 2/5] crypto: add SP800-108 counter key derivation function Stephan Müller
2021-01-04 21:49 ` [PATCH 3/5] crypto: add RFC5869 HKDF Stephan Müller
2021-01-07 7:30 ` Eric Biggers
2021-01-07 7:53 ` Stephan Mueller
2021-01-07 18:53 ` Eric Biggers
2021-01-04 21:49 ` [PATCH 4/5] security: DH - use KDF implementation from crypto API Stephan Müller
2021-01-12 1:34 ` Jarkko Sakkinen
2021-01-04 21:50 ` [PATCH 5/5] fs: use HKDF implementation from kernel " Stephan Müller
2021-01-07 7:19 ` Eric Biggers
2021-01-07 7:49 ` Stephan Mueller
2021-01-07 18:47 ` Eric Biggers [this message]
2021-01-04 22:20 ` [PATCH 0/5] Add KDF implementations to " Eric Biggers
2021-01-07 6:37 ` Stephan Mueller
2021-01-07 6:59 ` Eric Biggers
2021-01-07 7:12 ` Eric Biggers
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=X/dXXEThAgankGIG@gmail.com \
--to=ebiggers@kernel.org \
--cc=dhowells@redhat.com \
--cc=herbert@gondor.apana.org.au \
--cc=keyrings@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathew.j.martineau@linux.intel.com \
--cc=smueller@chronox.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.