[noise] half-duplex protocols

[Trevor Perrin]

On Fri, Aug 11, 2017 at 3:01 PM, David Wong <davidwong.crypto at gmail.com> wrote:
> In the context of half-duplex protocols were the initiator and the
> responder are taking turns to send messages on the channel, it would
> make sense not to use a Split function but continue to use the
> CipherState as is.
>
> The Split function is called in WriteMessage and ReadMessage at the very end:
>
>> If there are no more message patterns returns two new CipherState objects by calling Split().
>
> I'm not sure how to modify this, maybe just as an advanced feature?
>
> (I'm asking in the context of the Disco extension where Strobe works
> really well for half-duplex protocols)

Good question, you could also look at BLINKER, one of the inspirations
behind Strobe (note the names), which focuses on the half-duplex case
IIRC.

Anyways, it might be better to call Split(), but just have both
parties take turns using the first CipherState output from Split
(which means the second doesn't need to be calculated).

One reason is that security proofs in Bellare-Rogaway style are
probably easier if the handshake phase outputs keys which are
indistinguishable from random.  But if the output key(s) are also used
for encryption during the handshake phase then they are no longer
indistinguishable to an adversary who has observed the handshake.
This is sort of a "proof artifact" and technicality, but I think it
makes Noise easier to analyze.

Also, from a software layering / API perspective, it seems more
consistent to view the handshake as outputing keys from Split(). and
then allow people to use these keys in different ways.

I agree we could discuss this in the core spec as an advanced use.


Trevor