3 ms·

My understanding was that speed is not something you want in a UUID generator, since it makes it more susceptible to brute force attacks. Is this not the case?

• sdrapkin 1y ago
  cuid2 generates variable-length strings. If you want fast cryptographically strong string generation, I recommend https://github.com/sdrapkin/randstring https://github.com/sdrapkin/randstring. It will likely be faster than cuid2.
  • imiric 1y ago
    That doesn't address what I said. Nor explains why your package is better.
    • sdrapkin 1y ago
      Guid package generates guids/uuids. Your linked package generates variable length strings. These are different usecases (oh, and your benchmarks are inferior to https://github.com/sdrapkin/randstring https://github.com/sdrapkin/randstring). Nothing to argue about.
      • shakna 1y ago
        But this doesn't generate guid/uuids? It generates random bytes.
        • sdrapkin 1y ago
          Guid/uuid is defined as a 16-byte structure. Are you questioning the “byte” part, or the “random” part?
          • shakna 1y ago
            No, its defined to a series of specifications. [0] Ones that define an underlying structure, in bits. You have a 16byte random string. Thats great. But it is not a UUID. [0] https://www.rfc-editor.org/rfc/rfc9562.html https://www.rfc-editor.org/rfc/rfc9562.html > The UUID format is 16 octets (128 bits) in size; the variant bits in conjunction with the version bits described in the next sections determine finer structure.
            • sdrapkin 1y ago
              No, Guid/uuids are defined as 128-bit labels used to uniquely identify objects in computer systems. This 128-bit/16-byte definition predates any RFCs that one may or may not choose to implement. I'm obviously aware of RFC 9562, and nowhere in the Guid library do I claim implementation of it. RFC 9562 is a choice, and one that should not be made blindly, or for you. It all starts with 16 random bytes. Google's uuid starts that way, and virtually every other Guid/uuid implementation. Then, on top of that building block, one may tweak additional non-random bits if the usecase truly requires it. If it does - you can do it quickly and cheaply on top of 16 random bytes. If the usecase does not require it (99% of cases), you're better off with the foundational 16 random bytes. The perspective of "your 16 random bytes do not implement RFC 9562 - BAD, BAD!" is very myopic. But if wasting bits on versions and variants is something that helps someone sleep better - they can easily and cheaply achieve that with a couple of bit ops. RFC 9562 robs developers of that choice.
              • shakna 1y ago
                Ok... But if you want to ignore the last twenty years, you should probably pick another name, because it has been used a particular way for two decades. If you want "more choice" - use a name unbound by a tradition old enough to drink.
      • imiric 1y ago
        No need to argue. You just haven't addressed the point that a fast UUID generator is a security risk. I don't care about benchmarks. And in most use cases where I'd need a UUID, I'd usually want the string representation of it.
        • sdrapkin 1y ago
          Fast guid/uuid generators are NOT a security risk. You want such generators to be as fast as possible, without compromising cryptographic strength.
• stouset 1y ago
  > My understanding was that speed is not something you want in a UUID generator, since it makes it more susceptible to brute force attacks. Is this not the case? The only possible think I can think of here is using a UUID version with a small space for the random bits, such that you could accidentally collide by generating them too fast. But with something like UUIDv7, you'd need to be generating hundreds of millions of random UUIDs every nanosecond in order for that to be a realistic concern.