Obscuring HTTP headers using an HMAC trick

Goal: after the auditee completes the notarization, he must obscure the http header of the response (which usually contains the sensitive session ID) while at the same time proving to the verifier that the data that was not obscured came from the notarization session.

Whereas previously auditee committed to the whole page before he received server MAC key, now he only commits to the MAC of the page and to that part of html that he wants to make public.

Notation used here same as in https://en.wikipedia.org/wiki/Hash-based_message_authentication_code k = key, m = message (ie the server response) opad, ipad (padding) is omitted for simplicity H - hash function, assume sha256 sha256 state are the variables h0 through h7 as per https://en.wikipedia.org/wiki/SHA-2

The verifier will run the HMAC function to make sure that the resulting MAC matches that to which the auditee committed during the notarization session.

HMAC (k, m) = H ( k | H (k | m) )

the auditee has to allow the verifier to calculate H ( k | m) without revealing the http header portion of m, or if we split m into two parts - private and public, the verifier has to calculate H ( k | mpriv | mpub)

sha256 works by splitting the data to be hashed into 64 byte chunks and performing a round on each chunk. After each round, the sha256 state changes. Each new round builds on the state of the previous round.

With that in mind, the auditee will perform rounds on (k | mpriv) and stop. He will pass on the changed state to the verifier. The verifier will start with the changed state and complete the rounds on mpub. The verifier will get the final result H ( k | m ). From there the verifier has enough information to calculate the rest of the HMAC function.

The output of the HMAC function is MAC code which must match the MAC to which the auditee committed to. Also the verifier will check that mpub also matches the one to which auditee committed to.