
NUID – An entropy friendly and highly performant unique identifier generator - tylertreat
https://github.com/nats-io/nuid
======
tptacek
There is no such thing as "entropy draining".

If it's higher-performance than other UUID generators, fine, that's a win. But
it's not doing anything useful for the system as a whole by sparing the
"entropy pool".

~~~
derekcollison
I disagree, either the entropy is drained and the randomness of what the pool
returns (based on OS) is compromised or you get stalled waiting for more of it
and decrease performance of the generator.

[https://www.google.com/webhp?q=draining+entropy+pool](https://www.google.com/webhp?q=draining+entropy+pool)

~~~
nullc
In the immortal words of Timecube: "You have been educated stupid".

Fortunately, salvation is readily at hand: [http://www.2uo.de/myths-about-
urandom/](http://www.2uo.de/myths-about-urandom/)

~~~
derekcollison
I think entropy, in however you measure it, does influence something like a
UUID generator differently than the cryptographic algorithms. What you are
trying to achieve, or more importantly the condition you are trying to avoid,
is different.

------
heavenlyhash
I wrote Yet Another UUID [1] for my own purposes recently as well. Mine's
based on Firebase's style UIDs [2] -- they sort roughly chronologically,
because operationally, I find that irritates me less. Arbitrary choice?
Entirely. Regrets? None. Do I recommend it for use? Also not at all. Unless
you feel like it. It's fine. I guess.

I've kind of given up on there being any purpose to a One True Spec for UUIDs.
Count how many bits of entropy you want. Shove some CSPRNG into it. Call it a
day.

¯\\_(ツ)_/¯

(This a fine implementation, fwiw. I only mean to share my honest question as
to whether there's any real utility to UUIDs-as-a-library.)

[1]
[https://github.com/polydawn/repeatr/blob/dd41ca72421a173b5aa...](https://github.com/polydawn/repeatr/blob/dd41ca72421a173b5aa14580f5d7df48df1548d0/lib/guid/guid.go)
[2] [https://www.firebase.com/blog/2015-02-11-firebase-unique-
ide...](https://www.firebase.com/blog/2015-02-11-firebase-unique-
identifiers.html)

~~~
derekcollison
I agree, was simply sharing because it was a need we had, which might be a
need someone else had as well. Anyone can feel free to use it or not.

------
fweespeech
> NUID needs to be very fast to generate and be truly unique, all while being
> entropy pool friendly. NUID uses 12 bytes of crypto generated data (entropy
> draining), and 10 bytes of pseudo-random sequential data that increments
> with a pseudo-random increment.

> Total length of a NUID string is 22 bytes of base 36 ascii text, so 36^22 or
> 17324272922341479351919144385642496 possibilities.

Isn't 22 bytes = 176 bits?

UUID = 128 bit

Storage performance is more than per-ns on a CPU core, imo.

~~~
sheng
UUIDs are 120 Bit or less. Depending on the Version you use. But you lose 8
bit on any version because 1 byte is used to decode the UUID version.

~~~
fweespeech
Yes. 128bit is the worst case for UUIDs, I was trying to avoid the claim I was
being overly generous by using the smallest size I could get away with. ;)

------
jamesrom
Why on earth would you care about entropy for a UUID?

You can use the most basic PRNG to generate your 128 bits. There's your UUID.

Call me when you find a collision.

~~~
wongarsu
A basic PRNG might not be enough if you care about malicious collisions.
There's plenty of cases of UUIDs being used in a context where a CSPRNG is
preferable.

------
NuSkooler
What's the use case here over a UUID?

~~~
tylertreat
Performance mainly, I think. Benchmarking against UUID v4 shows a ~175%
speedup.

~~~
derekcollison
UUID V4 is ~900ns/op, NUID is ~60ns/op, so 15X speedup, or 1500%.

------
nullc
"Entropy draining" :(

