[noise] Proposal for the Disco extension (Noise + Strobe)

[Trevor Perrin]

On Fri, Jul 21, 2017 at 2:55 AM, David Wong <davidwong.crypto at gmail.com> wrote:
> Hello all,
>
> I've come up with a specification for the Disco extension, following
> discussions here:
> https://moderncrypto.org/mail-archive/noise/2017/001122.html
>
> The draft is here:
> https://github.com/mimoo/NoiseGo/blob/master/disco/specification.md


Great!  Thanks for pushing this forward, that's an excellent basis for
discussion.

My primary feedback:

This spec eliminates SymmetricState and CipherState and describes how
to directly implement higher-level functions on top of a new
"StrobeState".

It might be better to:
 * Leave HandshakeState alone
 * Treat Noise's SymmetricState and CipherState as "interfaces" and
describe how to re-implement them with Strobe.

My reason is that HandshakeState is going to evolve as we add more
tokens and more features (e.g. post-quantum, signatures, PAKE, SAS,
etc).  We'll describe new features in terms of the existing
SymmetricState / CipherState APIs, so if all symmetric-crypto fits
into that framework it will automatically work, and you won't have to
keep re-defining alternate STROBE versions of everything.

It might be that the existing SymmetricState and CipherState APIs are
limited for what you want, or aren't consistently used (e.g.
channel-binding using "h" directly instead of calling a
SymmetricState.GetHash or something).  But I think we should identify
such issues and improve SymmetricState / CipherState as needed, rather
than replace them.

So for example, instead of explicitly replacing every call to
SymmetricState.MixHash() with StrobeState.AD(), we could define in a
single place that MixHash() calls are implemented with the STROBE "AD"
operation.

---

Couple other comments:

 * Should MixKey operations be done with STROBE "KEY" instead of STROBE "AD"?

 * The Strobe specification mentions several STROBE instances (e.g.
128/1600, 256/800, etc).  The STROBE paper mentions even more
generality, e.g. using STROBE with different sponges.  Do we want to
generalize and extend the naming for different STROBE instances and
other sponges?

Perhaps relevant:  Libhydrogen is using a Noise-like protocol with
"Gimli", which is a different Sponge (as far as I understand, which is
not far).  So is there a way to generalize this approach so it's also
easier to work with things like that?

https://github.com/jedisct1/libhydrogen/wiki/Key-exchange

 * We were thinking of tightening up the name format to only allow
alphanumeric characters and maybe slashes.  Perhaps this spec makes a
case for allowing "." characters as well?

Trevor