<div dir="ltr">Hi Trevor,<div><br>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.</div><div><br></div><div>Jason<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 26, 2015 at 5:33 PM, Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> - "KDF(k, n, input): Takes a cipher key and nonce and some input data<br>
> and returns a new cipher key. The KDF should call GETKEY(k, n) to<br>
> generate an internal key and then provide a PRF when keyed by the<br>
> internal key." ... "KDF(k, n, input): HMAC-SHA2-512(GETKEY(k, n),<br>
> input). The first 32 bytes of output are used as the new k."<br>
><br>
> This seems new from previous drafts I read. What's the reasoning?<br>
> Where does HKDF not do the trick? In previous revisions I recall you<br>
> doing a similar counter operation to HKDF. Now there's a construction<br>
> involving encryption?<br>
<br>
</span>Good question.<br>
<br>
Previously Noise tracked the encryption key (aka "cipher context") and<br>
"chaining variable" separately.  New DHs would be combined with<br>
previous CC through a KDF and output a new "CC" and "CV".  The CC<br>
would be used for encrypting, and the CV would be input for later KDF.<br>
<br>
I've tried to simplify and replace CC and CV with a single secret<br>
variable 'k', which is a cipher key, and 'n', a nonce.  K and n are<br>
used for encryption, and to absorb a new DH output you do:<br>
<br>
k = HMAC-SHA2-256(PRF(k, n), <new_dh>)<br>
n = 0<br>
<br>
PRF(k, n) : encrypt a block of zeros and take first 32 bytes.<br>
<br>
The rationale for PRF is that the cipher key k shouldn't be fed<br>
directly into a different crypto algorithm.  So we repurpose the<br>
encryption algorithm to get a value derived from k.  The definition of<br>
PRF allows reusing the encryption function, or short-cutting it and<br>
just calling ChaCha20 or AES directly to ignore the MAC.<br>
<br>
So 'k' is serving both to accumulate DH and as a cipher key.  I'm<br>
tentatively adding a requirement that k be at least 256 bits and that<br>
KDF be collision-resistant, unless I can convince myself that's not<br>
necessary.<br><br></blockquote></div>
</div></div></div>