Title: Issue with changed hashing algorithm for V3-V2 key derivation
Claus,
There is another option, which is to
forget the fact that the V2 key was produced by the old hashing algorithm and
regard it as an evolved key that must be mapped to the desired V3 key in a
non-standard way, as we do for some of the canonical tModels in V2.
However, if the BP WG are happy to have a
UUID-based V3 key then I think that is the best option.
I am by no means a cryptography expert but
I don’t think the change in algorithm will affect the chances of a
collision. Because we changed the initial 16-byte sequence of the total
sequence of bytes given to the MD5 hash algorithm we can be sure that the
sequence of bytes that were used to produce the original WS-I V2 key can never
be used with the new algorithm. This means that the only way that we
could get the exact same 128-bit quantity out of the MD5 hash is if there were
a collision, and although it has not been proven that such collisions are
impossible it does not seem to be a practical concern.
However, it occurred to me while thinking
about this that we could have a problem in general, nothing to do with the
change of algorithm as such, because we force some of the bits of the output of
the MD5 hash, which means that we could potentially be introducing “false”
collisions by making the output of the hash conform to the format of a UUID.
We force six bits to constant values which
means that there are 64 different MD5 hash values that would all produce the same
UUID value. I doubt that this will be a problem in practice, and I don’t
see what else we could do. By restricting the format to being a
particular UUID format we only have 122 bits of random number, not a full 128.
The migration from V2 to V3 is covered by section
10.1.3. You cannot map from V2 to V3, at least not if you follow the
recommendations in the spec.
John Colgrave
IBM
-----Original Message-----
From: Von Riegen, Claus
[mailto:]
Sent: 17 September 2003 07:59
To: UDDI Spec TC
()
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
