From: Eric Biggers <ebiggers3@gmail.com>
To: Michael Halcrow <mhalcrow@google.com>
Cc: linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-ext4@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-mtd@lists.infradead.org, linux-crypto@vger.kernel.org,
"Theodore Y . Ts'o" <tytso@mit.edu>,
Jaegeuk Kim <jaegeuk@kernel.org>, Alex Cope <alexcope@google.com>,
Eric Biggers <ebiggers@google.com>
Subject: Re: [PATCH 3/6] fscrypt: use HKDF-SHA512 to derive the per-inode encryption keys
Date: Wed, 19 Jul 2017 10:32:37 -0700 [thread overview]
Message-ID: <20170719173237.GA78811@gmail.com> (raw)
In-Reply-To: <20170714162440.GB25453@google.com>
On Fri, Jul 14, 2017 at 09:24:40AM -0700, Michael Halcrow wrote:
> > +static int hkdf_expand(struct crypto_shash *hmac, u8 context,
> > + const u8 *info, unsigned int infolen,
> > + u8 *okm, unsigned int okmlen)
> > +{
> > + SHASH_DESC_ON_STACK(desc, hmac);
> > + int err;
> > + const u8 *prev = NULL;
> > + unsigned int i;
> > + u8 counter = 1;
> > + u8 tmp[HKDF_HASHLEN];
> > +
> > + desc->tfm = hmac;
> > + desc->flags = 0;
> > +
> > + if (unlikely(okmlen > 255 * HKDF_HASHLEN))
> > + return -EINVAL;
> > +
> > + for (i = 0; i < okmlen; i += HKDF_HASHLEN) {
> > +
> > + err = crypto_shash_init(desc);
> > + if (err)
> > + goto out;
> > +
> > + if (prev) {
> > + err = crypto_shash_update(desc, prev, HKDF_HASHLEN);
> > + if (err)
> > + goto out;
> > + }
> > +
> > + err = crypto_shash_update(desc, &context, 1);
>
> One potential shortcut would be to just increment context on each
> iteration rather than maintain the counter.
>
That's not a good idea because then it wouldn't be standard HKDF, and it would
be relying on the "feedback" mode to keep the HMAC inputs unique which isn't
guaranteed to be sufficient.
> >
> > - res = validate_user_key(crypt_info, &ctx, raw_key, FS_KEY_DESC_PREFIX,
> > - keysize);
> > - if (res && inode->i_sb->s_cop->key_prefix) {
> > - int res2 = validate_user_key(crypt_info, &ctx, raw_key,
> > - inode->i_sb->s_cop->key_prefix,
> > - keysize);
> > - if (res2) {
> > - if (res2 == -ENOKEY)
> > - res = -ENOKEY;
> > + if (ctx.version == FSCRYPT_CONTEXT_V1) {
> > + res = find_and_derive_key_v1(inode, &ctx, derived_key,
> > + derived_keysize);
>
> Why not make this consistent with the else clause, i.e. doing
> load_master_key_from_keyring() followed by derive_key_v1()?
>
struct fscrypt_master_key contains the HMAC transform but not the raw master
key. For the v1 key derivation we need the raw master key. We could put it in
the fscrypt_master_key and then try to allow fscrypt_master_key's both with and
without HMAC transforms depending on the policy versions they are used for, but
there's no point in doing so currently.
Eric
next prev parent reply other threads:[~2017-07-19 17:32 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-12 21:00 [PATCH 0/6] fscrypt: key verification and KDF improvement Eric Biggers
2017-07-12 21:00 ` [PATCH 1/6] fscrypt: add v2 encryption context and policy Eric Biggers
2017-07-13 22:29 ` Michael Halcrow
2017-07-13 22:58 ` Eric Biggers
2017-07-14 20:08 ` Andreas Dilger
2017-07-12 21:00 ` [PATCH 2/6] fscrypt: rename ->ci_master_key to ->ci_master_key_descriptor Eric Biggers
2017-07-14 15:36 ` Michael Halcrow
2017-07-12 21:00 ` [PATCH 3/6] fscrypt: use HKDF-SHA512 to derive the per-inode encryption keys Eric Biggers
2017-07-13 14:54 ` Stephan Müller
2017-07-13 16:07 ` Herbert Xu
2017-07-13 16:18 ` Stephan Müller
2017-07-13 18:10 ` Eric Biggers
2017-07-14 15:50 ` Stephan Müller
2017-07-14 16:24 ` Michael Halcrow
2017-07-14 17:11 ` Michael Halcrow
2017-07-19 17:32 ` Eric Biggers [this message]
2017-07-12 21:00 ` [PATCH 4/6] fscrypt: verify that the correct master key was supplied Eric Biggers
2017-07-14 16:40 ` Michael Halcrow via Linux-f2fs-devel
2017-07-14 17:34 ` Jeffrey Walton
2017-07-15 0:52 ` Eric Biggers
2017-07-12 21:00 ` [PATCH 5/6] fscrypt: cache the HMAC transform for each master key Eric Biggers
2017-07-17 17:45 ` Michael Halcrow
2017-07-19 17:37 ` Eric Biggers
2017-07-12 21:00 ` [PATCH 6/6] fscrypt: for v2 policies, support "fscrypt:" key prefix only Eric Biggers
2017-07-17 17:54 ` Michael Halcrow
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=20170719173237.GA78811@gmail.com \
--to=ebiggers3@gmail.com \
--cc=alexcope@google.com \
--cc=ebiggers@google.com \
--cc=jaegeuk@kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=mhalcrow@google.com \
--cc=tytso@mit.edu \
/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;
as well as URLs for NNTP newsgroup(s).