[noise] Noise+Strobe=Disco

[Trevor Perrin]

On Mon, Jun 19, 2017 at 10:41 AM, David Wong <davidwong.crypto at gmail.com> wrote:
>
> In the end what I did was replacing the SymmetricState with Strobe,
> and not making use of a CipherState. Which meant removing the
> SymmetricState's ck, h and CipherState variables; and re-mapping its
> functions to Strobe's ones:
>
> MixHash -> AD()
> InitializeSymmetric(protocol_name) -> InitializeStrobe(protocol_name)
> MixKey -> KEY()
> MixKeyAndHash -> KEY()
> EncryptAndHash -> send_AEAD()
> DecryptAndHash -> recv_AEAD()
> Split -> something that creates two Strobe State with Clone() and KEY()
>
> So to make Noise accept this kind of thing by default, you could make
> SymmetricState an interface without enforcing its h, ck and
> CipherState variables. Then you could define the current
> SymmetricState+CipherState as one instance of a SymmetricState in a
> different section, along with the Strobe's one.
>
> I would also go and define Split() to return two objects called
> CommunicationChannel or something (rather than SomethingState, it's
> not really a state anymore) and with the following interface:
>
> InitializeKey() -> KEY()
> WriteWithAd() -> send_AEAD()
> ReadWithAd() -> send_AEAD()
> Rekey() -> RATCHET()

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


> I figured this would be too much of a change for you to be interested
> in extending Noise this way.
> I can see several reasons why this is a bad idea:
>
> 1. Noise's specification is good right now, I don't think it needs to
> be extended. Rather it needs stability and a lot of available
> implementations.

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


> 2. Disco could have a much cleaner/shorter spec on its own.

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.


> 3. I'm not really in favor of cryptographic extensibility (see TLS or
> Adam Langley's posts).

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


> What are your reasons for extending here?

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 do not really have a direction in mind. I like the idea of having a
> shorter spec + shorter code which is why I  think Disco could stand on
> its own. I like the idea of instantiating Noise with Strobe as well
> and I'be interested to hear what your ideas are if we would take this
> as an opportunity to extend the spec of Noise.

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.

Trevor