[noise] Noise+Strobe=Disco

Trevor Perrin trevp at trevp.net
Sat Jun 17 11:26:30 PDT 2017

On Sat, Jun 17, 2017 at 12:36 PM, David Wong <davidwong.crypto at gmail.com> wrote:
> Hello all!
> I've been looking at Strobe[1] a lot (a protocol framework that Mike
> Hamburg announced on this mailing list a while ago). And I've been
> thinking about merging Noise and Strobe together.

Thanks for proposing this!  STROBE and sponges were an influence on
Noise, there are interesting connections worth exploring.

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.

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:

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

 (2) We'd have to extend the Noise protocol naming.  Currently the scheme is:


It might work to have one less primitive name, interpreted as:


Where [SYMMETRIC] could be something like:


(Don't take those too seriously, I'm not sure what the parameters for
a Strobe or Disco would be).

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


More information about the Noise mailing list