[noise] Proposal for the Disco extension (Noise + Strobe)
trevp at trevp.net
Fri Jul 21 10:01:38 PDT 2017
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:
> The draft is here:
Great! Thanks for pushing this forward, that's an excellent basis for
My primary feedback:
This spec eliminates SymmetricState and CipherState and describes how
to directly implement higher-level functions on top of a new
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"
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
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?
* 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?
More information about the Noise