From: Stephan Mueller <smueller@chronox.de>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
Andy Lutomirski <luto@amacapital.net>,
"Lee, Chun-Yi" <joeyli.kernel@gmail.com>,
"Rafael J . Wysocki" <rjw@rjwysocki.net>,
Pavel Machek <pavel@ucw.cz>,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
keyrings@vger.kernel.org,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Chen Yu <yu.c.chen@intel.com>, Oliver Neukum <oneukum@suse.com>,
Ryan Chen <yu.chen.surf@gmail.com>,
David Howells <dhowells@redhat.com>,
Giovanni Gherdovich <ggherdovich@suse.cz>,
Randy Dunlap <rdunlap@infradead.org>,
Jann Horn <jannh@google.com>, Andy Lutomirski <luto@kernel.org>,
linux-crypto@vger.kernel.org
Subject: Re: [PATCH 4/6] crypto: hkdf - RFC5869 Key Derivation Function
Date: Mon, 14 Jan 2019 19:44:22 +0100 [thread overview]
Message-ID: <1693060.JDmgY16SMQ@tauon.chronox.de> (raw)
In-Reply-To: <20190114175315.GB7644@gmail.com>
Am Montag, 14. Januar 2019, 18:53:16 CET schrieb Eric Biggers:
Hi Eric,
> > I would not suggest this, because that rounds contrary to the concept of
> > the kernel crypto API IMHO. The caller has to provide the wrapping
> > cipher. It is perfectly viable to allow a caller to invoke a specific
> > keyed message digest.
> Sure, but it would not conform to the HKDF specification. Are you sure it
> is okay to specify an arbitrary keyed hash?
Technically, I see no issue why this should not be possible. You see that with
the SP800-108 KDF implementations where using CMAC is perfectly legal (and
which I also test).
Though, using another keyed hash implementation like CMAC is not covered by
the HKDF spec. If a caller would use hkdf(cmac(aes)), it would produce
cryptographically strong values. Though this implementation does not conform
to any standard. I do not think we should prevent a caller to select such
combination in the kernel crypto API.
IMHO there would even be valid reasons why one would use cmac(aes) for a kdf.
For example, when you would want to use a hardware AES which somehow also
employs a hardware key that is inaccessible to software in order to tie the
KDF result to the local hardware. This could even be a valid use case for Ext4
FBE encryption where you derive a key. The KDF could be used to link the
derived key to the local hardware to prevent the encrypted data could be
copied to another system and decrypted successfully there.
Ciao
Stephan
WARNING: multiple messages have this Message-ID (diff)
From: Stephan Mueller <smueller@chronox.de>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
Andy Lutomirski <luto@amacapital.net>,
"Lee, Chun-Yi" <joeyli.kernel@gmail.com>,
"Rafael J . Wysocki" <rjw@rjwysocki.net>,
Pavel Machek <pavel@ucw.cz>,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
keyrings@vger.kernel.org,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Chen Yu <yu.c.chen@intel.com>, Oliver Neukum <oneukum@suse.com>,
Ryan Chen <yu.chen.surf@gmail.com>,
David Howells <dhowells@redhat.com>,
Giovanni Gherdovich <ggherdovich@suse.cz>,
Randy Dunlap <rdunlap@infradead.org>,
Jann Horn <jannh@google.com>, Andy Lutomirski <luto@kernel.org>,
linux-crypto@vger.kernel.org
Subject: Re: [PATCH 4/6] crypto: hkdf - RFC5869 Key Derivation Function
Date: Mon, 14 Jan 2019 18:44:22 +0000 [thread overview]
Message-ID: <1693060.JDmgY16SMQ@tauon.chronox.de> (raw)
In-Reply-To: <20190114175315.GB7644@gmail.com>
Am Montag, 14. Januar 2019, 18:53:16 CET schrieb Eric Biggers:
Hi Eric,
> > I would not suggest this, because that rounds contrary to the concept of
> > the kernel crypto API IMHO. The caller has to provide the wrapping
> > cipher. It is perfectly viable to allow a caller to invoke a specific
> > keyed message digest.
> Sure, but it would not conform to the HKDF specification. Are you sure it
> is okay to specify an arbitrary keyed hash?
Technically, I see no issue why this should not be possible. You see that with
the SP800-108 KDF implementations where using CMAC is perfectly legal (and
which I also test).
Though, using another keyed hash implementation like CMAC is not covered by
the HKDF spec. If a caller would use hkdf(cmac(aes)), it would produce
cryptographically strong values. Though this implementation does not conform
to any standard. I do not think we should prevent a caller to select such
combination in the kernel crypto API.
IMHO there would even be valid reasons why one would use cmac(aes) for a kdf.
For example, when you would want to use a hardware AES which somehow also
employs a hardware key that is inaccessible to software in order to tie the
KDF result to the local hardware. This could even be a valid use case for Ext4
FBE encryption where you derive a key. The KDF could be used to link the
derived key to the local hardware to prevent the encrypted data could be
copied to another system and decrypted successfully there.
Ciao
Stephan
next prev parent reply other threads:[~2019-01-14 19:18 UTC|newest]
Thread overview: 181+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-03 14:32 [PATCH 0/5 v2][RFC] Encryption and authentication for hibernate snapshot image Lee, Chun-Yi
2019-01-03 14:32 ` Lee, Chun-Yi
2019-01-03 14:32 ` [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler Lee, Chun-Yi
2019-01-03 14:32 ` Lee, Chun-Yi
2019-01-06 8:01 ` Stephan Mueller
2019-01-06 8:01 ` Stephan Mueller
2019-01-06 8:25 ` Stephan Mueller
2019-01-06 8:25 ` Stephan Mueller
2019-01-07 15:33 ` joeyli
2019-01-07 15:33 ` joeyli
2019-01-07 15:52 ` Stephan Mueller
2019-01-07 15:52 ` Stephan Mueller
2019-01-08 5:03 ` Herbert Xu
2019-01-08 5:03 ` Herbert Xu
2019-01-08 7:09 ` Stephan Mueller
2019-01-08 7:09 ` Stephan Mueller
2019-01-08 23:54 ` Andy Lutomirski
2019-01-08 23:54 ` Andy Lutomirski
2019-01-09 0:44 ` James Bottomley
2019-01-09 0:44 ` James Bottomley
2019-01-09 0:44 ` James Bottomley
2019-01-09 1:43 ` Andy Lutomirski
2019-01-09 1:43 ` Andy Lutomirski
2019-01-09 6:49 ` James Bottomley
2019-01-09 6:49 ` James Bottomley
2019-01-09 18:11 ` joeyli
2019-01-09 18:11 ` joeyli
2019-01-11 15:53 ` Jarkko Sakkinen
2019-01-11 15:53 ` Jarkko Sakkinen
2019-01-09 18:34 ` Andy Lutomirski
2019-01-09 18:34 ` Andy Lutomirski
2019-01-09 19:46 ` James Bottomley
2019-01-09 19:46 ` James Bottomley
2019-01-09 20:12 ` Andy Lutomirski
2019-01-09 20:12 ` Andy Lutomirski
2019-01-09 21:43 ` James Bottomley
2019-01-09 21:43 ` James Bottomley
2019-01-09 22:19 ` Pavel Machek
2019-01-09 22:19 ` Pavel Machek
2019-01-11 16:04 ` Jarkko Sakkinen
2019-01-11 16:04 ` Jarkko Sakkinen
2019-01-11 14:02 ` Jarkko Sakkinen
2019-01-11 14:02 ` Jarkko Sakkinen
2019-01-11 15:28 ` James Bottomley
2019-01-11 15:28 ` James Bottomley
2019-01-18 14:33 ` Jarkko Sakkinen
2019-01-18 14:33 ` Jarkko Sakkinen
2019-01-18 20:59 ` James Bottomley
2019-01-18 20:59 ` James Bottomley
2019-01-20 16:02 ` Jarkko Sakkinen
2019-01-20 16:02 ` Jarkko Sakkinen
2019-01-09 6:45 ` Stephan Mueller
2019-01-09 6:45 ` Stephan Mueller
2019-01-09 6:58 ` James Bottomley
2019-01-09 6:58 ` James Bottomley
2019-01-09 7:05 ` Stephan Mueller
2019-01-09 7:05 ` Stephan Mueller
2019-01-09 8:21 ` Eric Biggers
2019-01-09 8:21 ` Eric Biggers
2019-01-09 10:17 ` Stephan Mueller
2019-01-09 10:17 ` Stephan Mueller
2019-01-09 17:34 ` Eric Biggers
2019-01-09 17:34 ` Eric Biggers
2019-01-09 18:18 ` Stephan Mueller
2019-01-09 18:18 ` Stephan Mueller
2019-01-11 19:08 ` [PATCH 0/6] General Key Derivation Function Support Stephan Müller
2019-01-11 19:08 ` Stephan Müller
2019-01-11 19:09 ` [PATCH 1/6] crypto: add template handling for RNGs Stephan Müller
2019-01-11 19:09 ` Stephan Müller
2019-01-11 19:10 ` [PATCH 2/6] crypto: kdf - SP800-108 Key Derivation Function Stephan Müller
2019-01-11 19:10 ` Stephan Müller
2019-01-12 5:27 ` Eric Biggers
2019-01-12 5:27 ` Eric Biggers
2019-01-14 9:31 ` Stephan Müller
2019-01-14 9:31 ` Stephan Müller
2019-01-11 19:10 ` [PATCH 3/6] crypto: kdf - add known answer tests Stephan Müller
2019-01-11 19:10 ` Stephan Müller
2019-01-12 5:26 ` Eric Biggers
2019-01-12 5:26 ` Eric Biggers
2019-01-14 9:26 ` Stephan Müller
2019-01-14 9:26 ` Stephan Müller
2019-01-11 19:10 ` [PATCH 4/6] crypto: hkdf - RFC5869 Key Derivation Function Stephan Müller
2019-01-11 19:10 ` Stephan Müller
2019-01-12 5:12 ` Eric Biggers
2019-01-12 5:12 ` Eric Biggers
2019-01-12 9:55 ` Herbert Xu
2019-01-12 9:55 ` Herbert Xu
2019-01-13 7:56 ` Stephan Müller
2019-01-13 7:56 ` Stephan Müller
2019-01-13 16:52 ` James Bottomley
2019-01-13 16:52 ` James Bottomley
2019-01-14 9:30 ` Stephan Müller
2019-01-14 9:30 ` Stephan Müller
2019-01-14 17:53 ` Eric Biggers
2019-01-14 17:53 ` Eric Biggers
2019-01-14 18:44 ` Stephan Mueller [this message]
2019-01-14 18:44 ` Stephan Mueller
2019-01-11 19:10 ` [PATCH 5/6] crypto: hkdf - add known answer tests Stephan Müller
2019-01-11 19:10 ` Stephan Müller
2019-01-12 5:19 ` Eric Biggers
2019-01-12 5:19 ` Eric Biggers
2019-01-14 9:25 ` Stephan Müller
2019-01-14 9:25 ` Stephan Müller
2019-01-14 17:44 ` Eric Biggers
2019-01-14 17:44 ` Eric Biggers
2019-01-11 19:11 ` [PATCH 6/6] crypto: tcrypt - add KDF test invocation Stephan Müller
2019-01-11 19:11 ` Stephan Müller
2019-01-16 11:06 ` [PATCH v2 0/6] General Key Derivation Function Support Stephan Müller
2019-01-16 11:06 ` Stephan Müller
2019-01-16 11:07 ` [PATCH v2 1/6] crypto: add template handling for RNGs Stephan Müller
2019-01-16 11:07 ` Stephan Müller
2019-01-16 11:08 ` [PATCH v2 2/6] crypto: kdf - SP800-108 Key Derivation Function Stephan Müller
2019-01-16 11:08 ` Stephan Müller
2019-01-16 11:08 ` [PATCH v2 3/6] crypto: kdf - add known answer tests Stephan Müller
2019-01-16 11:08 ` Stephan Müller
2019-01-16 11:08 ` [PATCH v2 4/6] crypto: hkdf - HMAC-based Extract-and-Expand KDF Stephan Müller
2019-01-16 11:08 ` Stephan Müller
2019-01-16 11:09 ` [PATCH v2 5/6] crypto: hkdf - add known answer tests Stephan Müller
2019-01-16 11:09 ` Stephan Müller
2019-01-16 11:09 ` [PATCH v2 6/6] crypto: tcrypt - add KDF test invocation Stephan Müller
2019-01-16 11:09 ` Stephan Müller
2019-01-28 10:07 ` [PATCH v2 0/6] General Key Derivation Function Support Stephan Mueller
2019-01-28 10:07 ` Stephan Mueller
2019-01-30 10:08 ` Herbert Xu
2019-01-30 10:08 ` Herbert Xu
2019-01-30 14:39 ` Stephan Mueller
2019-01-30 14:39 ` Stephan Mueller
2019-02-08 7:45 ` Herbert Xu
2019-02-08 7:45 ` Herbert Xu
2019-02-08 8:00 ` Stephan Mueller
2019-02-08 8:00 ` Stephan Mueller
2019-02-08 8:05 ` Herbert Xu
2019-02-08 8:05 ` Herbert Xu
2019-02-08 8:17 ` Stephan Mueller
2019-02-08 8:17 ` Stephan Mueller
2019-02-19 5:44 ` Herbert Xu
2019-02-19 5:44 ` Herbert Xu
2019-01-09 15:34 ` [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler James Bottomley
2019-01-09 15:34 ` James Bottomley
2019-01-09 6:27 ` Stephan Mueller
2019-01-09 6:27 ` Stephan Mueller
2019-01-03 14:32 ` [PATCH 2/5] PM / hibernate: Generate and verify signature for snapshot image Lee, Chun-Yi
2019-01-03 14:32 ` Lee, Chun-Yi
2019-01-06 8:09 ` Stephan Mueller
2019-01-06 8:09 ` Stephan Mueller
2019-01-07 18:58 ` Dan Carpenter
2019-01-07 18:58 ` Dan Carpenter
2019-01-03 14:32 ` [PATCH 3/5] PM / hibernate: Encrypt " Lee, Chun-Yi
2019-01-03 14:32 ` Lee, Chun-Yi
2019-01-06 8:23 ` Stephan Mueller
2019-01-06 8:23 ` Stephan Mueller
2019-01-03 14:32 ` [PATCH 4/5 v2] PM / hibernate: Erase the snapshot master key in snapshot pages Lee, Chun-Yi
2019-01-03 14:32 ` Lee, Chun-Yi
2019-01-03 14:32 ` [PATCH 5/5 v2] PM / hibernate: An option to request that snapshot image must be authenticated Lee, Chun-Yi
2019-01-03 14:32 ` Lee, Chun-Yi
2019-01-06 18:10 ` [PATCH 0/5 v2][RFC] Encryption and authentication for hibernate snapshot image Pavel Machek
2019-01-06 18:10 ` Pavel Machek
2019-01-07 17:37 ` joeyli
2019-01-07 17:37 ` joeyli
2019-01-07 18:07 ` Pavel Machek
2019-01-07 18:07 ` Pavel Machek
2019-01-08 21:41 ` Andy Lutomirski
2019-01-08 21:41 ` Andy Lutomirski
2019-01-08 23:42 ` Pavel Machek
2019-01-08 23:42 ` Pavel Machek
2019-01-09 16:39 ` joeyli
2019-01-09 16:39 ` joeyli
2019-01-09 16:47 ` Stephan Mueller
2019-01-09 16:47 ` Stephan Mueller
2019-01-11 14:29 ` joeyli
2019-01-11 14:29 ` joeyli
2019-01-09 16:51 ` joeyli
2019-01-09 16:51 ` joeyli
2019-01-09 18:47 ` Andy Lutomirski
2019-01-09 18:47 ` Andy Lutomirski
2019-01-10 15:12 ` joeyli
2019-01-10 15:12 ` joeyli
2019-01-11 1:09 ` Andy Lutomirski
2019-01-11 1:09 ` Andy Lutomirski
2019-01-11 14:59 ` joeyli
2019-01-11 14:59 ` joeyli
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=1693060.JDmgY16SMQ@tauon.chronox.de \
--to=smueller@chronox.de \
--cc=James.Bottomley@hansenpartnership.com \
--cc=dhowells@redhat.com \
--cc=ebiggers@kernel.org \
--cc=ggherdovich@suse.cz \
--cc=herbert@gondor.apana.org.au \
--cc=jannh@google.com \
--cc=joeyli.kernel@gmail.com \
--cc=keyrings@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=luto@kernel.org \
--cc=oneukum@suse.com \
--cc=pavel@ucw.cz \
--cc=rafael.j.wysocki@intel.com \
--cc=rdunlap@infradead.org \
--cc=rjw@rjwysocki.net \
--cc=yu.c.chen@intel.com \
--cc=yu.chen.surf@gmail.com \
/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.