<div dir="ltr"><div class="gmail_default" style="font-size:small">This paper shows many of the arguments surrounding the order of signature and encryption</div><div class="gmail_default"><a href="http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html">http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html</a><br></div><div class="gmail_default"><br></div><div class="gmail_default">The paper recommends that data be signed and then encrypted. But I dislike that order because it means that it is only possible to verify the message after it has been decrypted. This violates a layering principle in which data is only exposed to a device that contains a private key AFTER we know it doesn't come from a malicious source.</div><div class="gmail_default"><br></div><div class="gmail_default">So here is the alternative approach. I generate my message encryption keys from a master secret established by the key exchange by means of a key derivation function (HKDF) and a unique per-message salt. (I also generate the IV for encryption and the MAC key if required).</div><div class="gmail_default"><br></div><div class="gmail_default">Each set of keying material is extracted with a different and unique info tag 'encrypt', 'mac', 'iv' and so on.</div><div class="gmail_default"><br></div><div class="gmail_default">I would like to include an additional witness value that is derived from the master secret using the KDF using another unique info tag 'sign'.</div><div class="gmail_default"><br></div><div class="gmail_default">This does not quite guarantee that the signer knows the plaintext or even the master key but does prove that whoever had the master key authorized them to sign. That might be an interesting property.</div><div class="gmail_default"><br></div></div>