[noise] Noise+Strobe=Disco

[Trevor Perrin]

On Tue, Jun 20, 2017 at 10:29 AM, David Wong <davidwong.crypto at gmail.com> wrote:
>
> 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.)

Sure, agreed we need more concrete uses in short term, the "simple
1-RTT protocol" thread is thinking about that.


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

Cool, Rhys' hybrid forward secrecy spec is probably the best we've
got.  Figuring out how to handle extension documents is another open
task.

https://raw.githubusercontent.com/noiseprotocol/noise_spec/master/extensions/ext_hybrid_forward_secrecy.md


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

I'm thinking we could do this more lightly.  Not sure there's a strong
reason to merge or rename SymmetricState or CipherState, I think just
a sentence or two explaining that they could be implemented
differently, and an explanation of how to name this, should do the
trick.

Other work items are:
 - What other parts of spec need to be changed to go through
SymmetricState and CipherState functions, instead of accessing
"internal" variables.  I think channel-binding using "h" is one case
that needs fixing.  Another case is probably out-of-order transports
like Noise that use explicit nonces, so perhaps we need to make the
nonce a parameter to CipherState (but then: how would the Sponge /
Strobe implement that?)
 - How to name this.  I'm proposing
Noise_[PATTERN]_[PUBKEY]_[SYMMETRIC], but it would be good to see some
concrete proposals for how to name a Strobe or sponge layer here.

Trevor