[noise] Noise+Strobe=Disco

[David Wong]

Hey! Thanks for the answer Trevor. Response inlined.

> One approach would be to consider something like STROBE as a different
> way of extending Noise.  I.e. instead of instantiating Noise with a
> cipher and hash, there would be an option to instantiate Noise with a
> SymmetricState and CipherState.  Then you could implement
> SymmetricState and CipherState with STROBE, or other sponge
> constructions, or something else entirely.
>
> We've anticipated this (which is why SymmetricState and CipherState
> are "object-oriented" APIs), but we haven't thought about it deeply.

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

Btw:

* send_AEAD() is not a Strobe function, but it could be. It's just
send_ENC followed by send_MAC.
* I also see that you're not using the Additional Data part so this
could really well have Write() and Read() instead.


> I'm not sure this is the road you want to take (you mention removing
> CipherState and SymmetricState instead of re-implementing them, and
> making something different from Noise, rather than extending it).  My
> interest, unsurprisingly, is more towards extending Noise.  What that
> would probably look like:

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.
2. Disco could have a much cleaner/shorter spec on its own.
3. I'm not really in favor of cryptographic extensibility (see TLS or
Adam Langley's posts). The point of Disco would be that everything
just use the same primitive.

For the second point, I made a PoC based on the Noise spec here:
https://github.com/mimoo/NoiseGo/blob/master/disco/disco.md

What are your reasons for extending here?


> (1) We'd review the SymmetricState and CipherState APIs to make sure
> they encapsulate all symmetric crypto.  There's probably some
> adjustments needed.  For example, Noise channel-binding mentions the
> "h" value directly; we could add a SymmetricState.GetHandshakeHash()
> instead.  Also, we might have to make nonces an argument to
> SymmetricState, to allow out-of-order decryption (as discussed in
> other thread).

this would probably be done via a PRF() call at any point in time,
since even the returned CipherState are based on the handshake
messages.

>  Noise_[PATTERN]_[PUBKEY]_[SYMMETRIC]

This could work. Strobe is instantiated with the following string:
"STROBEv1.0.2" but I think it should include the permutation in the
name as well (Strobe supports several permutations, particularly for
lightweight devices). Mike if you're reading this, you know how I feel
:D

> Anyways, if you want to drive the discussion in that direction, these
> are questions I'm immediately interested in for the next Noise spec
> revision.
> But of course, feel free to discuss broader (and more interesting!)
> questions as well.

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.

David