<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 8, 2017 at 3:16 PM, 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"><span class="gmail-"><br>
</span>What you describe is the SpongeWrap mode introduced in "Duplexing the<br>
sponge: single-pass authenticated encryption and other applications"<br></blockquote><div><br></div><div><div><br class="gmail-Apple-interchange-newline">In Strobe terms, would this be:</div><div><br></div><div>KEY; AD; ENC; MAC;</div><div><br></div><div>(from [1], section 5.2)?</div></div><div><br></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">The nice part about STROBE is that you<br>
can get rid of the nonce though, which is both safer and more<br>
efficient imo (hence why I'm pushing this for Disco).<br></blockquote><div><br></div><div><div>Is your efficiency concern that the key and nonce would occupy space in the "rate" at the start of each AEAD call, whereas if you use a duplex object that is stateful between AEAD calls then the full "rate" is available for application data, since the key gets absorbed into the "capacity" prior to the AEAD calls, and there's no nonce?</div><div><br></div><div>Losing nonce-based AEAD substantially limits the functionality of Noise, e.g. you couldn't implement WireGuard.  That's a big loss of functionality for a small optimization.</div><div><br></div><div>If we wanted nonce-based AEAD *and* this optimization, couldn't we do something like encode the key and nonce directly into the SHAKE256 "capacity" (which is 512 bits, so could easily hold a 256-bit key and 64-bit nonce).  Then we'd get nonce-based AEAD plus the same efficiency, I think?  Or is that not allowed?</div><div><br></div><div>Trevor</div><div><br></div><div>[1] <a href="https://eprint.iacr.org/2017/003.pdf">https://eprint.iacr.org/2017/003.pdf</a> </div><div><br></div></div></div></div></div>