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

[Paul Rubin]

Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:
> 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.

Ehhh, I guess you want the crypto hardware to generate physical
randomness for each shuffle.  I'm skeptical of the value of this since
a cryptographic PRNG seeded with good entropy is supposed to be
computationally indistinguishable from physical randomness, and if
it's not, we're all in big trouble; further, that hardware engine is
almost certainly doing some cryptographic whitening, which is a
problem if you don't think that cryptography works.

Anyway, if it's just a 52-card deck you're shuffling, there's only
about 226 bits of entropy per shuffle, or 52*6 = 312 bits if you write
out the permutation straightforwardly as a vector.  You could use that
as the ticket but if you're generating it that way you may need to
save the shuffle for later auditing.  

For practical security purposes I'd be happier generating the shuffles
entirely inside the crypto module (HSM) by cryptographic means, with
the "ticket" just being a label for a shuffle.  E.g. let

  K1, K2 = secret keys

  T(n) = ticket #n = AES(K1, n)  to prevent clients from guessing 
         ticket numbers

  shuffle(n) = HMAC-SHA-384(K2, n) truncated to 312 bits, treated as
         permutation on 52 cards

You could put some of the card dealing logic into the HSM to get the
cards dealt out only as the game as played, to decrease the likelihood
of any cards getting exposed prematurely.