<div dir="ltr">yes.<div>actually, there might be a better option. If i send the _responder_ static key in prelude we get some minimal identity hiding because the responder key changes frequently.<div></div></div><div><br></div><div>however, i'm unsure about the security implications because  noise never sends the responder static anywhere for precedent.</div><div>Does an  attacker gain any advantage by knowing the public key for the responder? Is it easier to break then maybe since they can also observe the 0RTT payload encrypted for that recipient?<br></div><div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 19, 2021 at 3:08 PM Filippo Valsorda <<a href="mailto:filippo@ml.filippo.io">filippo@ml.filippo.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u><div><div>Sounds like what you want is KK with the initiator's s in the prologue.<br></div><div><br></div><div>You obviously lose all initiator identity hiding, but otherwise it should have the same payload properties as regular KK.<br></div><div><br></div><div>2021-05-19 14:07 GMT+02:00 Arvid Picciani <<a href="mailto:aep%40exys.org" target="_blank">aep@exys.org</a>>:<br></div><blockquote type="cite" id="gmail-m_-6952365238181194308qt"><div dir="ltr"><div>In order to not share the responder static key between multiple servers,<br></div><div>i am considering creating a responder key per initiator.<br></div><div>the responder key is then loaded hot only when needed and can be revoked more fine grained.<br></div><div><br></div><div>This would require the responder to know which key to load. The current IK pattern has the initiator static encrypted with the responder static, so i can't look up the matching receiver keys.<br></div><div><br></div><div>I could just use IX , but i actually want encrypted 0RTT payload,<br></div><div><br></div><div>so something like<br></div><div><br></div><div>XIK:<br></div><div>      <- s<br></div><div>      ...<br></div><div>      -> s, ss, e, es<br></div><div>      <- e, ee, se<br></div><div><br></div><div>i'm assuming 0RTT payload has the same protection as IK, i.e. Source 1 and Destination 2,<br></div><div>except it looses identity hiding, as that's kind of the point<br></div><div><br></div><div>is this correct?<br></div><div><br></div><div>thanks,<br></div><div>Arvid<br></div><div><br></div><div>--<br></div><div>+4916093821054<br></div></div><div>_______________________________________________<br></div><div>Noise mailing list<br></div><div><a href="mailto:Noise%40moderncrypto.org" target="_blank">Noise@moderncrypto.org</a><br></div><div><a href="https://moderncrypto.org/mailman/listinfo/noise" target="_blank">https://moderncrypto.org/mailman/listinfo/noise</a><br></div><div><br></div></blockquote><div><br></div></div>_______________________________________________<br>
Noise mailing list<br>
<a href="mailto:Noise@moderncrypto.org" target="_blank">Noise@moderncrypto.org</a><br>
<a href="https://moderncrypto.org/mailman/listinfo/noise" rel="noreferrer" target="_blank">https://moderncrypto.org/mailman/listinfo/noise</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">+4916093821054</div>