<div dir="ltr"><div><br></div>Continuing the discussion on whether a Strobe variant of Noise would benefit from avoiding nonce-based AEAD, in favor of AE with duplex objects:<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 11, 2017 at 11:17 AM, David Wong <span dir="ltr"><<a href="mailto:davidwong.crypto@gmail.com" target="_blank">davidwong.crypto@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
* a half-duplex Strobe protocol is attracting → it can be done with an<br>
AEAD as well<br></blockquote><div><br></div><div>I think your counter-argument ("it can be done...") is correct here.</div><div><br></div><div><div>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).  </div><div><br></div><div>We could mention this briefly as an "Advanced feature" in the Noise spec, which we discussed earlier: </div><div><br></div><div><a href="https://moderncrypto.org/mail-archive/noise/2017/001241.html">https://moderncrypto.org/mail-archive/noise/2017/001241.html</a></div><div><br></div><div>So I don't see an argument here against nonce-based AEAD.</div><div><br></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* if you use a nonce, you need to absorb it and permute every time<br>
before encrypting. You also need to keep track of an 8-byte state →<br>
ou need a permutation everytime as well with Strobe's ENC operation.</blockquote><div><div><br></div><div>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.</div><div><br></div><div>I'm not sure this cost is large enough to be worth optimizing.</div><div><br></div><div>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.  </div><div><br></div><div>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?).</div><div><br></div><div>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.</div><div><br></div><div> <br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* you lose Strobe's RATCHET operation which can give you<br>
forward-secrecy for free at every encryption → you could use a last<br>
PRF call (after AD;AD;ENC;MAC) that would generate your next AEAD key<br></blockquote><div><br></div><div><div>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.  </div><div><br></div><div>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?<br></div><div><br></div><div><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* you lose Strobe's continuous authentication of all previous messages<br>
including the handshake → you could keep a continuous hash of these<br>
and authenticate them in the AD part (but one more state to keep track<br>
of) → on the other hand do we care about this property?<br></blockquote><div><br></div><div>I don't care much about that property in the Noise transport phase (after the handshake).</div><div><br></div><div>If the transport keys are shared between 2 parties, then authenticating each message individually is sufficient to have authenticated "all previous messages".</div><div><br></div><div>If the transport keys are compromised then "continuous authentication" doesn't help against an active attacker who can replace all messages.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think it would be nice to have Disco specify three types of<br>
SymmetricState at the end: a half-duplex one, a full-duplex one and an<br>
AEAD one. The first one allowing for great space saving, the last one<br>
specifically targeting UDP protocols.<br></blockquote><div><br></div><div>Not convinced yet - the first case is just a way of using CipherStates, it doesn't need crypto changes.  </div><div><br></div><div>The motivation for a non-AEAD construct isn't yet that compelling to me.</div><div><br></div><div>Trevor</div><div><br></div></div></div></div>