[noise] PerformHandshake() Function

[dawuud]

To better explain the sans IO concept here's a talk from PyCon:

Cory Benfield - Building Protocol Libraries The Right Way - PyCon 2016
https://www.youtube.com/watch?v=7cC3_jGwl_U

Might we learn something from the Python community even if we dislike
the python language?  Some of the Rust community might be doing it
wrong by implementing protocols twice; as asynchronous and then as
blocking IO. Your proposition to implement a handshake function has
totally ignore this important issue and I'm guessing it's because you
have lately been implementing things in golang which only gives
developers access to blocking IO semantics.

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