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

[David Wong]

Trevor Perrin

> I think you could go even further in
> defining things via SymmetricState and CipherState

I tried to think more on how to do that, but I don't see any practical
way to re-define a CipherState with Strobe. The SymmetricState just
end up not making sense (especially since Strobe is itself a
SymmetricState, I think that's the point).

>  * I'm not sure you need section 3, seems like some of that is
> repeating things from Strobe, and the rest could just be inlined into
>  descriptions of a SymmetricState and CipherState implementation.

The functions described in Strobe have a different API which is not
relevant for the current document. For example every function admits
an extra argument `more` while not having clear names (they either
accept some `data` or `length`). I don't think that this section
really impedes on the document, rather it declares what are the
functions that we later talk about.

> If you were to define a CipherState, we could also think about whether
> the CipherState API should be modified to take explicit nonces to
> support out-of-order / UDP protocols like Wireguard.  I'm not sure how
> STROBE would support that?

Strobe would not be a good option here as you would need to define a
new protocol for every new encryption/decryption.

> Another thing I'm curious about is whether the permutation could be
> run for fewer rounds when encrypting versus MixHash / MixKey steps.  I
> think some constructions like "MonkeyDuplex" use more rounds when
> absorbing the key and fewer rounds when encrypting.  That could make
> sense in the Noise context as well.

I think these are definitely something we should look into. Can we
reduce the rounds of the permutation to 12 like KangarooTwelve? Can we
go extreme like the MonkeyDuplex? But these ideas will most likely
happen on the Strobe side of things while being transparent for the
Disco extension.

> It seems like the cost of preserving this KDF property is low (just a few extra permutations, during the handshake)?

Yep, I was just following on one of Noise's themes which seems to be
about optimization. I'm not sure if the PSK case really needs a KEY
either but I did not look into it much. By the way I guess this is a
good opportunity to ask, what about KangarooTwelve as an additional
hash function? Taking it further, without thinking about disco, SHAKE
could also be an option that could work for HKDF, HASH and HMAC. Right
now if I want an alternative to Merkle-Damgard(-based) constructions I
don't have much choice :)

> So how do we name all these?

Strobe can also be named this way : `Strobe-F-sec/b-vX.Y.Z` with `F`
being the permutation, `sec` the security provided, `b` the size of
the permutation.

So that would give us something like this:
`Noise_XX_25519_Strobe-Keccak-128/1600-v1.0.2`.

David