[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.
I concur with Robert.
> Thus, I am reluctant to include multiple
> hashes within the message imprint.
Me too.
Regards,
Denis
> 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
> >