2
$\begingroup$

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?

$\endgroup$
  • 1
    $\begingroup$ Personally I really dislike partial hashes; I'll ask the creators of the protocol as well if they can give substantial reasons to apply them. $\endgroup$ – Maarten - reinstate Monica Sep 3 '14 at 10:32
  • $\begingroup$ Where does the second part of the message to be hashed by the card comes from? If it is not provided by the terminal the rationale behind could be that the terminal cannot use the card as a signing oracle. $\endgroup$ – DrLecter Sep 3 '14 at 13:15
  • $\begingroup$ @DrLecter It is provided by the terminal as well. In that sense there is no difference - all data is present in the terminal (to sign a document, you need the document, you're not first going to split it and distribute). $\endgroup$ – Maarten - reinstate Monica Sep 3 '14 at 14:32
  • $\begingroup$ Ok. True in case of signing a document, but thats not mentioned in the question. In other applications it might be meaningful to have some part of the message on the card. $\endgroup$ – DrLecter Sep 3 '14 at 14:35
  • $\begingroup$ @DrLecter OK, so that's one reason why this could have advantages, thanks! A hash list or tree would make more sense if you control the protocol of course. Not applicable at all for my situation, but it may be in a rationale in the general sense. $\endgroup$ – Maarten - reinstate Monica Sep 3 '14 at 14:45
2
$\begingroup$

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

$\endgroup$
1
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ I've accepted the other answer because it is just slightly more generic, but this answer shows a very interesting use case of partial hashes (which could also be solved using a Merkle tree or list, but using a partial hash would work as well, I suppose). Thanks! $\endgroup$ – Maarten - reinstate Monica Feb 24 at 2:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.