[Cryptography] Sign then encrypt, then sign again...

[Phillip Hallam-Baker]

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'.

I am certain that for my application I need both.

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.

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.

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).

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.

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.

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.

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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20230128/14014906/attachment.htm>