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

[Martin P. Hellwig]

Paul Rubin wrote:
> "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.

Nope I have a front end service that does the client bit, its about this 
(in this context, there are more services of course):

crypto - ZFS - table servers - mirror dispatching - client xmlrpc access 
- client ( last one has not been written yet )

<cut>
> 
> 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.

Only client xmlrpc access is (should be) accessible from the outside and 
since this server is user session based they only see their own card.
However this project is still in it's early development, I'm doing now 
initial alpha-tests (and stress testing) and after this I'm going to let 
some audit bureau's check for security (probably Madison-Ghurka, but I 
haven't asked them yet).

-- 
mph