<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 12, 2017 at 6:44 PM, 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;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">

 (B) One party can just transmit a PSK to the other.  There's some<br>
subtlety in that you might want to "channel-bind" the PSK by hashing<br>
it with the handshake-hash, or using the handshake-hash as prologue<br>
when such a PSK is used for resumption, to prevent PSKs being relayed<br>
between sessions.  But I'm thinking that might be OK, and transmitting<br>
the PSK gives flexibility to send multiple PSKs, and works well with<br>
rekey (since PSKs sent before a rekey will be protected by the rekey).<br></blockquote><div><br></div><div>My concern with transmitting the PSK's is that they are no longer "mutual" - the sending party solely determines the value.  And if that party's random number generator has become borked (e.g. accidentally or deliberately outputting all-zeroes), then the PSK value is essentially in the clear as the transmitted ciphertext.</div><div><br></div><div>What about this: modify Rekey() to return 64 bytes instead of 32.  The first 32 are used as the new transport key, and the second 32 can be exported from the protocol as a PSK if the protocol needs a PSK at that point.  If the protocol requires multiple PSK's, it can Rekey() multiple times before continuing with data transport.  Because the transport keys are already determined using a mutual process, the PSK will be mutual also.</div><div> </div><div>Cheers,</div><div><br></div><div>Rhys.<br></div></div></div></div>