[noise] Disco objects (was Re: spectemplate / spectools)

[David Wong]

> I guess "DiscoSecureChannel" doesn't update its StrobeState?  That's
> could be clearer.

Good catch! There's nothing mentionning this. I'll fix.


> Not sure about the different handling for out-of-order vs in-order
> protocols.  Could you not just use the out-of-order approach always,
> since it's the most general and works for everything?

This is definitely not the approach I'll be implementing since I like
the simplicity of the in-order approach of Strobe. Since Strobe's
forte is definitely not out-of-order I don't think this should be made
the default here.


> The relationship between SymmetricState / CipherState and your objects
> (StrobeState, DiscoSecureChannel) is somewhat confusing.  E.g., I
> guess StrobeState functions as either an internal object to a modified
> SymmetricState, or as a CipherState equivalent, but it doesn't
> re-implement all the CipherState functions (e.g. to understand how
> transport encryption works I have to read the text in Section 4).

Correct, StrobeState is an internal object to a modified SymmetricState.
I don't know how I could make the transport encryption phase clearer,
maybe having a section on how to handle transport encryption? This is
by the way one of the suggestion I had for the Noise's spec itself:
have a post-handshake section. For the moment I assume an implementer
will:

1. look at section 3 (The StrobeState object) and make sure to have a
good API for Strobe
2. look at section 4 (Modifications to the Handshake State) and
understand that the handshake will be returning different objects,
that will be used differently to encrypt application data during the
post-handshake phase
3. look at section 5 (Modifications to the Symmetric State) and apply
the modifications to make Disco work

If you look at the section 6.3 now (Out-of-order transport messages):

1. look at 6.3.1 and modify the Split() function of SymmetricState
2. look at 6.3.2 and implement the DiscoSecureChannel object

Maybe these two need to be reversed?


> If possible, it would seem better to have something like:
>  * A single "DiscoSymmetricState" that re-implements all the
> SymmetricState functions

I'm already re-implementing all the SymmetricState functions. Or did I
miss some? If you mean I could get rid of the StrobeState, I need the
API to interact with Strobe.

>  * A single "DiscoCipherState" that re-implements all the CipherState functions

See my thoughts on why I didn't do this in "[noise] spectemplate /
spectools" on the list. Thinking more about it, I could have a section
on "Modifications to the CipherState" and mention in the beginning
that this is only used for out-of-order protocols. I would
re-implement most functions except InitializeKey() and HasKey().

What about that? It sounds cleaner.

David