Hacker News Reader

> Contrary to other languages, D's current standard implementation of UUID4 isn't cryptographically secure

It's hard to imagine a language designer choosing not to make such an import part of the standard library cryptographically secure. Is there a story behind this?

View on HN

UUIDs aren't supposed to be secure. They're aren't supposed to be unguessable. They're just supposed to be very unlikely to be duplicated. They have one use case: as universally unique identifiers. That's it. Any expectation or off-label use that goes beyond that is misuse. In other news, most hammers are found to be unsafe to use as toothpicks.

Relying on a client not being able to guess the next UUID is an attempt of security through obscurity, no? I don't think it's part of the requirement.

Relying on a client not being able to guess a random number is also important for Diffe-Hellman and like, all private key generation AFAIK. I don't think anything says private keys are security by obscurity because they require you to locally generate random numbers

Reply on news.ycombinator.com