# What encryption algorithm/package should I use in a betting game?

I have a betting type site where I publish a number (between 0-100) that is encrypted. Then after a period of time, I would review what the number is and prove it with a key to decrypt the encrypted number to prove that I'm not cheating. I also want it to be easily verifiable by an average user.

What encryption algorithm/technique/package should I use?

I'm no expert on cryptography. There seems to be so many options out there and I'm not sure what to use.

python friendly is a plus.

-
Is this for real money, or just an example? [Google python encryption] docs.python.org/library/crypto.html – Paul Aug 28 '12 at 18:52
No, not real money, but would still like it to be a secure as possible. – user299648 Aug 28 '12 at 18:55
I think there is a fairly specific answer, actually. Not sure why there are currently 3 close votes for not constructive. – psr Sep 17 '12 at 20:59

Use AES.. see Comparison of DES, Triple DES, AES, blowfish encryption for data for details..

As for ease of use.. refer you users to a Site Like: http://www.everpassword.com/aes-encryptor

-

You shouldn't use a cipher at all, but rather a cryptographic hash. If you state that the string hashed is a random 45-character alphanumeric string (with case), followed by a colon, followed by the number: e.g.

``````cxsFiEUK93Pl3e6bR1i40u7EyJgXQXf0JSejsuIQDcoGL:70
``````

and that the hash is SHA-256, that's enough for people who know what SHA-256 is to verify it. It's long enough that no-one will realistically be able to brute force it.

You also need to ensure that your random number source is good, and that's harder.

-
Couldn't a determined number guesser just build a table of hashes? – James Aug 28 '12 at 20:38
@James, that's what the random 45-character prefix is for. It raises the source entropy (including the entropy of the random number from 0 to 100) to about 270 bits, which is too much for a determined number guesser to tackle in a reasonable time on a reasonable budget. By the time 270 bits isn't enough, SHA-256 won't be enough either, because it won't be collision-resistent. – Peter Taylor Aug 29 '12 at 6:55
Ya sorry, I misread the second sentence – James Aug 29 '12 at 12:42

Conceivably this is a better question for the Stack Exchange Security site, but...

The fact that you have encrypted the number doesn't prove you aren't cheating. It just proves you encrypted the number. The question you are asking is called, probably among other things, Mental Poker. The idea is that every party needs to perform some random step and encrypt it.

I included the reference because it can get you started, but for a single random number one might do:

1. Alice picks a random number A from 0 to 99 and encrypts it.
2. Bob does the same for number B.
3. The "real" random number is (A+B) mod 100. This can be verified when both parties reveal their private keys.

You can use any single-key encryption for this simple scheme. You will have to generate lots of keys so they must be created using cryptographically strong key generation.

This scheme isn't computationally cheap.

You can probably do better for a specific algorithm, but hopefully this answer can get you started. I don't think any secure scheme will be all that cheap, but it isn't clear how many of these numbers you need.

-