The central part of the V3 to V2 algorithm is the use of the MD5 message
digest algorithm. This is a cryptographic digest, SPECIFICALLY DESIGNED to make
if difficult to create a message that will produce a desired digest (you can see
why that was a design objective...). OK, it's not as popular as it once was
(SHA-1 seems to be the more popular alternative), because there have been some
weaknesses detected, but it was considered more than good enough in its
day.
So, no, there's no algorithm to get a V3 key that will produce a given V2
key when run through the hash.
The algorithm to get a V3 key from a V2 key is to take the V2 key and put
an appropriate prefix in front of it. :-)
How likely is it that we'll see some other V3 key hash to this one? Rather
unlikely - the message digest algorithms are supposed to distribute the hashes
fairly uniformly across the target domain.
Tony.
-----Original Message----- From: Von Riegen,
Claus [mailto:claus.von.riegen@sap.com] Sent: Wed 17/09/2003 16:58
To: UDDI Spec TC (uddi-spec@lists.oasis-open.org) Cc:
Subject: [uddi-spec] Issue with changed hashing algorithm for V3-V2
key derivation
As you might know, WS-I has specified a category
system for profile conformance claims in UDDI. The tModel's key (in UDDI V2)
is "uuid:65719168-72c6-3f29-8c20-62defb0961c0" and was derived from the
proposed V3 key "uddi:ws-i-org:conformsto:2002_12".
Since we are going to correct our hashing algorithm
in the V3 errata V3.0.1, the V2 key would have to be regenerated. The correct
key would be "uuid:24ef977d-6293-3d7c-8386-b183cdf86149". However, the WS-I
Basic Profile WG (BP WG) does not feel comfortable to change the key at this
point in time - the Basic Profile 1.0 has been published as a Final
Specification and would be changed incompatibly.
I believe that there are two alternatives:
- either change the key to conform to the new
hashing algorithm and to enable the domain-based V3 key (as specified
above),
- or do not change the key and map it to the
UUID-based V3 key "uddi:65719168-72c6-3f29-8c20-62defb0961c0" later.
The BP WG would like to pursue the second
alternative, but before deciding so, I wanted to make sure that it is actually
a valid alternative. Since the key was generated using the "old" hashing
algorithm, we must ensure that it can not coincidentally be generated using
the "new" hashing algorithm from another key. In other words, how can we
ensure that a given V2 key is not derived from a domain-based V3 key? Besided
the V3-V2 hashing algorithm, is there also a V2-V3 mapping
algorithm?
Thanks, Claus
|