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

[Trevor Perrin]

On Tue, Jul 25, 2017 at 12:47 AM, David Wong <davidwong.crypto at gmail.com> wrote:
>
>> 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

Could you expand on that?

CipherState and SymmetricState are intended to be re-implementable
APIs.  If that's not the case I'd like to understand the problem and
fix it.


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

Hmm, Wireguard (for example) uses explicit out-of-order nonces.  I
think new symmetric crypto for Noise should support that (and we
should clarify this in the Noise spec).

I assume you could clone the Strobe state for every encryption and mix
in a nonce somehow?


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

Fair point, that's more a feature request for Strobe.


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

In theory that's easy.  It raises questions of naming and document structure.

We're still thinking about naming conventions (e.g. what characters do
we need to allow in crypto algorithm names), so it's a good exercise
to name these.  Perhaps(?):

"K12" = Kangaroo12, HASHLEN=32
"M14" = Marsupilami14, HASHLEN=64

"SHAKE128" = SHAKE128, HASHLEN=32
"SHAKE256" = SHAKE256, HASHLEN=64

"SHA3/256" =  HASHLEN=32
"SHA3/512" = HASHLEN=64

The HMAC BLOCKLEN would be set to the "rate", for processing the HMAC key.


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

 * Seems like the size of the permutation makes more sense as part of
the permutation name (e.g. "Keccak1600")?

 * What does the "128" correspond to?  Does that get mapped to some
number of rounds or something?

 * Shouldn't mix underscores and dashes.

 * Shouldn't the version number (if it's needed) be attached to Strobe
itself, e.g. Strobe1.0.2...


Trevor