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

[Trevor Perrin]

Continuing the discussion on whether a Strobe variant of Noise would
benefit from avoiding nonce-based AEAD, in favor of AE with duplex objects:

On Mon, Sep 11, 2017 at 11:17 AM, David Wong <davidwong.crypto at gmail.com>
wrote:

>
> * a half-duplex Strobe protocol is attracting → it can be done with an
> AEAD as well
>

I think your counter-argument ("it can be done...") is correct here.

A "half-duplex" protocol (perhaps not best term, given that "duplex" has a
different meaning in context of permutation crypto) just means the parties
take turns using a single CipherState.  This is easily done with our
existing notions (just use the first CipherState from Split).

We could mention this briefly as an "Advanced feature" in the Noise spec,
which we discussed earlier:

https://moderncrypto.org/mail-archive/noise/2017/001241.html

So I don't see an argument here against nonce-based AEAD.



> * if you use a nonce, you need to absorb it and permute every time
> before encrypting. You also need to keep track of an 8-byte state →
> ou need a permutation everytime as well with Strobe's ENC operation.


You're making a performance argument against nonce-based AEAD in the case
of Duplex-based constructions: you have to absorb the nonce, which costs
something.

I'm not sure this cost is large enough to be worth optimizing.

I'm also not sure this comparison is fair to nonces:  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.

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?  (Farfalle?  Some "full-width" /
Evan-Mansour thing?).

I think we should research whether that's the case, and consider the best
AEAD/permutation constructs, before deciding to "optimize" away a useful
feature like nonces.



> * you lose Strobe's RATCHET operation which can give you
> forward-secrecy for free at every encryption → you could use a last
> PRF call (after AD;AD;ENC;MAC) that would generate your next AEAD key
>

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.

I would think an efficient AEAD might use this "crypto work" for other
purposes.  Perhaps forward-secrecy here only looks free because you're
comparing against inefficient alternatives?


* you lose Strobe's continuous authentication of all previous messages
> including the handshake → you could keep a continuous hash of these
> and authenticate them in the AD part (but one more state to keep track
> of) → on the other hand do we care about this property?
>

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

If the transport keys are shared between 2 parties, then authenticating
each message individually is sufficient to have authenticated "all previous
messages".

If the transport keys are compromised then "continuous authentication"
doesn't help against an active attacker who can replace all messages.

It could help prevent traffic modification by an active attacker who has
compromised the traffic key, but can only intermittently MITM.  That's a
very small benefit, IMO.

More generally, I don't think it's a great idea for different crypto
algorithms to provide subtly different properties in Noise.  I'd prefer for
Noise crypto choices to behave identically (except for
performance/crypanalytic strength), so it's easy to mix-and-match
algorithms and reason about things.


> I think it would be nice to have Disco specify three types of
> SymmetricState at the end: a half-duplex one, a full-duplex one and an
> AEAD one. The first one allowing for great space saving, the last one
> specifically targeting UDP protocols.
>

Not convinced yet - the first case is just a way of using CipherStates, it
doesn't need crypto changes.

The motivation for a non-AEAD construct isn't yet that compelling to me.

Trevor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20170914/c0a33582/attachment.html>