SHA-based subclass for random module

[Raymond Hettinger]

[Paul Rubin]
> I think it's best to stick with SHA, because of its longer hash,
> because it's a US federal standard, and because MD5 is already known
> to not meet its security goals (see Dobbertin's paper on finding
> collisions in MD5's compression function).

Okay, that is reasonable.



>  Python has already screwed
> up choosing its PRNG twice out of speed considerations, first with
> WHrandom, and when that wasn't random enough, then with MT, which
> still isn't random enough.

The cause won't be advanced by becoming a zealot or by insulting
people volunteering time to review your patch.  The three principal
maintainers of the module have been me, Tim, and Guido -- bashing all
three in one sentence is an unusual strategy ;-)

Also, the criticism of MT is baseless.



>  If we're selecting a PRNG for a third
> time, let's stop cutting corners and take care of the problem once and
> for all.

No corners were cut.  MT is a state-of-the-art psuedo random number
generator.  The problem is that you want encryption.

Haskell, Perl, Ruby, and SML also have not gone down your suggested
path.  A post to their newsgroups telling them that they are screwing
up and cutting corners likely will not be well received.  Of course,
that could just be part of the unusual strategy ;-)



> But MT has no security properties at all.  It's equivalent to just
> generating the whole output stream by hashing a sequential counter
> with a secret seed.

Right.  All of the security comes from the hashing step.



> No, I wanted cryptographic strength to both the left and right,
> otherwise I would have just hashed a counter.  I do care about
> inferring last week's numbers from this week's.  If you're playing
> poker with someone, you not only don't want him to see your cards
> unless he bets against you, you also don't want him to see the cards
> you were holding in the last hand when he folded.

That makes sense.  Still, the hashing step protects you.  Given a
series of 10,000 bits from the generator, do you have any means of
deducing either a) the state of MT, b) what came before, or c) what
comes after?


I'm keeping an open mind but will abandon this patch unless the tone
improves.



Raymond