2 ms·

FWIW in Tcl it's fairly easy to generate random numbers from /dev/urandom on Unix-like systems[0]. It involves opening /dev/urandom, reading 8 bytes from the d

by jrapdx3 10y ago

FWIW in Tcl it's fairly easy to generate random numbers from /dev/urandom on Unix-like systems[0]. It involves opening /dev/urandom, reading 8 bytes from the device, binary scan of the returned value, converting from the hex format and scaling the result to fall within a specified min to max range. The tcllib has other PRNG procedures, and there's the "Random" package ISAAC implementation. Whether output quality of any of these procedures is adequate probably depends on the purpose. [0] http://tcl.wiki/29163 http://tcl.wiki/29163

junke 10y ago
Reading this story, I was curious about ISAAC, so I posted a link to its webpage in another post (https://news.ycombinator.com/item?id=12441451 https://news.ycombinator.com/item?id=12441451), hoping people would give their opinion on it. Do you have experience with ISAAC?
- jrapdx3 10y ago
  That's the same link provided in the Tcl wiki. I haven't actually used the ISAAC generator since the urandom is considered reliable. However, urandom is only available on Linux/BSD systems, on Windows alternatives are necessary. From the comments on the ISAAC home page, the ISAAC and ISAAC-64 versions would appear adequate for most uses, but a reader more experienced in CSPRNG analysis might have more information.
pwg 10y ago
> reading 8 bytes from the device, binary scan of the returned value, converting from the hex format It is not necessary to round trip through a hex encoding. Tcl's binary scan is capable of converting an 8 byte value directly into a 64-bit signed or unsigned integer. You can even request big or little endian interpretation of the bytes. Check the "w" conversion flag in the man-page. For unsigned you'd add the "u" flag. For big-endian conversion use the "W" flag instead.
zAy0LfpBZLC8mAC 10y ago
> and scaling the result to fall within a specified min to max range. This is actually incorrect. Unless the size of the range is a power of two, this gives non-uniform probability. The bias might be acceptable if it's small enough, but it's something to be aware of, and, if you want to have something robust, to avoid. A general safe strategy is to check if the raw random value is below the maximum multiple of the size of the range that's no greater than the number of possible values for the raw random value, and if not, generate a new one and repeat. (In principle, any smaller multiple (>= 1) would work as well, but taking the maximum gives the smallest number of retries.)

by jrapdx3 10y ago

junke 10y ago

Reading this story, I was curious about ISAAC, so I posted a link to its webpage in another post (https://news.ycombinator.com/item?id=12441451 https://news.ycombinator.com/item?id=12441451), hoping people would give their opinion on it. Do you have experience with ISAAC?

jrapdx3 10y ago
That's the same link provided in the Tcl wiki. I haven't actually used the ISAAC generator since the urandom is considered reliable. However, urandom is only available on Linux/BSD systems, on Windows alternatives are necessary. From the comments on the ISAAC home page, the ISAAC and ISAAC-64 versions would appear adequate for most uses, but a reader more experienced in CSPRNG analysis might have more information.

pwg 10y ago

> reading 8 bytes from the device, binary scan of the returned value, converting from the hex format It is not necessary to round trip through a hex encoding. Tcl's binary scan is capable of converting an 8 byte value directly into a 64-bit signed or unsigned integer. You can even request big or little endian interpretation of the bytes. Check the "w" conversion flag in the man-page. For unsigned you'd add the "u" flag. For big-endian conversion use the "W" flag instead.

zAy0LfpBZLC8mAC 10y ago

> and scaling the result to fall within a specified min to max range. This is actually incorrect. Unless the size of the range is a power of two, this gives non-uniform probability. The bias might be acceptable if it's small enough, but it's something to be aware of, and, if you want to have something robust, to avoid. A general safe strategy is to check if the raw random value is below the maximum multiple of the size of the range that's no greater than the number of possible values for the raw random value, and if not, generate a new one and repeat. (In principle, any smaller multiple (>= 1) would work as well, but taking the maximum gives the smallest number of retries.)