<div dir="ltr"><div class="gmail_default" style="font-size:small">One of the topics that keeps coming up is whether to sign the data first then encrypt or encrypt the data and then sign. And there are valid security arguments both ways and vehement arguments bordering on editor wars as to which is 'correct'.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I am certain that for my application I need both.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">One of the applications of the Mesh is to notarize digital forensic evidence as it is collected. So take some photographs at a crime scene, enroll them in a Merkle Tree notary log immediately. Take a hard drive image, same. Everything we can should be authenticated and checkmarked.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">But the evidence also needs to be encrypted because there may be evidence relevant to multiple cases in the same notary log. It is impossible to know in advance what is linked to a case and what is not.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">In my scheme, the individual envelope and the sequence are signed separately. Both signatures are always over a manifest consisting of the digest of the content metadata and the digest of the payload (i.e. ciphertext of an encrypted message).</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Question is how to establish a robust binding to the plaintext of the envelope so that we can say that this particular photograph was taken at a particular date and time and without revealing plaintext of any other message in the process. I don't rate the AES-OCB authentication tag sufficient for that purpose.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So first step there is that every envelope is encrypted under a unique key and IV that are derived from the key agreement key by way of a salt. So the envelope session key is always separate from every other envelope.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I could just include a hash of that key in the signature manifest. But it seems better to include something that has a direct binding to the message such as a MAC of the plaintext digest under the envelope key or the plaintext digest encrypted under the envelope key. I can't decide which, nor can I decide whether I should use OCB or ECB mode to encrypt the plaintext digest, yes, I know ECB has issues but this is encrypting data that cannot have repeating patterns in the plaintext without something being severely wrong with the universe.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Taking the SHAKE of (key, plaintext-digest) seems like the best approach to me since the signature then incorporates the envelope key within its scope. But I guess I could be persuaded otherwise...</div></div>