
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