Cryptographic random number generator Hash_DRBG, as defined in
NIST's SP800-90A.
The Hash_DRBG algorithm ("Hash - Deterministic Random Bit Generator") uses
SHA-2 (or optionally SHA-1) to stretch the useful life of a non-deterministic
entropy
source for security and cryptographic purposes, such as
single-use tokens,
nonces
or password salts.
While technically deterministic, Hash_DRBG is not intended for deterministic,
repeatable uses of psuedo-random number generation (such as generating randomized
interactive worlds with minimal-storage requirements - for which something like
Mt19937 would be better suited). For the sake of security, the algorithm is
intentionally defined to not support direct seeding and to automatically
accumulate (but never discard) entropy from not only a pre-determined source
of unpredictable entropy, but also from actual usage patterns. In that
spirit, this implementation is non-seedable, non-ForwardRange (only InputRange),
and all instances share a static state (albeit per thread, per EntropyStream type).
Mainly through the underlying HashDRBGStream (accessed via the stream member),
this supports the optional features of the Hash_DRBG algorithm. Specifically,
prediction resistance via forced reseeding, providing additional input for
each value generated, and custom personalization strings.
TSHA: Any SHA-1 or SHA-2 digest type. Default is SHA512.
custom: The Hash_DRBG algorithm's personalization string. You
can optionally set this to any specific value of your own choosing for
extra security.
EntropyStream: The source of entropy from which to draw.
The default is SystemEntropyStream!(), but can be overridden. If you provide
your own, then it's your responsibility to ensure your entropy source is
non-deterministic.
This is a convenience alias for WrappedStreamRNG!(HashDRBGStream, Elem).
Note that to conform to the expected InputRange interface, this must keep a
copy of the last generated value in memory. For security purposes, it may
occasionally be appropriate to make an extra popFront() call before and/or
after retrieving entropy values. This may decrease the chance of using
a compromised entropy value in the event of a memory-sniffing attacker.
Cryptographic random number generator Hash_DRBG, as defined in NIST's SP800-90A.
The Hash_DRBG algorithm ("Hash - Deterministic Random Bit Generator") uses SHA-2 (or optionally SHA-1) to stretch the useful life of a non-deterministic entropy source for security and cryptographic purposes, such as single-use tokens, nonces or password salts.
While technically deterministic, Hash_DRBG is not intended for deterministic, repeatable uses of psuedo-random number generation (such as generating randomized interactive worlds with minimal-storage requirements - for which something like Mt19937 would be better suited). For the sake of security, the algorithm is intentionally defined to not support direct seeding and to automatically accumulate (but never discard) entropy from not only a pre-determined source of unpredictable entropy, but also from actual usage patterns. In that spirit, this implementation is non-seedable, non-ForwardRange (only InputRange), and all instances share a static state (albeit per thread, per EntropyStream type).
Mainly through the underlying HashDRBGStream (accessed via the stream member), this supports the optional features of the Hash_DRBG algorithm. Specifically, prediction resistance via forced reseeding, providing additional input for each value generated, and custom personalization strings.
TSHA: Any SHA-1 or SHA-2 digest type. Default is SHA512.
custom: The Hash_DRBG algorithm's personalization string. You can optionally set this to any specific value of your own choosing for extra security.
EntropyStream: The source of entropy from which to draw. The default is SystemEntropyStream!(), but can be overridden. If you provide your own, then it's your responsibility to ensure your entropy source is non-deterministic.
This is a convenience alias for WrappedStreamRNG!(HashDRBGStream, Elem).
Note that to conform to the expected InputRange interface, this must keep a copy of the last generated value in memory. For security purposes, it may occasionally be appropriate to make an extra popFront() call before and/or after retrieving entropy values. This may decrease the chance of using a compromised entropy value in the event of a memory-sniffing attacker.
Declaration: