• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: On NSIncrementalStore UUID Uniqueness
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: On NSIncrementalStore UUID Uniqueness


  • Subject: Re: On NSIncrementalStore UUID Uniqueness
  • From: Alastair Houghton <email@hidden>
  • Date: Wed, 11 Jan 2017 10:27:33 +0000

On 11 Jan 2017, at 00:16, Saagar Jha <email@hidden> wrote:
>
> Small quibble: UUIDs are not guaranteed to be unique. It's just extremely likely they will be, and they be sufficient for almost all applications, including this one.

If we’re going to be pedantic, properly issued version 1 and 2 UUIDs *are* guaranteed to be unique - but that means (a) you have a properly issued MAC address that hasn’t been spoofed, and (b) you aren’t generating more than the rate limit for the UUID version (this should be prevented by the generating code; sometimes the generator has a lower rate limit because of the low precision of the system clock).  The downside is that version 1 and 2 UUIDs have privacy implications - they leak the MAC address of your device.  For some applications, though, this is not a problem and you may want to use a version 1 UUID in that case.

Versions 3 and 5 are subject to hash collisions (MD5 and SHA-1 respectively), and version 4 (the one you should probably use as a sensible default) is random and so subject to statistical collisions.  It isn’t recommended to use version 4 unless you have a source of high quality randomness available, to avoid collisions caused by poor quality random number generation (this won’t be a problem if you’re using the system APIs to generate them on Mac OS X or iOS).

Version 5 UUIDs can be useful if the thing you want to identify has e.g. a URL or FQDN or similar, as you can directly construct them from that, which might let you avoid e.g. another database lookup in some cases.  I would avoid version 3 (besides MD5 being weak to begin with, it’s also vulnerable to a length-extension attack; SHA-1 normally would be too, but in a version 5 UUID it isn’t because too many bits of the SHA-1 hash are missing... you’d need to try 275 billion different alternatives).

Also worth noting that different versions cannot collide with one another - there are version bits in the UUID.

TL;DR: Version 1 and 2 UUIDs should be unique.  Versions 3 through 5 can in most cases be assumed to be unique.

Kind regards,

Alastair.

--
http://alastairs-place.net


_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden


References: 
 >On NSIncrementalStore UUID Uniqueness (From: Daryle Walker <email@hidden>)
 >Re: On NSIncrementalStore UUID Uniqueness (From: Jean-Daniel <email@hidden>)
 >Re: On NSIncrementalStore UUID Uniqueness (From: Saagar Jha <email@hidden>)

  • Prev by Date: Re: On NSIncrementalStore UUID Uniqueness
  • Next by Date: Re: On NSIncrementalStore UUID Uniqueness
  • Previous by thread: Re: On NSIncrementalStore UUID Uniqueness
  • Next by thread: Re: On NSIncrementalStore UUID Uniqueness
  • Index(es):
    • Date
    • Thread