[noise] Nonce-based AEAD and duplex objects (was Re: Notes from CRYPTO)

[David Wong]

Weirdly this thread's subject didn't start with a [noise] so I ignored
it :) I'm back!

> A "half-duplex" protocol (perhaps not best term, given that "duplex" has a different meaning in context of permutation crypto)

True. This could be renamed to *turn-by-turn* and *simultaneous*
perhaps? More verbose but more descriptive imo.

> We could mention this (half-duplex) briefly as an "Advanced feature" in the Noise spec

glad it made it to the spec! I have one nitpick though: this could
potentially allow you to not have to store two CipherStates, but the
way the spec makes you implement it still allocates space for two
CipherStates. I like the tendency of the Noise spec to be opiniated
and to make the right choices for the developers, so it would make
more sense to mention "not to return two CipherStates but one" instead
of "not to use the second one".

> If you don't have a nonce you need to permute and store your duplex state between every AEAD call.  It seems unfair to ignore the cost of storing a 200-byte Keccak state while criticizing an 8-byte nonce.

If you'd use Strobe as an AEAD, you would probably optimize it by
pre-absorbing the key and keeping that. So you would already have to
store a precomputed state. Which doesn't matter anyway because you
already need that space in memory.
Note that this is not an argument in favor of Strobe since you need to
do that extra permutation even without a nonce (an ENC or MAC
operation always permutes before doing its thing).

> It might be that building nonce-based AEAD on a duplex object, like Strobe, is a suboptimal use of permutations?  Maybe there are better AEAD-from-permutation constructions?

I'd have to read more about Keyak and Ketje before answering this.

> I think "for free" is debateable - you get forward-secrecy because you're using some of the "crypto work" performed by the permutation to update your old state to a new state.

What I meant is a combination of: (1) you do not need to specify this
as it is one aspect of Strobe (which currently doesn't allow you to
encrypt and ratchet at the same time but probably could if it wanted)
and (2) it doesn't involve another algorithm or more code to ratchet.
Although this is a light argument I agree.

> I don't care much about that property in the Noise transport phase (after the handshake).

It is not of the utmost importance, but it is what Strobe is about
(inspired by Noise!) and why I find it elegant. (It's mostly this nice
continuity that led me to read more about it and sponges btw!)

I think there are two ways to integrate a duplex construction in
Noise. You can either (1) replace each primitive by its duplex
equivalent (which should be straightforward. cSHAKE could replace
everything OR HMAC could be KMAC, AESGCM could be Ketje, SHA256 could
be SHAKE/K12, HKDF could be SHAKE, etc...). Note that this would
mostly make use of sponge constructions rather than a duplex
construction, but this would allow you to easily mix and match with
the currently defined crypto algos in Noise. Or you can (2) deeply
merge a duplex construction into Noise, which is what I had in mind
for Disco.

If you are attracted by (1), I don't think it needs to be done in an
extension in the first place.

(2) just plays nicely if you think of Strobe as something like AESGCM
that developers would not be expected to implement, but just use. The
whole part about having to deal with nonces, generating the
CipherState objects and using them is complicating the spec. If we're
using a duplex construction inside of Noise let's not make compromises
and see what it can fully accomplish. The whole dealing with nonces
and setting up AEADs can be removed which is a plus even only thinking
about complexity. For example, I made the mistake in my own
implementation of generating nonces in BigEndian instead of
LittleEndian, mistake that took me quite some time to catch. If you
look at how Disco does it, it is completely straight forward:
https://github.com/mimoo/NoiseGo/blob/master/disco/disco.go#L286:L298
and the developers don't even have to implement the
encryption/decryption functions. In addition to that you get all the
flexibility of Strobe which allows you to continue your session with
more complex symmetric protocols.



David