A critic of Guido's blog on Python's lambda

[Paul Rubin]

"Martin P. Hellwig" <mhellwig at xs4all.nl> writes:
> > This is a weird approach.  Why not let the "ticket" by the (maybe
> > encrypted) PRNG seed that generates the permutation?
> 
> Because the server that handles the generate request doesn't need to
> be the same as the one that handles the request to give the client
> that deck. 

Wait a sec, are you giving the entire shuffled deck to the client?
Can you describe the application?  I was imagining an online card game
where clients are playing against each other.  Letting any client see
the full shuffle is disastrous.

> But if the ticket is given to the client, than any other server can
> serve back that ticket to give the shuffled deck, unless the ZFS dies
> of course but then again thats why I use ZFS so I can mirror them om 4
> different machines in 2 different locations.

> > I don't know what good that hardware crypto is doing you, if you're
> > then writing out the shuffled deck to disk in the clear.
> 
> It's not about access security it's more about the best possible
> randomness to shuffle the deck.

Depending on just what the server is for, access security may be a far
more important issue.  If I'm playing cards online with someone, I'd
be WAY more concerned about the idea of my opponent being able to see
my cards by breaking into the server, than his being able to
cryptanalyze a well-designed PRNG based solely on its previous
outputs.