[noise] PerformHandshake() Function
Loup Vaillant David
loup at loup-vaillant.fr
Mon Jun 3 11:01:02 PDT 2019
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
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
On Mon, 2019-06-03 at 13:33 +0000, dawuud wrote:
> Since Katzenpost uses Noise XX we have ourselves a function called
> Upon returns it means that both parties have performed the handshake.
> If the noise library were to perform this function then it would have
> 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
More information about the Noise