The "race" towards SHA-256, SHA-512

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Rich,

> Bob,
> 
> The current idea is to have OIDs for SHA-256, SHA-512, and SHA-384
> (truncated SHA-512).  

A naive question here. I am a little bit puzzled. The reason for
having 128 bits for a minimum hash comes from the Birthday Paradox.
160 bits is already overkilling. Are there any new discoveries along
the Birthday Paradox which indicate that 128 bits hashes are going
to be insecure and thus that we *need* 256 bits hashes and even more
?

For fitting the size of a signature value, various padding functions
exist.

So could you (or someone else) explain the rational for the "race"
towards SHA-256 and even SHA-512 ?

Denis 


> At least in X9; your comments (and anone else's)
> are appreciated.  I know nothing else about these algorithms except the
> following: SHA-x (with x >= 256) is not backward with SHA-1, i.e. you
> can't truncate a SHA-256 or whatever to SHA-160-bits.  So they are
> not doing the obvious (SHA-Y with Y > X in SHA-X being some sort of
> iteration of the same function with different IVs).  Of course that's
> obviously
> only 160 bits strong, so never mind.
> 
> This is an area where you have lots of expertsise; I'd be interested in your
> ideas (remembering the real version will be distributed to X9 in the next
> few weeks, and I'll do my best to leak it to PKIX ASAP).
> 
> Best,
> Rich
> 
> -----Original Message-----
> From: Bob Jueneman <bjueneman@novell.com>
> To: jap@ecs.soton.ac.uk <jap@ecs.soton.ac.uk>; ietf-pkix@imc.org
> <ietf-pkix@imc.org>; todd.glassey@worldnet.att.net
> <todd.glassey@worldnet.att.net>
> Date: Monday, September 11, 2000 6:31 PM
> Subject: TS TOKEN TYPES - Re: CMC issues, TSP hashes -
> 
> >In this regard, I was interested to hear on the Federal PKI TWG list that
> NIST
> >is considering releasing a SHA-256 and SHA-512 hash algorithm.
> >
> >No new algorithms will be forthcoming -- the only question is whether to
> >bundle them with the conventional signature OID, or to separate them out.
> >
> >Bundling them makes them somewhat harder to change, but on the other hand,
> >allowing complete freedom to choose the signing algorithm independently
> tends to
> >raise issue of N-squared combinations that have to be tested.
> >
> >Some combinations might not even make technical sense -- for example
> 200-bit
> >elliptic curve DSA with SHA-512, since the hash function wouldn't fit
> within the
> >signature result.
> >
> >On balance, and noting the generally poor track record we have in limiting
> >combinations of things to stable profiles, I am inclined to continue the
> practice of
> >specifying the signature algorithm and the hash algorithm as one joint
> specification.
> >
> >Bob
> >
> >>>> "todd glassey" <todd.glassey@worldnet.att.net> 09/11/00 01:06PM >>>
> >Hi all -
> >
> >----- Original Message -----
> >From: "J Adrian Pickering" <jap@ecs.soton.ac.uk>
> >To: <ietf-pkix@imc.org>
> >Sent: Wednesday, September 06, 2000 7:57 AM
> >Subject: Re: CMC issues, TSP hashes
> >
> >
> >> At 11:57 06/09/00 +0200, Avi Gozlan wrote:
> >>
> >> >- Use of SHA1 is hard coded in section 5.2. This does not leave the
> >> >standard open for other hash algorithms. Are there any plans to change
> >> >this?
> >>
> >> This is a problem shared with the TSP Draft also.
> >>
> >> (see posting -
> >> Date: Sat, 02 Sep 2000 17:37:43 +0100
> >> From: J Adrian Pickering <jap@ecs.soton.ac.uk>
> >> Subject: TSP Draft - hash enforcement &c
> >> which is rather lost amongst the OCSP debate!)
> >>
> >> Please can something be done about this for everyone's benefit? My
> >> suggestion is to introduce a PKIX globally available OID
> >> HashAlgorithmIdentifier which is distinct from AlgorithmIdentifier. This
> >> will enable other hashes to be used where required/wanted. The
> overloading
> >> of the AlgorithmIdentifier allows for a parameter which I'm not sure is
> >any
> >> use in the hash arena?
> >
> >Actually Adrian  your right - but I think we need a little more than this.
> >We need an official PKIX OID Tree and it needs to be available.
> >
> >For each complex data structure or process that can be uniquely identified
> >and that would want to be identified, PKIX needs an OID entry in some PKIX
> >master OID Table. Hash's, techniques, and maybe even the IOTP Transaction
> >types or something like that as well.
> >
> >>
> >> Russ Housley appears to agree: "The selected one-way hash function must
> be
> >> uniquely identified by an OID."
> >>
> >> I'd still rather have the TSA autonomously stamp an octet string and
> leave
> >> the client to decide what it all means.
> >
> >We are confusing the term "Client" here for the term "USER OF"... and this
> >is an important concept in understanding what we are really talking about.
> >
> >The key issue is whether the time stamp is used to control some other
> >external process, almost analogous to dropping a coin into a vending
> >machine,
> >or whether it is standing as evidentiary testimony to some event. As it
> >happens the Coin does both, but generally the mindset about how the TSP has
> >been thought about is form using time as a control parameter rather than an
> >evidentiary one. By the way - We generally as a group seem to assume
> >automatically between 'using data elements for control' rather than  'for
> >content'.
> >
> >In one case they are used to control the infrastructure or policy
> >like a signal, and on the other they are used to stand audit. The uses of
> >the same parametric data elements here are very different and have
> different
> >needs to support their respective end use models.
> >
> >> What business is it of the TSA to
> >> know what it is stamping (semantically or syntactically)?
> >
> >Depends on what the purpose of the TSA is. If there is a conveyance in a
> >legal sense of Agency, then the TSA may have legally binding reasons for
> >being able to identify the type of content it is stamping. Maybe to the
> >granularity of needing to parse the file first to determine its data type.
> >
> >.. and this leads us to the fact that a HASH in and of itself as a
> >timestamping record is very difficult to use from an end user model. What
> >the TST should be is a framework or harness itself and internally it should
> >represent a number of events interchangeably. There would need to be
> >different grades of Tokens with varying levels of overhead for their
> >management, and the approriate BCP to match.
> >
> >But realize that in no uncertain terms what we are sitting on is  the
> >designing of the Global Mint here.
> >
> >"The real end user goal is a simple bolt-on system that allows end users
> to,
> >with the transaction infrastructure they have today,  add non-repudiation
> >at a commercial level to their process, and  at a scaleable and reasonable
> >overhead."
> >
> >Simple to say, not so simple to do as there are so many different
> >transaction
> >processing systems in the world today, but the common elements in all of
> >them is that they have some DB system that they are layered on and an OS
> >under that of some sort.
> >
> >With that being the key the DB that is, doesn't the idea of a common binary
> >data structure that is a timestamp token appeal to you (represented in the
> >cyber world as ASN.1 if you want) . We can build an TST Binary to XML
> >presentation system and absorb or bridge the IOTP/XML Receipt efforts at
> >some level into the PKIX Timestamping systems  and deliver evidentiary
> grade
> >standards for representing events in time and space. YOW - look at the
> >potential
> >there!!!.
> >
> >These tokens and their respective API's will be able to specify its level
> of
> >trust, the event it marks and the data components that make up that event,
> >and the rules of processing the token. If a lighter token is necessary
> >portions of the system can be replaced by OIDS on as "as many as possible"
> >basis based in the OID tree idea (see above). More risk mitigated
> >transactions may require self authenticating tokens as well and we should
> >provide for these at the high end of the API.
> >
> >Poof - Instant transaction systems. I think that this is what DigiCash and
> >most all of the other token based transactor companies tried to do but they
> >were too far ahead of the curve to get real traction - and as scary as it
> >sounds, PKIX is in the perfect position to make this fly now.
> >
> >BTW, in and of itself is reason for not advancing the TPS Draft.
> >
> >>
> >> Adrian Pickering/
> >> Electronics and Computer Science
> >> University of Southampton
> >> UK
> >>
> >>
> >
> >