<div dir="ltr"><span class=""><div>I'm merging message trees here to avoid multiple replies.<br><br>Re: Joe --<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"><div dir="ltr">Your
proposed scheme might be secure there, but the straightforward way to
do what you're trying to do is compute a MAC of the plaintext and use
that as your IV. Key-reuse is a problem for provable security, as you
point out. The simplest thing is to just have two keys, one for the MAC
computation and one for the encryption.</div></blockquote><div><br></div></span><div></div>
<div class="gmail_extra">MACs are definitely simpler and feel more elegant, but if possible, I'd prefer to stick with an encrypt-then-MAC/sign approach all around (the containers themselves are signed, not MAC'd).<br><br></div><div class="gmail_extra">Re: Taylor --<span class=""><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"><div dir="ltr">What you describe is roughly the SIV construction of RFC 5297. The<br>
128-bit block size of AES makes me nervous for random nonces, no<br>
matter how you carve it up or mix it up for nonce and counter</div></blockquote><div><br></div></span>
</div><div class="gmail_extra">SIV is an awesome thing that I didn't know about, thanks. Wouldn't the 128-bit block size then be an argument *for* deterministic nonce generation? It's a bit tough for me to tell from your message. For our application, deterministic nonce generation is highly desirable, but we don't want that to compromise security. Point is, we're already on the side of non-random.<span class=""><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">If you used, e.g., XSalsa20 or XChaCha instead, which have 192-bit<br>
nonces in addition to a counter, random nonces would be OK -- a<br>
birthday bound of 2^96 is reasonably high and you can theoretically<br>
have up to 2^64-block messages.</div></blockquote><div><br></div></span>
</div><div class="gmail_extra">I'd definitely like to look into Salsa/ChaCha in the future, but right now we don't really have the resources to make that switch.<span class=""><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">All that said, depending on the rest of your protocol, you may be<br>
better off with an independent key per message, as, e.g., Tahoe-LAFS<br>
and Tarsnap do.</div></blockquote><div><br></div><div>I probably should have clarified that as well. Generally speaking, independent messages should have different keys. However -- and this decision may come back to bite us -- key choice is deliberately left out of the protocol spec. So it's possible, given that we do have a concept of a dynamic message (that discussion gets complicated quickly[1]), that clients may choose to reuse keys for dynamic messages. In the future we'd like to add an (optional) overlay standard that mandates some kind of ratcheting, probably axolotl. For scope limitation reasons that would still be outside of the "spec proper", but at least it'd be heavily recommended.<br></div></span>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">I've seen Tahoe-LAFS before, but am probably not as familiar with it as I should be. Thanks for the suggestion, I'll take a second look.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">[1] Relevant whitepaper section: <a href="https://github.com/Muterra/doc-muse/blob/master/whitepaper.md#addressing-content">https://github.com/Muterra/doc-muse/blob/master/whitepaper.md#addressing-content</a><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks,<br clear="all"></div><div class="gmail_extra"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><br>Nick Badger<br></div><div><a href="https://www.ethyr.net" target="_blank">https://www.ethyr.net</a><br></div><div><a href="https://www.muterra.io" target="_blank">https://www.muterra.io</a><br></div><div dir="ltr"><div><a href="http://www.nickbadger.com" target="_blank">http://www.nickbadger.com</a><br><span><font size="1">PGP fingerprint 37B9 22FC 2E47 50AA E06B 9CEC FB65 8930 46F0 333A, listed at <a href="https://pgp.mit.edu/" target="_blank">MIT</a> and <a href="http://keyserver.pgp.com/" target="_blank">PGP</a></font></span></div></div></div></div></div></div></div></div><br></div></div>