Re: Time-Stamp: Why not use several hashes?

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Manuel,

We want to keep the protocol simple. The threat you mention can be countered
by another way: re-time-stamp later on with a new hash function. If SHA-1
gets broken one day, this will not happen in just one day. Some
cryptographer will first find some weaknesses before you can really forge a
meaningfull message that has the same hash. So you get some time for
re-stamping.

If this argument were used, then we should sign TWICE, i.e.  in case one
digital signature algorithm was broken. We do not do that. There is no
reason to do it for the hash function.

Regards,

Denis


> Hi.
>
> In the (now expired) latest PKIX draft on time-stamping protocols from
> Sept. 23, 1998, time-stamp requests and tokens support the insertion of
> a single message imprint.
>
> I think several message imprints should be supported. If a hash
> algorithm were broken, time-stamp tokens using it (as the single message
> imprint) would have to be regarded invalid (even if some kind of linking
> mechanism were implemented!). If several hashes had been used, the token
> would still be valid, and it could be promptly renewed in order to
> prevent invalidation should further advances in cryptography render
> other hashes obsolete!
>
> (One must be careful here: there are different extents to which a hash
> algorithm could be broken; in Appendix A of  PKITS-D3
> [http://www.fnmt.es/pkits] there is an interesting analysis of the
> implications that the different kinds of hash failures would have on the
> time-stamping process.)
>
> Of course the requirements on the time-stamp verification process would
> also have be modified to require ("MUST" level) *all* the hashes to
> correctly verify in order to regard the corresponding time-stamp token
> valid.
>
> Best regards,
>
>     - Manuel -
>
> ----
> Manuel Heras-Gilsanz (mherasg@nexo.es)
> Independent Security Consultant
> Phone: +34-629 07 53 31