>  I might have the IQ of a horse's arse but I completely fail to see how this dice roll example would apply to submitting a high score to a server.

He wasn't serious. There are algorithms for fair die roll, coin flip, and card shuffling. Those are probably sufficient to handle what the original poster (way back on page one asked for.

The more recent stuff about high scores is a different matter. I don't know a way for a normal algorithm to prove that you did what you say you did when all activity is confined to your machine and it only has the opportunity to look at the final result of a game playing session.

Maybe there is one, but I certainly don't know it.

He can re-read it all he likes, it still would not be correct.

You've yet to show how the simple algorithm I explained, one that can be found in any competent encryption textbook (alongside other algorithms that will show you how to do a fair coin flip or fair deal of cards between two parties), will not work.

You were right in part of what you said, "People have thought long and hard on this..." but you were wrong on all the rest. People have thought long and hard on this and they came up with some simple answers. You are simply choosing to ignore them.

>  You can complicate the procedure all you want but all you're really doing is making it computationally undesirable to cheat. And that is the best you can do when you don't control the system from start to finish.

"A difference which makes no difference, _is_ no difference."

>So what's to stop A sending B whatever key it likes to fudge the dice roll?

Plenty. See encryption algorithms are designed to be very one-way things.  In fact, the public key systems we use every day (e.g. e-commerce over the web) are a perfect example of that.  Even though, you, the client has both the public key for a site _and_ an example of an encrypted and decrypted message, you still can't work backward to figure out what the private key was that was used to encrypt that message.

Trying to work them backwards to generate a key that produces a particular message is nigh on impossible. What you are suggesting is that Inga is clever enough to make a message that can decrypt six different ways with six different keys (which any message does) AND that each of the messages makes sense and is a different valid ordering of the numbers 1-n. Sorry, that's not going to happen.  And even, if by some miracle, she has set a computer to calculating a set of keys + message that gets this result, she blows the whole combo on one die roll.

If she keeps sending the same message more than once then a more sophisticated client can easily detect the cheating. If she doesn't send the exact same key for the same message then he knows she's cheating. If she sends the same message and the same key then he's in a perfect opportunity to cheat by sending a specific return value to choose the roll rather than just randomly select it.

Sorry. I didn't go into a lot of depth. Let me try again.

1: Inga's computer makes a list like so.

641253

It is a random ordered list of the possible values for the die she is supposed to roll.

2: She encrypts the list using a key she randomly generates. It is a one-time-use key. After she uses it for encrypting this one die roll, she'll throw it away and generate a new one the next time she needs to roll.

key: 5791233243234

encrypted list: 114143

3: She sends only the encrypted list to Hans. She keeps the key on her machine.

4: Hans picks a number from 1-6. He sends that number over to Inga.

5: The die roll is now settled. Inga reveals the key to Hans. His PC decrypts the list and confirms that every number that was supposed to be on the die is in the list and appears only once (i.e. she couldn't just generate a list of all 6's). Her machine can independently figure out what he rolled just by looking up the value from the list using his choice.

In order to know what the die roll result was, Hans and Inga pick the nth element out of the list Inga generated, where n is the number Hans picked. So, for example, if Hans picks '3', then when the list is revealed to him he sees that the third element in the list was '1' so that's the result of the die roll. Inga can't influence which one he picks and he can't influence what will appear where he picks. And it's in the best interests of each side to be as random as possible in the generation of the list and the picking. If either side can predict what the other side does then he/she can take advantage of the bias.

Essentially it's the same thing as a fair coin flip. I'm allowed to flip, but you are allowed to choose heads or tails. Neither of us can cheat the other unless I can change the coins position after you pick. The encrypted list that Hans keeps in this case ensures that Inga can't change the list ex post facto.

The algorithm works for any size die and even for a coin toss (because a coin is effectively a two sided die). You could even roll multiple dice at once using a single encryption key with Hans making multiple choices (i.e. Inga sends 523164 231564 425631 (encrypted of course) and Hans picks the fourth element from the first group, the second  from the second, and the first from the third group before Inga reveals her key). When rolling multiple dice that will result in less key generation, less network traffic, and faster encryption/decryption.

Jesus Christ! It's good to see that people here are doing such thorough research...

> No. It's not possible, it will never be possible.

>People have thought long and hard on this and there are no solid answers.

Crap. Absolute crap. For at least the two player peer-to-peer system, how to roll dice is a well known problem. It takes about three steps and it boils down to this:

Inga: I'll generate a list of all the possible numbers on a die in a random order and write them down on this piece of paper. Then I'll lock it in this box and hand it to you.

Hans: No problem. Now, I'll pick a random number between 1 and the maximum value of the die. Then we open the box and look at the list to see what number that corresponds to. You can't cheat because I've got the list you used. I can't cheat because you don't give me the key to the box until I've picked a number.

Inga:Let me have your baby you algorithmic stud!

In practice, Inga just generates the list of numbers and sends it to Hans. She doesn't send the encryption key over for that list until he picks one. The whole negotiation can be hidden behind a die rolling class and it would take a very small fraction of a second. It would work just fine _WITHOUT_ using a server.

The only time it has problems is when there more than two players. Then it is possible for the other players to get shafted by collusion between Inga and Hans. In practice there are probably ways to deal with that problem too.

I think the answer to the question of "what does it do under Web Start" is that it depends upon what permissions your WS app has asked for.

If you've asked for full permissions and you've specified that your WS app needs 1.4 to run then you should be able to use any 1.4 API you desire. On the other hand, if you are not asking for permissions in your JNLP file then you are very restricted in what you can call. So you will probably have to use the WS mechanism for persistent storage. It is called muffins and is similar to the cookies mechanism that servers are allowed to use with browsers when they communicate via HTTP.

Personally, I'd rather use the 1.4 preferences stuff.