Advantages of using intermediate hash over full hash in digital signature application

Question

Description of intermediate hashes

Intermediate (or partial) hashes are canonical forms of digest state that can be transferred from one hash implementation to another, so that the other, limited device (e.g. a smart card chip) can finish the hash calculation with the remaining data. This scheme is used to create a signature generation system consisting of the devices performing the calculations.

So:

1. Terminal generates intermediate hash by processing the first i blocks of the message;
2. Terminal sends intermediate hash to the smart card;
3. Smart card finishes the hash with the last (N - i) blocks of data;
4. Smart card creates the signature and sends it back to the terminal;
5. Sends back the signature.

instead of:

1. Terminal creates full hash;
2. Terminal sends full hash to the smart card;
3. Smart card creates the signature and sends it back to the terminal;
4. Sends back the signature.

Obviously letting the smart card generate a full hash has drawbacks with regards to performance if the data to be hashed is large. This can still be an option, e.g. when the signature is generated over signed attributes instead of the content itself.

Intermediate hashes are not specified in the SHA-1, SHA-2 or SHA-3 standards.

Possible reason for using intermediate hashes

In my previous question I've already asked about if other protocols use partial hashes. Due to the limited amount of feedback there I'll probably have to conclude that they are not often used.

I've mused there that intermediate hashes could possibly be used to avoid covert channels, i.e. the insertion of data other than a hash into the signature generation. I'm not sure that this would pose a significant threat though (as the provider of the hash could also provide a hash over anything else).

Question

What cryptographic rationale is there to use intermediate/partial hashes instead of full hashes provided by the terminal?

Answer 1

There are two points I can imagine where partial hashes in a protocol can be useful.

Massively parallel computing from the same start

Using an intermediate state as the base for the PoW seems to be standard practice with Bitcoin ASICs these days and give a few dozen per cent of a speed-up. Technically you can pre-compute what you want in the next block and then send this to the ASICs for them to do the final compression function call and looking for the right property.

Regulatory Restrictions / Trusted-Signed Data Displayment

There may be regulatory restrictions along the lines of "the trusted computing device must have seen the actual transaction data", where the signature is over the sender, the recipient and the amount. Now the standard requires you to display the recipient and the amount on a card- / card-reader-controlled trusted display, however you could maybe save a bit of computation time by pre-computing the hash for the parts that do not need extra evaluation. Here the security gain would be in the fact that the card actually knows what it signed and not just some random blob (which could also have been a malicious transaction!).

Answer 2

Currently I have a somewhat similar requirement.

The task is to provide hardware signature (smartcard, remote HSM) for transaction data. The speciality is, that during signature a signature count (per certificate) and a timestamp has to be added to the payload. On the other hand, detail transaction data should be kept private, only an >intermediate< hash should be presented to the signature device.

The signature process would be:
by requestor: hash0 = Hash.update(data).intermediate()
by HSM: hash = Hash.resume(hash0).update(signCount+signTime).digest()
signature = Certificate.sign(hash)

Verification would be:
hash = Hash.update(data+signCount+signTime).digest()
result = Certificate.verify(hash, signature)

At the moment this can be realized only in a two step hashing. This is not really a problem, but the solution is not as elegant, as it could be.