<div dir="ltr">I see. Thank you Loup and Dawuud for explaining this tradeoff, I no longer think that this function should exist in the specification for the reasons you have both mentioned.<br clear="all"><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><br></div><div dir="ltr">Nadim Kobeissi<div>Symbolic Software <span style="color:rgb(84,84,84);font-size:small">• <a href="https://symbolic.software" target="_blank">https://symbolic.software</a></span></div><div><span style="color:rgb(84,84,84);font-size:small">Sent from office</span></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 3, 2019 at 8:01 PM Loup Vaillant David <<a href="mailto:loup@loup-vaillant.fr">loup@loup-vaillant.fr</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">I have the same problem with Monokex, and Monocypher, and Libsodium has<br>
the same problem. We cannot implement such a "handshake" function<br>
without losing portability. We'd have to touch network APIs, which most<br>
likely means writing a network layer for every supported platform. This<br>
is such a portability nightmare, we might as well import libevent.<br>
<br>
That's why Noise, Libsodium, etc. stick to shuffling bits around. This<br>
minimises portability issues, *and* let users chose how they wish do do<br>
networking. (For instance, they could add crypto to an existing network<br>
layer.)<br>
<br>
We do need that network layer, and it would be very nice if users could<br>
pick one of the shelf instead of writing their own. But that's likely a<br>
separate project.<br>
<br>
Loup.<br>
<br>
<br>
On Mon, 2019-06-03 at 13:33 +0000, dawuud wrote:<br>
> Since Katzenpost uses Noise XX we have ourselves a function called<br>
> handshake.<br>
> Upon returns it means that both parties have performed the handshake.<br>
> <br>
> <br>
<a href="https://github.com/katzenpost/core/blob/master/wire/session.go#L140-L289" rel="noreferrer" target="_blank">https://github.com/katzenpost/core/blob/master/wire/session.go#L140-L289</a><br>
> <br>
> If the noise library were to perform this function then it would have<br>
> to<br>
> take ownership of the connection type whereas it specifically avoids<br>
> this by design.<br>
> <br>
> I guess by synchronous you mean usage of blocking IO symantics which<br>
> is all golang is capable of.<br>
> However Rust programmers had better be writing their protocols in a<br>
> sans-IO manner so that they<br>
> can accomodate async IO as well as blocking IO.<br>
> <br>
> <br>
> On Mon, Jun 03, 2019 at 02:56:48PM +0200, Nadim Kobeissi wrote:<br>
> > Hello everyone,<br>
> > <br>
> > In working with Noise implementations in production, we noticed<br>
> > something interesting: inside the HandshakeState object, the<br>
> > following functions currently exist:<br>
> > <br>
> >     - Initialize(handshake_pattern, initiator, prologue, s, e, rs,<br>
> > re): initializes the state machine locally.<br>
> >     - WriteMessage(payload, message_buffer): writes a message with<br>
> > an optional payload.<br>
> >     - ReadMessage(payload, message_buffer): reads a message as<br>
> > written using the above function.<br>
> > <br>
> > In addition to the above, it may be useful to add a new<br>
> > “PerformHandshake()” function. The simple goal of this function<br>
> > would be to advance the local Noise Handshake Pattern state machine<br>
> > of both parties to the point where they have dealt with all<br>
> > handshake messages and where the next message to be sent will be a<br>
> > transport message.<br>
> > <br>
> > The usefulness of “PerformHandshake()” is in contexts where both<br>
> > parties can afford to perform a synchronous round-trip key exchange<br>
> > without issue. Imagine we are deploying IKpsk2 in a use case where<br>
> > both parties are expected to be online always. In that scenario, it<br>
> > is in both the initiator and the responder’s benefit to arrive to<br>
> > the transport message stage of the protocol as quickly as possible<br>
> > since transport messages will benefit from stronger confidentiality<br>
> > and authentication guarantees, and so calling “PerformHandshake()”<br>
> > before transmitting any real payloads of actual value could be<br>
> > beneficial.<br>
> > <br>
> > Predictable question: “Why not leave this up to the implementer to<br>
> > do manually?”<br>
> > Answer: this actually seems to be a pretty common use case scenario<br>
> > from my experience. By implementing it directly within the Noise<br>
> > Protocol Framework specification, we can avoid an additional burden<br>
> > on users where they can also potentially get things wrong. We also<br>
> > make it easier for implementers to have a more user-friendly “out<br>
> > of the box” experience once a Noise implementation is prepared.<br>
> > <br>
> > I’m not set on the name and so of course we can call this function<br>
> > anything we like in the event that this proposal garners popular<br>
> > support.<br>
> > <br>
> > Interested to hear your thoughts,<br>
> > <br>
> > Nadim Kobeissi<br>
> > Symbolic Software • <a href="https://symbolic.software" rel="noreferrer" target="_blank">https://symbolic.software</a><br>
> > Sent from office<br>
> > <br>
> > _______________________________________________<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>
> <br>
> _______________________________________________<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>
<br>
</blockquote></div>