[Haskell-cafe] random library

[Thomas DuBuisson]

> I was looking at this recently; may I ask why drbg and crypto-api even
> bother to expose the possibility of CSPRNGs "running out" of entropy?

Because most standards discuss this possibility and my decisions at
the time were motivated by trying to make those implementations as
much of a mindless "translate English to Haskell" job as possible.

> This is not thought to be a concern on any cryptographically sound primitive

The primitive's soundness doesn't have anything to do with the period.
We can construct a sound cipher with small block size and claim the
counter mode of this cipher is a DRBG that is both secure and with a
small period.

> , and
> it substantially complicates both the implementation and the user-facing
> API.

The implementations are not substantially harder.  For the users I had
begun moving to exceptions with separate `.Pure` and `.Exceptions`
modules.  The API is all a bit long in the tooth and could stand for
me to spend some time on it though.

> The currently selected reseed interval of 2^48 is already large enough
> that it might as well not be there; it's too large to provide forward
> secrecy

Again, this is unrelated.  The instantiated Hash and HMAC DRBGs both
have forward secrecy and large intervals.

> and almost large enough that you'll never hit it.

Yes! That is the convincing argument right there.  The fact that no
user actually cares (beyond getting an exception instead of unsafe
operation) or will ever hit such a bound is rather important.

> Might I suggest in a future revision of the drbg/crypto-api libraries
> dropping all mentions of "Either" from the CryptoRandomGen typeclass API,
> except maybe "newGen"? I think this would make your job a lot easier *and*
> make the library a lot easier to consume (e.g. via RandT).

Well my job is easiest doing nothing.  But yes, making it nice for
users would be good.  I've been meaning to give these packages some
more attention and I'll take this as motivation.

-Thomas