search

tc39 / proposal-uuid

UUID proposal for ECMAScript (Stage 1)
463 stars 7 forks source link

Should api be async? #32

Closed broofa closed 5 years ago

broofa commented 5 years ago

I alluded to this in https://github.com/tc39/proposal-uuid/issues/31#issuecomment-541204786.

The issue here is that CSPRNGs require a certain amount of entropy, which is typically supplied from the underlying system (electrical noise, hamsters flipping coins... whatever) at a limited rate. If there is not enough entropy, or it becomes depleted, then either the random # source has to block until enough entropy is available, or produce values that aren't cryptographically secure. For example, from urandom Man page:

if there is not sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic attack

Also, this Real-world issue

Assuming this is a fundamental issue with any CSPRNG, then it may make sense to make this API async, so underlying implementations can insure RNG quality without blocking calls to this API.

bakkot commented 5 years ago

I think this is a misunderstanding of how randomness is provided on modern systems. As I said in the other issue, that caveat from the manpages is misleading and has been removed and replaced with

The /dev/random interface is considered a legacy interface, and /dev/urandom is preferred and sufficient in all use cases, with the exception of applications which require randomness during early boot time

The node docs pertaining to the linked issue say something similar:

The crypto.randomBytes() method will not complete until there is sufficient entropy available. This should normally never take longer than a few milliseconds. The only time when generating the random bytes may conceivably block for a longer period of time is right after boot, when the whole system is still low on entropy.

That caveat appears to have been incorrect in older versions of electron, but that issue has apparently since been fixed, and does not reflect a fundamental issue with providing good randomness synchronously.

As an aside, entropy doesn't really "become depleted" in any meaningful sense.

bcoe commented 5 years ago

@broofa @bakkot I think we're starting to move towards a pretty reasonable idea, as to what a sync API for randomness would look like in #33. Is this conversation worth keeping open? or do you think the movement towards the Math.getRandomValues() option addresses this issue.

broofa commented 5 years ago

Based on @bakkot's comments, it sounds like this isn't a real concern. Closing.