<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Oct 9, 2016 at 6:57 AM, Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">To derive an "additional" key or pair of keys, do:<br>
  ki : initiator's post-handshake encryption key<br>
  name : ASCII string zero-padded to 32 bytes<br>
  K = ENCRYPT(ki, nonce=2^64-1, ad=zerolen, plaintext=zeros[32])[0..32]<br>
  return HKDF(K, name)<br></blockquote><div><br></div><div>Why does the name need to be padded?  The hash that HKDF is based on will pad anyway.  Then the name can be arbitrary-length.<br><br></div><div>I was thinking that rather than the PSK being the "resumption key", "K" could be the resumption key from which the PSK's are generated for follow-up sessions:<br><br></div><div>    PSK = HKDF(K, name || nonce)<br></div><div><br></div>Where "nonce" is a randomly generated value and/or timestamp sent as part of the prologue for the new session.  I was thinking that, but then I realised that the PSK is already nonce'd with the initiator's ephemeral public key.  So, ignore that. :-)<br><br></div><div class="gmail_quote">However, my thought experiment does imply that "name" or parts thereof may not be known until the new session starts if it contains session-specific context:<br><br><div>    PSK = HKDF(K, name || context)<br></div><div></div><br>So "K" might be the resumption key after all.<br></div><div class="gmail_quote"><br></div></div><div class="gmail_extra">Cheers,<br><br></div><div class="gmail_extra">Rhys.<br><br></div></div>