<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><br></div><div><div><div>On Oct 5, 2017, at 9:50 AM, Phillip Hallam-Baker <<a href="mailto:phill@hallambaker.com">phill@hallambaker.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_default" style="font-size:small">I am reading the double ratched docs again, trying to see if there is any real advantage over just doing a rekey.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">My basic key exchange is to use a 3 or 4 way DH as follows (ignoring the mod p part)</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Sender has long term credential {a, e^a} creates an ephemeral {x, e^x}. Sends public keys e^a, e^x to recipient.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Receiver has long term credential {b, e^b}, optionally creates an ephemeral {y, e^y}. Sends public keys e^b, e^y to recipient plus a witness value</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Shared secret is s=KDF(e^abxy, m), witness value is KDF(e^abxy, w)</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Receiver also replies with an opaque identifier for the connection of up to 1Kb (or so) which may be kerberos ticket style.</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">I am anticipating a situation where Alice and Bob might have tens of different encrypted streams between them simultaneously. They might have a couple of web cams, a chat, shared desktop, etc. Some or all of these may be across different device pairs.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Yes, I can do the ratchet but it seems to me that it is not buying me a great deal that I can't get better by using the old ticket and shared session key to get a new ticket and session key.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I can always do s_n+_1 = KDF(e^abxy+s_n, m)</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">But what is that really buying me? I cannot expect every party to keep state on every possible sender/receiver pair. So an attacker can always say 'lets set up a completely new session'.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">My protocol already has forward secrecy as the client and server both contribute a nonce per key exchange and discard it.</div></div></blockquote><br></div><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/">https://github.com/rongarret/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><div><br></div><div>rg</div><div><br></div><br></div></body></html>