We will upgrade our BlackJack algorithm.
The game uses asymmetric encryption RSASSA-PKCS1-v1_5 mode.
The server has the [Privatekey] and announce the [Publickey].
Here is the [Publickey].
-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDE9QKpw5CHZyf+OfcrT5MCeiCR
CLVZjDVUSPGzwXdoGAcRi/r9y7T8t4/byXNTLky0h9dUGKBowwN7bt7fgMKvWAtz
0Xf4ztfpsEoRHrzRs2r8khPUjihjrz0N+oPQ+ktAh7M95ZnQfgt/hNWFevGRd+SV
sGsWhO8VFrBYb7nS8wIDAQAB
-----END PUBLIC KEY-----
1. Encrypt the [Issue] and [Salt] with HmacSHA256 to get [Hash].
2. Sign [Hash] with the [Privatekey] to get the [Seed].
3. Using the [Seed] to shuffle cards.
4. [Seed] is announced after the end of game.
5. The client can use the [Publickey] to verify the signature.
Before being used to calculate the corresponding result, each game hash is salted with the lowercase, hexadecimal string representation of the hash of bitcoin block 592,600
This block has not been mined yet at the time of starting the provably fair seeding event, proving that I have not deliberately picked a chain that is unfavorable for players.
Another point that players need to notice:
In the first player position, there is a risk that the robot sitting there and interfere you to get a good hand
(we won't do that, swear in coco's tooth.At the same time, we will work hard to solve the possible robot problems in PVP games and provide a fairer environment for players.)
We suggest you leave the room if the there are full of weird frogs instead of your friends.
Good luck!
Can I claim the eth bounty? This is not provably fair, because step-2 is not verifiably deterministic. You could create as many different "[Seed]" as you wanted with RSASSA-PKCS1-v1_5 signing, that all pass the test 5 by twiddling with thing like the padding and stuff. For this scheme to work, you'd need to use a digital signature algorithm that generated only a single valid signature for a given message.
Thank you for your attention and questioning! It will make us more transparent and fair!
RSASSA-PKCS1-v1_5 algorithm used 0xFF to padding, so the same input get same ouput.
Replace the verification program last line with this command, you could see the padding.
openssl rsautl -verify -in signature.sign -inkey pub.pem -pubin -raw -hexdump
Example:
#!/bin/bash
# Defining variables
bj_issus='20303'
bj_slat='00000000000000000009e93621499e5a63d79a6293609ce52e95e93dd49cb1be'
bj_signature='Kwn2sjCh3wvd86vwIvqPhlOWYGArMBSuE6JK6EiFULMBGx468x67Gh8lTKXlWi5e53tGGwP/RO6t+Cwim20tFe+es0c9oeGysAubf7zzkJnwxHQ0SwZ/OnHv40a/UnBNtBFiNYE77g/F9LJxwGymQVpa1StSgQibe9vdcjgAP/E='
# Save public key
echo '-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDE9QKpw5CHZyf+OfcrT5MCeiCR
CLVZjDVUSPGzwXdoGAcRi/r9y7T8t4/byXNTLky0h9dUGKBowwN7bt7fgMKvWAtz
0Xf4ztfpsEoRHrzRs2r8khPUjihjrz0N+oPQ+ktAh7M95ZnQfgt/hNWFevGRd+SV
sGsWhO8VFrBYb7nS8wIDAQAB
-----END PUBLIC KEY-----' > pub.pem
# Save signature
base64 --decode <<<$bj_signature > signature.sign
# HMAC slat and verify
#echo -n $bj_issus | openssl dgst -sha256 -hmac $bj_slat -binary | openssl dgst -sha256 -verify pub.pem -signature signature.sign
openssl rsautl -verify -in signature.sign -inkey pub.pem -pubin -raw -hexdump
You could get the padding content which is 0xFF
0000 - 00 01 ff ff ff ff ff ff-ff ff ff ff ff ff ff ff ................
0010 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff ................
0020 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff ................
0030 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff ................
0040 - ff ff ff ff ff ff ff ff-ff ff ff ff 00 30 31 30 .............010
0050 - 0d 06 09 60 86 48 01 65-03 04 02 01 05 00 04 20 ...`.H.e.......
0060 - a9 4d d2 4b 91 dc 8d be-75 71 b7 b8 4f 2f df 92 .M.K....uq..O/..
0070 - 4b f9 2a 3d 60 20 98 4f-1d b3 00 fb 46 d8 10 d2 K.*=` .O....F...
:p
