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

[David Wong]

Hey Trevor!

Thanks for the feedback.

I released a new draft according to the feedback:
https://github.com/mimoo/NoiseGo/blob/master/disco/specification.md

Some more answers inline:

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

I thought about that and it seemed less elegant, but your point about
extending the HandshakeState in future revisions of Noise is indeed a
concern. It could be painful to constantly try to keep Disco
up-to-date with Noise's HandshakeState in the future. If you think
SymmetricState and CipherState are going to be more stable this sounds
good. I applied these changes and it makes the Disco spec much
shorter, I guess it wasn't so inelegant from the point of view of the
extension.

Also, this brings another point: the specification currently builds on
top of Noise revision 32, I'm guessing that we will have to keep up
with what revision we extend until Noise finally land a real version.
Is that the plan or are there no plan to ever release a Noise 1.0 :)?


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

There are two big differences between the KEY and the AD operations:

1. the KEY operation forces a permutation to happen
2. the KEY operation replaces the bytes of the new state (instead of
XORing into it). This creates the forward secrecy

I don't think it is a better operation, because of the following points:

* this operation doesn't need to be influenced by the previous ones
(so 1. is not needed)
* forward secrecy is not needed at this stage (so 2. is not needed)
* forcing a permutation at this point would slow down the handshake


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

I've been talking to Mike Hamburg about this, I think we should indeed
include the permutation in the name. It was actually part of the
naming in prior versions of Strobe and was removed for some reasons.

I love what Frank has done with libHydrogen (and what the Gimli team
has done with Gimli), and in practice yes you can switch the
permutation in Strobe since it already has three different ones
(keccak-f[400], keccak-f[800] and keccak-f[1600]). (Now I would be
careful with Gimli at the moment because the amount of cryptanalysis
Keccak has received compared to this new permutation is way too
important to ignore it due to "worse" performance.)

David