<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 12, 2015 at 11:05 AM, Nick Badger <span dir="ltr"><<a href="mailto:nbadger1@gmail.com" target="_blank">nbadger1@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br>Second question: assuming it is reasonable, what's the best way to do this? We do have to be concerned about leaking information from the inner container, so our current process is NONCE = AES-ECB( message_key, HASH( plaintext ) ) with the hash truncated to match the symmetric block size. Frankly though, that seems off to me, at the very least because we're reusing the message key. We should probably transition the message key to a master key, and use a KDF to generate both the nonce key and the message key. To that end, would NONCE = AES-ECB( KDF( master_key, HASH(plaintext) ), HASH(plaintext) ) make more sense? The "extra" AES here is to protect from dictionary attacks and against potential hash compromise.<br></div></blockquote><div><br></div><div><span style="font-size:12.8px">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.</span> </div></div></div></div>