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 _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode