You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original bug ID: 5206 Reporter: lealanko Assigned to:@damiendoligez Status: closed (set by @xavierleroy on 2015-07-24T08:39:04Z) Resolution: fixed Priority: normal Severity: tweak Version: 3.12.0 Fixed in version: 4.00.0 Category: ~DO NOT USE (was: OCaml general) Monitored by:@dbuenzli
Bug description
I'm a bit concerned with OCaml's random seeds. I'm writing some distributed software and I'm generating random UUIDs which need to be unique across the network. However, it turns out that a random generator initialized with Random.State.make_self_init gets only 31 bits of entropy on a 32-bit platform, and in any case it uses only time and pid as seeds, without even trying to get any data that would be unique to the machine.
Even if the 31-bit seed function had perfectly uniform distribution, it would only require 7000 nodes for the possibility of a seed collision to be 1%. That is too close to comfort to be within the realm of possibility. What use is a 128-bit UUID if it is only generated from 31 bits of seed?
Obviously I can do my own seeding if I'm not satisfied with the default seed, and I will probably do that, but existing software that uses the default seeding function (e.g. the Uuidm library) would benefit from an enhancement.
So please make the default seeding function a bit stronger, by e.g. using /dev/(u)random where available, and without packing all the entropy into a single int.
The text was updated successfully, but these errors were encountered:
FWIW, there is support for /dev/random and EGD in cryptokit, probably uuidm should optionally use it (it will not cause binary dependency because of objects).
The self_init function is only intended for toy examples. If you need serious entropy, you should get it from the OS somehow. We don't provide it through the stdlib because there isn't any good portable way to do that, and providing a function with good entropy on some systems and bad entropy on others would be worse than nothing.
I'll "fix" this by documenting the fact that self_init provides low entropy and advising against its use in serious applications that need high entropy.
Since OCaml 4.00.0, Random.self_init uses /dev/urandom if it is available, so the situation should have improved, at least on platforms that support /dev/urandom (Linux, BSD, MacOS X, Solaris).
I second ygrek's suggestion to use Cryptokit if you need strong pseudorandom numbers.
Original bug ID: 5206
Reporter: lealanko
Assigned to: @damiendoligez
Status: closed (set by @xavierleroy on 2015-07-24T08:39:04Z)
Resolution: fixed
Priority: normal
Severity: tweak
Version: 3.12.0
Fixed in version: 4.00.0
Category: ~DO NOT USE (was: OCaml general)
Monitored by: @dbuenzli
Bug description
I'm a bit concerned with OCaml's random seeds. I'm writing some distributed software and I'm generating random UUIDs which need to be unique across the network. However, it turns out that a random generator initialized with Random.State.make_self_init gets only 31 bits of entropy on a 32-bit platform, and in any case it uses only time and pid as seeds, without even trying to get any data that would be unique to the machine.
Even if the 31-bit seed function had perfectly uniform distribution, it would only require 7000 nodes for the possibility of a seed collision to be 1%. That is too close to comfort to be within the realm of possibility. What use is a 128-bit UUID if it is only generated from 31 bits of seed?
Obviously I can do my own seeding if I'm not satisfied with the default seed, and I will probably do that, but existing software that uses the default seeding function (e.g. the Uuidm library) would benefit from an enhancement.
So please make the default seeding function a bit stronger, by e.g. using /dev/(u)random where available, and without packing all the entropy into a single int.
The text was updated successfully, but these errors were encountered: