-
Notifications
You must be signed in to change notification settings - Fork 30.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cryptographically secure random integer in range #29707
Comments
@nodejs/tooling |
I think this would make a good addition. But.
|
In a generic "random" library I'd agree but since this is "crypto", I'm not entirely sure. At least, I personally am not sure what it would mean to implement it correctly nor feel very confident to do it (some relevant discussion here).
Shouldn't be too hard to add this argument. |
Yes, that could work. Another option is to make typeof randomInt(0, 42) // 'number'
typeof randomInt(0n, 42n) // 'bigint'
typeof randomInt(0n, 42) // TBD: 'bigint' or TypeError? Pro: lets callers support numbers and bigints transparently Con: potential for type confusion?
The problems around generating good, uniformly distributed random floating-point numbers is precisely why I think it would be good to have in core because I expect most people won't be aware of the subtleties with If nothing else, it lets us warn about distribution caveats in the documentation. An alternative approach is to:
Higher-level APIs can then be derived from the above primitives and wouldn't necessarily need to live in core. Technically even function randomBits(n) {
const t = n >>> 3
const u = n & 7
const b = randomBytes(t + !!u)
if (u > 0) b[t] &= (1 << u) - 1
return b
} I'm ignoring callbacks here for the sake of brevity. |
There was some related discussion on the BigInt proposal. I believe it was ultimately decided not to overload existing math functions to support BigInt. In the spirit of consistency, I would vote for an explicit If there's a chance it can get merged, I'd be happy to send a PR for |
@nodejs/crypto This needs your input. |
Bump |
Really not a fan of polymorphic signatures, not only because of type confusion but due to performance costs. I'd much rather just keep the variants separate. I can definitely get behind having these APIs in core. I'm less convinced on the floating point variant but I buy into @bnoordhuis' argument there. |
Feature seems reasonable to me. @orlonde, it sounds like a PR would be accepted, go for it. |
If we are only considering safe integers (that is, 53 bits or less), would the usual
This doesn't sound too bad to me. I am not a huge fan of bloating our APIs with functions that only differ in types, but I understand @jasnell's arguments. |
i think "random floats" are diverse enough of a problem that we should leave it to userland. we have int in range, float in range, int to float in range (e.g. 0x2440 for 10.0), list goes on. |
Likewise if uses end doing the type check after the function call. Code will already need to be aware that bigints are being used so a dedicated function is not going to make things more difficult there. |
Has there been any movement or progress on this feature? |
Attempting a pull request: #34600 |
That's could be a great functionality! |
A basic variant of this feature has landed in #34600, and will be available in future releases of Node.js. For further feature requests (e.g., use cases for random big integers), please open a new issue. |
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/random function getRandomInt(min, max) {
min = Math.ceil(min);
max = Math.floor(max);
//The maximum is exclusive and the minimum is inclusive
return Math.floor(Math.random() * (max - min) + min);
} |
@RodolfoSilva |
Thanks @madarche 😁. I hadn't paid attention to this note. My mistake. |
Is your feature request related to a problem? Please describe.
There is no API to obtain a random integer within a range. It's a common enough problem to deal with (e.g. to implement other algorithms like Fisher–Yates shuffle) and easy to get wrong. Most other runtimes/languages implement this in their standard library.
Describe the solution you'd like
Describe alternatives you've considered
I'm not sure about the internal implementation but I gave it a stab here: https://github.com/olalonde/crypto-range. http://www.pcg-random.org/posts/bounded-rands.html has a nice overview of different techniques (my implementation is probably not the most efficient).
The text was updated successfully, but these errors were encountered: