[noise] PerformHandshake() Function

[Nadim Kobeissi]

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.

Nadim Kobeissi
Symbolic Software • https://symbolic.software
Sent from office


On Mon, Jun 3, 2019 at 8:01 PM Loup Vaillant David <loup at loup-vaillant.fr>
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20190603/8cf79954/attachment.html>