Crypto-API is stabilizing

[Thomas DuBuisson]

Marcel noted:
> A central interface to get the output of a PRNG would be nice,
> preferably not constrained to Int like RandomGen.

While BOS said:
> Also, don’t use RandomGen for your asymmetric PRNG. The
> default implementation in System.Random gives absolutely
> disastrous performance, and the typeclass is just
> misdesigned (the split function shouldn’t be present).

Ok, ok.  I never liked RandomGen either - I start this whole thing
because of my PRNG and it doesn't fit RandomGen one bit.

I've build Data.Crypto.Random.RandomGenerator - a new class that fixes
the aspects of RandomGen I don't like.  This is something I was
considering anyway, so it's probably best now and not as an API upset
in a couple months.

There is a blog on this [1], but the main points about the new class are:

1) Generates bytestrings, not Ints
2) Generalized PRNG construction and reseeding
3) 'split' is in a different class.
4) Clean failure via Either (RandomGen forced you to use exceptions)

And minor points
- Providing additional entropy while requesting data is allowed and
has a default instance so most users can ignore this all together.
- a newtype wrapper and instance allows all RandomGenerator instances
to be used as RandomGen when needed.

Who cares about this?  Anyone wanting to get random IVs for block
cipher modes (without getIV_IO) and anyone wanting to generate
asymmetric keys using the AsymCipher class.

What can you do?  Accept this API, help improve the API, or argue that
we should stick with RandomGen (despite short-comings noted on the
blog).  Please pick one and get to it!

Cheers,
Thomas

P.S. I would like to get crypto-api onto hackage by the end of the
first week of September, but understand this is a fairly large change
and will slide that date if there is an unusual strong objection.

[1] http://tommd.wordpress.com/2010/09/02/a-better-foundation-for-random-values-in-haskell/

>
> Designing a random interface that provides something as high a level
> as monad random, is easy enough to make instances for (like RandomGen)
> and is feature rich enough to allow reseeding, additional entropy
> input, personalization, and failure is a non-trivial design task.
> Having ran into the dilemma of how to provide a reasonable high-level
> interface for DRBG, I agree with your statement but don't know how a
> solution would look.
>
> FYI, BOS had a similar suggestion (on the blog) of moving away from
> RandomGen but I'm not clear on what I'd move toward.
>
> Cheers,
> Thomas
>