At 11:09 PM 8/29/00 -0700, petro wrote:
> The trust issue can be dealt with by a combination of 2
>methods, first the traditional trust model--provide a consistent
>source of randomness over a long enough time, and people will trust
>it.
>
> Secondly, encrypt the random bits for delivery--that way the
>receiver can trust that the bits they get, they alone get.
You can't provide cryptographically trustable random numbers that way.
Run DES in counter mode, with a key and starting value known only to
the perpetrator, and you'll get high quality random numbers
which pass all the statistical tests gamers need,
but are still entirely owned, so not very useful cryptographically.
The main thing it does is lets gamers trust each other,
because it's a common stream of bits that none of them controls,
unless somebody hacks the transmission paths or the server itself.
The receiver has no way to trust that the bits they get aren't sent
to anybody else, because that requires knowing the server is Not Cheating,
and there's no way to know that. (Actually, you can do a bit better,
in that the receiver can decrypt the bits without the sender needing to
encrypt them first.)
It's not useless - you can use it to help seed PRNGs along with other
sources of entropy you've got locally, for times you need something
better than just the system clock and there's nobody at the console
to throw dice or wave a mouse.
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
