-2

At the moment you can generate a random UUID by using:

UUID.randomUUID().toString();

This results in the following string:

94f3c8a3-a161-468f-9844-de92dd90ace7

which is 36 char long...too small to be used, for example, as an ID to persist: I'd expect a lot of collisions.

I'd like to generate at least 128 char long string...by using the sha512 alg I was able to obtain a longer string but sha512 is meant to be secure, not efficient. What could I use to obtain longer ids but with low impact on performances?

Phate
  • 6,066
  • 15
  • 73
  • 138
  • 1
    Why not get several UUIDs and concatenate? – Sami Kuhmonen Mar 20 '18 at 19:31
  • 6
    "too small to be used, for example, as an ID to persist." really? You'd expect a lot of collisions? Then you expect wrong. – Kayaman Mar 20 '18 at 19:31
  • Generate 4 UUIDs and concatenate. Also we use UUIDs as primary keys with no issue. – Roddy of the Frozen Peas Mar 20 '18 at 19:31
  • 2
    Just for helpful reading check out [how good is java's UUID.randomUUID?](https://stackoverflow.com/questions/2513573/how-good-is-javas-uuid-randomuuid) – takendarkk Mar 20 '18 at 19:33
  • UUIDs with 16 hexadecimal characters offer approx. 2.2E43 choises. Thats a **lot** of possibilities. So collisions are very unlikely – eliaspr Mar 20 '18 at 19:33
  • 6
    I'm voting to close this question as off-topic because it's based on the misunderstanding of the author that UUID is somehow collision prone. – Kayaman Mar 20 '18 at 19:33
  • If you find that sha512'ing a 128bit UUID is a theoretically acceptable answer, you can just zero pad your UUID until it's the size you want. It'll be equally collision resistant but much faster. – that other guy Mar 20 '18 at 19:37
  • A UUID is by definition 128 **bits**, which is represented by 36 characters in that output. If you want something longer, it is **not an UUID**. In which case you are maybe searching for a way to generate a string of 128 characters. – Mark Rotteveel Mar 20 '18 at 19:43
  • 1
    The author of this Question has misunderstood [UUID](https://en.wikipedia.org/wiki/Universally_unique_identifier)s and has misunderstood how large a range of numbers is 128-bits (or 122-bits). As for largeness, read [this](https://blogs.oracle.com/bonwick/128-bit-storage:-are-you-high) or [this](http://www.swtor.com/community/showthread.php?t=372381). While a properly-produced Version 4 UUID is good enough for most purposes, if you want to eliminate any practical possibility of a collision, use Version 1. You can obtain those from Java libraries, native code, or from a database or web service. – Basil Bourque Mar 20 '18 at 19:47

1 Answers1

4

Your statement:

which is 36 char long...too small to be used

is most likely incorrect unless you are doing cryptography. This 36 characters are encoding 128 bit value as per Universally unique identifier. Assuming UUID version 4 returned by UUID.randomUUID() method, to quote the wiki further:

As in other UUIDs, four bits are used to indicate version 4, and 2 or 3 bits to indicate the variant (10 or 110 for variants 1 and 2, respectively). Thus, for variant 1 (that is, most UUIDs) a random version 4 UUID will have 6 predetermined variant and version bits, leaving 122 bits for the randomly-generated part, for a total of 2^122, or 5.3x10^36 (5.3 undecillion) possible version 4 variant 1 UUIDs.

You are extremely unlikely to experience any collisions ever in your code. They can happen but:

Thus, for there to be a one in a billion chance of duplication, 103 trillion version 4 UUIDs must be generated.

Karol Dowbecki
  • 43,645
  • 9
  • 78
  • 111
  • I would say “You are *extremely* unlikely to experience any collisions ever in your code.” Furthermore, to effectively eliminate any possibility of collision, use time-and-space-based Version 1 values rather than random-based Version 4. – Basil Bourque Mar 20 '18 at 19:50
  • Add the extremely part, it makes it clearer, thanks. – Karol Dowbecki Mar 20 '18 at 19:52