[noise] KDF(GETKEY(..), ..) explanation

[Jason A. Donenfeld]

Hi Trevor,

While you're at it with adding things to the justification section of
Noise, I thought this answer below was very informative, particularly the
point about not putting k into a different algo.

Jason

On Fri, Jun 26, 2015 at 5:33 PM, Trevor Perrin <trevp at trevp.net> wrote:
>
> > - "KDF(k, n, input): Takes a cipher key and nonce and some input data
> > and returns a new cipher key. The KDF should call GETKEY(k, n) to
> > generate an internal key and then provide a PRF when keyed by the
> > internal key." ... "KDF(k, n, input): HMAC-SHA2-512(GETKEY(k, n),
> > input). The first 32 bytes of output are used as the new k."
> >
> > This seems new from previous drafts I read. What's the reasoning?
> > Where does HKDF not do the trick? In previous revisions I recall you
> > doing a similar counter operation to HKDF. Now there's a construction
> > involving encryption?
>
> Good question.
>
> Previously Noise tracked the encryption key (aka "cipher context") and
> "chaining variable" separately.  New DHs would be combined with
> previous CC through a KDF and output a new "CC" and "CV".  The CC
> would be used for encrypting, and the CV would be input for later KDF.
>
> I've tried to simplify and replace CC and CV with a single secret
> variable 'k', which is a cipher key, and 'n', a nonce.  K and n are
> used for encryption, and to absorb a new DH output you do:
>
> k = HMAC-SHA2-256(PRF(k, n), <new_dh>)
> n = 0
>
> PRF(k, n) : encrypt a block of zeros and take first 32 bytes.
>
> The rationale for PRF is that the cipher key k shouldn't be fed
> directly into a different crypto algorithm.  So we repurpose the
> encryption algorithm to get a value derived from k.  The definition of
> PRF allows reusing the encryption function, or short-cutting it and
> just calling ChaCha20 or AES directly to ignore the MAC.
>
> So 'k' is serving both to accumulate DH and as a cipher key.  I'm
> tentatively adding a requirement that k be at least 256 bits and that
> KDF be collision-resistant, unless I can convince myself that's not
> necessary.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20150901/1612a4b4/attachment.html>