[prev in list] [next in list] [prev in thread] [next in thread]
List: ietf-tls
Subject: Re: [TLS] HKDF
From: Hugo Krawczyk <hugo () ee ! technion ! ac ! il>
Date: 2015-03-24 17:29:15
Message-ID: CADi0yUOwxpuKWJCsVx65ZuzBr2ipj2ScGW-HTavLLQDKVXA5iw () mail ! gmail ! com
[Download RAW message or body]
Here are some clarifications about HKDF that can help better understanding
its
rationale and use in (OP)TLS.
Note: all places where I say random it can (and sometimes should) be
replaced by
pseudo-random meaning indistinguishable from a uniform random string.
- HKDF is standardized by NIST (as an *approved* KDF mechanism) in
SP-800-56C
where it is explicitly stated that HKDF complies with this standard:
"IETF RFC 5869 [10] describes an instantiation of the above
extraction-then-expansion key derivation procedure using HMAC for the
extraction and expansion steps. For extensive rationale on the key
derivation
through the extraction-then-expansion procedure specified in this
Recommendation see [11]." For those interested, [11] appeared in Crypto
2010
and is here http://eprint.iacr.org/2010/264.
- HKDF uses a two-step mechanism by which one first extracts randomness
from a
possibly non-uniform secret input to create a uniformly random string
that is
then used with a regular PRF to generate keying material. In (OP)TLS we
denote
the two steps as HKDF-Extract and HKDF-Expand. The rationale of the
extraction
part is to concentrate the "secret entropy" of the input on a single
strong
cryptographic key (from which more keys can be derived).
- HKDF uses HMAC for both extract and expand but it could use, in
principle, any
regular PRF (including those from NIST) for expansion. Extraction is
trickier
since it is not a generic property of PRFs. The reason to use HMAC for it
is
that the HMAC construction has properties that support the extraction
functionality under reasonable cryptographic assumptions.
- Skipping the extraction property would require keying a PRF with a
non-uniform
key in which case the usual properties of PRF cannot be guaranteed as
these
properties assume a uniform random key. In TLS with RSA this was not a
problem
since the key transported under RSA was chosen as a random uniform string.
When using a DH key or passphrase this is not the case.
- Beyond the important cryptographic reasons for the extraction step, this
also
solves the problem of having to adapt the size of the secret input to
that of
a length of the key in the PRF: for example, how do you key AES-256 with a
point on a 512 elliptic curve? Even with a 256 curve you would require
point
compression which you may or may not want to use (I hope this comment
does not
open a discussion of EC point representations :-).
- The expansion function of HKDF is HMAC-based and is ESSENTIALLY THE SAME
as in
previous TLS. It even has the same feedback mode that TLS uses to expand
a key
(the exact inputs to the iterations changes a bit but nothing major).
- There is no need for ultimate performance in the key derivation in TLS.
These
operations are relative minor compared to the algebraic operations.
- There is nothing that ties HKDF to OPTLS in a fundamental way other than
it
supports the provability of the protocol, hence improving the confidence
on
its design. In particular, it supports a clean hierarchical key
derivation for
all the protocol modes.
Hugo
On Tue, Mar 24, 2015 at 8:16 AM, Ilari Liusvaara <
ilari.liusvaara@elisanet.fi> wrote:
> On Tue, Mar 24, 2015 at 06:39:43AM -0500, Yoav Nir wrote:
> >
> > > On Mar 24, 2015, at 1:01 AM, Andrey Jivsov <crypto@brainhub.org>
> wrote:
> > >
> > > Please note that at least some of these can be FIPS 140 tested (in
> particular, TLS PRF). Suite B expects the use of these approved KDFs.
> > >
> > > While NIST is perhaps too prolific with these, I feel that we should
> look into standard KDFs. There are test vectors, verifications systems,
> existing implementations…
> >
> > If such a KDF is needed for Suite-B, then it makes sense for Suite-B
> ciphersuites - the ones with ECDSA, P-256 or P-384 for ECDHE, and AES-GCM.
> >
> > Why not include a different PRF in those suites that have
> non-NIST-approved algorithms such as ChaCha20, Curve25519, and whatever
> signature scheme CFRG are going to recommend?
>
> Or even special Suite B ciphersuites. I think there are only 2 of
> those.
>
> - ECDHE/P-256, ECDSA/P-256, AES-128-GCM, SHA-256
> - ECDHE/P-384, ECDSA/P-384, AES-256-GCM, SHA-384
>
> The basic idea being: They who care can implement that.
>
>
> -Ilari
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
[Attachment #3 (text/html)]
<div dir="ltr"><div class="gmail_default" \
style="font-family:verdana,sans-serif;font-size:small">Here are some \
clarifications about HKDF that can help better understanding its<br>rationale and use \
in (OP)TLS.<br><br>Note: all places where I say random it can (and sometimes should) \
be replaced by<br>pseudo-random meaning indistinguishable from a uniform random \
string.<br><br>- HKDF is standardized by NIST (as an *approved* KDF mechanism) in \
SP-800-56C<br> where it is explicitly stated that HKDF complies with this standard: \
<br> "IETF RFC 5869 [10] describes an instantiation of the above<br> \
extraction-then-expansion key derivation procedure using HMAC for the<br> \
extraction and expansion steps. For extensive rationale on the key derivation<br> \
through the extraction-then-expansion procedure specified in this<br> \
Recommendation see [11]." For those interested, [11] appeared in Crypto 2010<br> \
and is here <a href="http://eprint.iacr.org/2010/264" \
target="_blank">http://eprint.iacr.org/2010/264</a>.<br><br>- HKDF uses a two-step \
mechanism by which one first extracts randomness from a<br> possibly non-uniform \
secret input to create a uniformly random string that is<br> then used with a \
regular PRF to generate keying material. In (OP)TLS we denote<br> the two steps as \
HKDF-Extract and HKDF-Expand. The rationale of the extraction<br> part is to \
concentrate the "secret entropy" of the input on a single strong<br> \
cryptographic key (from which more keys can be derived).<br><br>- HKDF uses HMAC for \
both extract and expand but it could use, in principle, any<br> regular PRF \
(including those from NIST) for expansion. Extraction is trickier<br> since it is \
not a generic property of PRFs. The reason to use HMAC for it is<br> that the HMAC \
construction has properties that support the extraction<br> functionality under \
reasonable cryptographic assumptions.<br><br>- Skipping the extraction property would \
require keying a PRF with a non-uniform<br> key in which case the usual properties \
of PRF cannot be guaranteed as these<br> properties assume a uniform random key. In \
TLS with RSA this was not a problem<br> since the key transported under RSA was \
chosen as a random uniform string.<br> When using a DH key or passphrase this is \
not the case. <br> <br>- Beyond the important cryptographic reasons for the \
extraction step, this also<br> solves the problem of having to adapt the size of \
the secret input to that of<br> a length of the key in the PRF: for example, how do \
you key AES-256 with a<br> point on a 512 elliptic curve? Even with a 256 curve you \
would require point<br> compression which you may or may not want to use (I hope \
this comment does not<br> open a discussion of EC point representations \
:-).<br><br>- The expansion function of HKDF is HMAC-based and is ESSENTIALLY THE \
SAME as in<br> previous TLS. It even has the same feedback mode that TLS uses to \
expand a key<br> (the exact inputs to the iterations changes a bit but nothing \
major).<br><br>- There is no need for ultimate performance in the key derivation in \
TLS. These<br> operations are relative minor compared to the algebraic \
operations.<br><br>- There is nothing that ties HKDF to OPTLS in a fundamental way \
other than it<br> supports the provability of the protocol, hence improving the \
confidence on<br> its design. In particular, it supports a clean hierarchical key \
derivation for<br> all the protocol modes.<br> <br>Hugo<br></div><br><div \
class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 24, 2015 at 8:16 AM, \
Ilari Liusvaara <span dir="ltr"><<a href="mailto:ilari.liusvaara@elisanet.fi" \
target="_blank">ilari.liusvaara@elisanet.fi</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><span class="">On Tue, Mar 24, 2015 at 06:39:43AM -0500, Yoav \
Nir wrote:<br> ><br>
> > On Mar 24, 2015, at 1:01 AM, Andrey Jivsov <<a \
href="mailto:crypto@brainhub.org">crypto@brainhub.org</a>> wrote:<br> > \
><br> </span><span class="">> > Please note that at least some of these can \
be FIPS 140 tested (in particular, TLS PRF). Suite B expects the use of these \
approved KDFs.<br> > ><br>
> > While NIST is perhaps too prolific with these, I feel that we should look \
into standard KDFs. There are test vectors, verifications systems, existing \
implementations…<br> ><br>
> If such a KDF is needed for Suite-B, then it makes sense for Suite-B \
ciphersuites - the ones with ECDSA, P-256 or P-384 for ECDHE, and AES-GCM.<br> \
><br> > Why not include a different PRF in those suites that have \
non-NIST-approved algorithms such as ChaCha20, Curve25519, and whatever signature \
scheme CFRG are going to recommend?<br> <br>
</span>Or even special Suite B ciphersuites. I think there are only 2 of<br>
those.<br>
<br>
- ECDHE/P-256, ECDSA/P-256, AES-128-GCM, SHA-256<br>
- ECDHE/P-384, ECDSA/P-384, AES-256-GCM, SHA-384<br>
<br>
The basic idea being: They who care can implement that.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
-Ilari<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
TLS mailing list<br>
<a href="mailto:TLS@ietf.org">TLS@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/tls" \
target="_blank">https://www.ietf.org/mailman/listinfo/tls</a><br> \
</div></div></blockquote></div><br></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic