[noise] Noise+Strobe=Disco

[David Wong]

> Cool, seems fairly simple to implement SymmetricState and CipherState
> in terms of STROBE, though Split() needs more detail (e.g. Appendix
> C.1 of Mike's paper).

Good catch! This probably is a better way as it zeros out the rest of the rate.
Looking at KMAC, this is kind of what they do, they absorb the key
then pad the rest of the rate with zeros.

> I think we're interested in lots of extensions (post-quantum,
> signatures, more 0-RTT modes, PAKE, more patterns, more crypto
> functions, etc).  We've been discussing how to change our document(s)
> and process to support a core of stable features as well as extensions
> (see "Document structure" threads).

I see. In the end it is a framework protocol. (Although I have to
agree with the sentiment you got from RWC. What would drive adoption
are specific protocols built from Noise and available in different
programming languages.)

In that sense, I think it would be a good idea to pursue Disco as an
extension of the Noise protocol framework. I'll look at these threads
and see how I can draft something that looks like an extension (right
now I'm thinking at RFCs that extend TLS). Are there any existing
extensions documents I should be aware of?

> Not really convinced, your spec just copies most of the Noise spec,
> which you'd probably want to keep in sync as we continue to extend
> things.

Oh this is just a PoC to see what Noise would look like if it just
used the sponge.
I have no intention to make it real, first because it is just a copy,
second because who would want to maintain a sync as you say :)
On the other hand I know that you have no intention of doing this as
well. This was really just a thought experiment.

> The AGL posts I'm thinking of were discussing runtime negotiation,
> which is a little different from a framework with lots of options that
> protocol designers select from (but which aren't negotiated at
> runtime).

That's true.

> There's a fairly clear interface between the protocol layer of Noise
> (the naming / pattern / tokens) and the symmetric layer
> (SymmetricState and CipherState).
>
> If we're clearer about this interface than we can allow these layers
> to evolve independently, so people can innovate in symmetric crypto
> while inheriting all of Noise's protocol features, and vice versa.

I can agree with that.

> My short-term, concrete interests are figuring out:
> - Any changes needed to the SymmetricState and CipherState APIs to
> acommodate them being re-implemented like this.
> - Any changes needed to the naming scheme needed for this.
>
> I think such changes should be pretty minimal and surgical in the
> Noise spec, so we could potentially put them in the next spec revision
> in a week or two.  After that, I'd like to think about how to refactor
> the documentation to make it easier to work on extensions like this.
>
> So those are the questions I'll be thinking about, next few weeks.

I understand. If I can help, I'll recap what I think would make the
integration of Strobe easier (and maybe future SymmetricState
objects):

1. Merge the SymmetricState and CipherState into one object called the
SymmetricState.
2. Make the SymmetricState an interchangeable part (kind of like what
you did with DH, HASH, ENCRYPT, DECRYPT, ...)
3. Do not define h, ck and the CipherState variables in the interface
of SymmetricState. These should be SymmetricState-specific internal
variables. (In the end this would mimic Golang's interface, you can
only specify functions they have to implement, not variables.)
4. Have Split() create a new interchangeable object that are called
something else than a xxxxxState . It's currently named CipherState, I
propose to name it SecureChannel. Have that object respect the
following interface: Write(), Read(), Rekey()

How does that sound?

David