Cryptographically secure random numbers?

Hi all, I'm in a situation where I have to generate cryptographically secure random UUIDs, i.e. ones that cannot feasibly be guessed/predicted. Does anyone know what options there are in this space? Ideally, I'd like to fulfill as many of these points as possible: - Few big/complicated dependencies. - Avoid native C if possible (ditto for non-base dependencies). - Avoid RDRAND if possible. - Non-opaque UUID type. - Cross-platform if possible, but the main platform would be Linux. (Generating a UUID from a random stream would be trivial, so obviously a library for secure random numbers would be a-okay too.) Any suggestions?

I've used this wrapper around the NaCl crypto library to generate random
numbers:
http://thoughtpolice.github.io/salt/
Nick
On Sunday, October 5, 2014, Bardur Arantsson
Hi all,
I'm in a situation where I have to generate cryptographically secure random UUIDs, i.e. ones that cannot feasibly be guessed/predicted.
Does anyone know what options there are in this space?
Ideally, I'd like to fulfill as many of these points as possible:
- Few big/complicated dependencies. - Avoid native C if possible (ditto for non-base dependencies). - Avoid RDRAND if possible. - Non-opaque UUID type. - Cross-platform if possible, but the main platform would be Linux.
(Generating a UUID from a random stream would be trivial, so obviously a library for secure random numbers would be a-okay too.)
Any suggestions?
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org javascript:; http://www.haskell.org/mailman/listinfo/haskell-cafe

I've reviewed a few of the crypto RNGs on my blog: http://tommd.github.io/posts/RNG-Bench.html - DRBG (disclaimer: my package) Three generators, HMAC, Hash, and CTR. All standards based and all using the Crypto.Random class interface from crypto-api. - cprng-aes One generator, afaict its an ad hoc creation of the author. - intel-aes Another ad hoc creation, but its more straight-forward (AES in counter mode) and has impressive performance.
Ideally, I'd like to fulfill as many of these points as possible:
- Few big/complicated dependencies.
True for threse packages, though my DRBG package does pull in crypto-api.
- Avoid native C if possible (ditto for non-base dependencies).
Avoid native C or avoid external C libraries? The DRBG generators could be paired with Adam's SHA package or Vincent's Haskell AES to give you a Haskell-only generator, but it will be slower than using the C implementations of AES or SHA2. This seems like a rather odd requirement.
- Avoid RDRAND if possible.
That's about the seed and not the generator. The `entropy` package now produces data that is an xor of urandom (or Windows cryptapi) and RDRAND (when available). RDRAND can be completely disabled by a flag in the cabal. I'm not sure what the `crypto-random` package does here, which is the entropy source typically used by `cprng-aes`, but I'd avoid it just because its lack of referential transparency.
- Cross-platform if possible, but the main platform would be Linux.
I think all of these are cross platform and in the past all the authors have been fairly responsive so send in any issues. Cheers Thomas

On 2014-10-05 19:21, Thomas DuBuisson wrote:
I've reviewed a few of the crypto RNGs on my blog:
[--snip--] It looks like I have a little reading to do :). Thanks to both of you! Regards,
participants (3)
-
Bardur Arantsson
-
Nicholas Vanderweit
-
Thomas DuBuisson