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

[Trevor Perrin]

On Wed, Nov 15, 2017 at 10:56 AM, David Wong <davidwong.crypto at gmail.com> wrote:
>> 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.

Regarding "simplicity":  I think having two different modes (that need
to be spec'd, analyzed, implemented, and chosen between) is more
complicated than having a single mode.


>> 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?

If you implement the CipherState API you don't have to say anything
about the transport phase.  The Noise spec already explains how to use
CipherStates during the transport phase.


> 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

Wouldn't it be simpler if Split() returned objects that behaved the
same as CipherState?


> 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.

The Strobe spec already defines its operations (PRF, AD, recv_ENC,
etc), It still seems like you're unnecessarily repeating those
definitions in StrobeState.


>>  * 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.

I don't see there why you can't have a "DiscoCipherState" or
"DiscoSecureChannel" that implements the CipherState API exactly.


Trevor