<div dir="ltr"><div class="gmail_default" style="font-size:small">On Thu, Oct 5, 2017 at 3:02 PM, Ron Garret <span dir="ltr"><<a href="mailto:ron@flownet.com" target="_blank">ron@flownet.com</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div><div><span class="gmail-"><div>On Oct 5, 2017, at 9:50 AM, Phillip Hallam-Baker <<a href="mailto:phill@hallambaker.com" target="_blank">phill@hallambaker.com</a>> wrote:</div><br class="gmail-m_-8267910182253072290Apple-interchange-newline"></span><div><div class="gmail-h5"><br></div></div></div><span class="gmail-"><div>If it’s helpful, I wrote a Javascript reference implementation of the Signal double-ratchet:<div><br></div><div><a href="https://github.com/rongarret/ratchet-js/" target="_blank">https://github.com/rongarret/<wbr>ratchet-js/</a></div><div><br></div><div>For session-based comms like real-time chat I think it’s probably worthwhile.  For asynchronous comms, probably not so much.  IMHO.</div></div></span></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">​What I am looking into doing right now is specifying the rekey mechanism as follows:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><div class="gmail_default">* One of the outputs of the HKDF function is a 'RekeySalt' value</div></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">* Rekey Messages are authenticated and optionally encrypted under the previous session key</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">* The RekeySalt value is the salt for the next HKDF Expand.</div></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">One of the peculiarities of the key agreement mechanisms that I am looking at is that they all seem to be fixated on use of signatures for a key agreement. Why not use a key agreement for a key agreement?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Both sides contribute an ephemeral key and an identity key, Bam, done!</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Both sides are protected against perfidy by the other if they choose a random ephemeral. It doesn't even need to be secret to protect against small subgroup games.<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div></div></div></div>