[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Time-Stamp: Why not use several hashes?
I think that if a common hash function is broken (for example SHA-1) then no
signature created within that infrastructure, with that hash function can be
trusted, including the TSA's. Thus, I am reluctant to include multiple
hashes within the message imprint. It will not actually help if the hash
algorithm used to sign the token is broken. Also, as I stated earlier, if
certain individuals really want to do this, they can do it by defining a new
OID.
> ----------
> From: Jose A. Manas[SMTP:jmanas@dit.upm.es]
> Sent: Monday, April 12, 1999 4:24 AM
> To: Denis Pinkas
> Cc: Manuel Heras Gilsanz; ietf-pkix@imc.org; afd@fnmt.es
> Subject: Re: Time-Stamp: Why not use several hashes?
>
> Denis,
> I feel uneasy with both arguments.
>
> If a guy finds out how to provoke collisions on a hash functions,
> there is a serious temptation to exploit the hole before
> publishing it. Breaking a time-stamp infrastructure is a nice
> goal: you break it before anybody knows it can be broken,
> and then there is a difficult question about when the TSA was
> no longer to be trusted.
>
> I have some concern as well with respect to breaking a digital
> signature. If broken but time-stamped,
> a TSA can still prove that it was signed
> before it was breakable. But if you break the TSA itself, then
> there is no help. That about breaking the hash.
>
> Still, if you break the TSA signature, you have audit records
> (stored evidence in the TSA) to help you (as far as there are
> no collisions in the hash).
>
> Alltogether, I aim to say that breaking a hash does break down
> everything, and it sounds interesting to foresee the case.
> Allowing for several messageimprints sounds as a cheap end
> effective countermeasure.
>
> pp
>
> Denis Pinkas wrote:
> >
> > 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
>
> -- --------------------------------------------------------
> Prof. Jose A. Manas <jmanas@dit.upm.es>
> Dpt. Telematica http://www.dit.upm.es/~pepe
> E.T.S.I. Telecomunicacion tel: [+34] 91 336 73 25
> Ciudad Universitaria gsm: [+34] 607 73 38 94
> E-28040 Madrid, SPAIN fax: [+34] 91 336 73 33
>