Thomas DuBuisson
Vincent has done great work for Haskell+Crypto so I think he knows I mean nothing personal when I say cprng-aes has the right idea done the wrong way. Why a new effort vs Vincent's package?
1. cprng-aes is painfully slow. 2. It doesn't use NI instructions (or any C implementation, currently). 3. It isn't backtracking resistent. I plan to follow the SP and test against the KATs.
I can't really tell whether the first two points are true. If they are, they should be really easy to fix and don't really require a new package possibly with yet another interface. The great thing about cprng-aes is its simplicity. It fulfills the design requirements for an opaque, secure cryptographic library. When you use the Crypto-API interface it's really difficult to use the generator incorrectly. About the third point: This should be easy to fix and would probably be the only breaking change (in that it would generate different sequences than before). However, it is questionable whether you want AES at all in this case. A hash function-based PRNG would probably be better. This could indeed justify a new library. On the other hand you want NI instructions. In any case I would contact Vincent about all this. It would be great if those changes could be incorporated transparently.
4. Lots of people still use "random" by default, so it would be good to have StdGen be something reasonable, where "reasonable" is from as many perspectives as we can manage.
Of course this is not cprng-aes' fault, so this point is one of its own
unrelated to my original response. StdGen is really unfortunate and
should be replaced, but by what? In an older thread this question
turned out to be difficult to answer. An AES-based PRNG would probably
be a good compromise, but that is only my opinion.
Greets,
Ertugrul
--
Key-ID: E5DD8D11 "Ertugrul Soeylemez