uuid types 3 and 5

[Martin Baxter]

On 09/01/14 20:58, Fraser Gordon wrote:
> 
> 
> On 09/01/2014 20:20, Martin Baxter wrote:
>> I have read that type 3 is deprecated, on the basis that md5 is not
>> considered secure these days, although I think that was one thing that
>> confused me because uuid is nothing to do with encryption or obfuscation
>> as far as I was aware.
> I believe the idea is to map a hierarchical system of names (like a
> filesystem) to fixed-length identifiers:
> 
> foo/bar - UUID = hash(bar + hash(foo))
> foo/baz/bar - UUID = hash(bar + hash(baz + hash(foo)))
> baz/bar - UUID = hash(bar + hash(baz))
> 
> will all (with overwhelming probability) have unique identifiers but the
> identifiers will be consistent whenever the UUID of a particular name is
> generated.
>> Is it perhaps that the "namespace" has to be obfuscated so that
>> "unspecified unauthorised persons" don't also deliberately create uuids
>> based on the same namespace?
>>
>> If that is the case, you wouldn't want to use this in an open-source
>> context, because the namespace would be a secret?
> UUIDs are not really intended to provide security - their purpose is for
> uncoordinated parties to generate identifiers without (realistic)
> probability of overlap.
> 
> The collision resistance is for a situation where you have
> filesystem-like paths that resolve to UUIDs that are then looked up in a
> table (this is a fairly normal hash table but based on the full path
> rather than hash components).  With such "unique" identifiers, you might
> decide not to allow UUID collisions. Now imagine a system where a number
> of people create records (e.g. a census) which have a UUID assigned
> based on some of the recorded information, e.g.:
> 
> /Country/State/City/Street/Building/Surname/FirstName/DateOfBirth
> 
> Some malicious person might deliberately change their name in such a way
> that their UUID will clash with another name - this will cause problems
> when the records are centralised and combined into the full data set.
> 
> This isn't a terribly realistic example but should hopefully indicate
> the motivation. I have no idea if anyone actually does this but similar
> hashing schemes exist in modern filesystems for things like metadata
> integrity checking.
> 
> Regards,
> Fraser
> 

I think I am maybe starting to see it.

RFC 4122 (thank you Mark) says:

The requirements for these types of UUIDs are as follows:

   o  The UUIDs generated at different times from the same name in the
      same namespace MUST be equal.

   o  The UUIDs generated from two different names in the same namespace
      should be different (with very high probability).

   o  The UUIDs generated from the same name in two different namespaces
      should be different with (very high probability).

   o  If two UUIDs that were generated from names are equal, then they
      were generated from the same name in the same namespace (with very
      high probability).

On the face of it, those requirements could be met by simply hashing the
inputs in some consistent manner, depending how you define "very high
probability".

So I take it that the situations where you would use this type of uuid
are really similar to those situations where you might use a hash, but
where a simple hash wouldn't povide a high enough probability of
uniqueness for the context.

Martin