Доказуемо честная колода карт, используемая клиентом и сервером

Скажем, сервер играет в блэкджек с клиентом, и карты перетасовываются и раздаются сервером. Сама тасовка может быть честной, а может и нет, но необходимо показать, что сданные карты не изменились в ходе игры, т. е. после начала раздачи карты в колоде тайно не имеют своего значения. порядок изменен сервером.

Я думал о следующем решении с использованием криптографии и хотел получить отзывы, будет ли оно приемлемо для производственной системы, а если нет, то почему бы и нет:

Шаг 1) Сервер тайно перетасовывает колоду карт в каком-то порядке, скажем следующее (мы опускаем масть для простоты): [3, 9, 2, ..., A]

Затем он создаст следующее сообщение M:
M = "Перетасовка карт: [3, 9, 2, ..., A]. Случайное число: A96A...QT3"

Случайное число — это случайное число, которое сервер генерирует внутри себя и хранит в секрете до завершения игры. Его длины будет достаточно, чтобы предотвратить взлом хэша клиентом методом грубой силы (скажем, его длина составляет 512 символов).

Теперь сервер будет хешировать M, используя sha-256 или какой-либо другой надежный алгоритм хеширования, например: hash(M)

Шаг 2) Перед началом игры сервер отправляет этот хеш (M) клиенту, который клиент сохраняет. Клиент не может узнать M из того, что я могу собрать.

Шаг 3) Игра начинается, карты раздаются в перетасованном порядке, игрок принимает решения, и игра, наконец, завершается.

Шаг 4) Теперь клиент хочет знать, что игра была честной, т.е. сервер не обманывал, меняя карты во время раздачи. Теперь сервер отправляет сообщение «M» клиенту в виде открытого текста, чтобы показать это.

Шаг 5) Клиент запускает hash(M) и видит, что он совпадает с его hash(M), полученным на шаге 1.

Является ли это честным способом доказать, что игра была честной, без возможности мошенничества со стороны клиента или сервера, исключая возможность того, что само перемешивание не было случайным? Если бы сервер менял исходные карты во время раздачи, то клиент увидел бы это на шаге 5 (либо порядок явно отличался бы от клиента, либо хэш сообщения, отправленного на шаге 4). будет отличаться от отправленного на шаге 2). Кроме того, за раздачу отправляется только один хэш, поэтому сервер не может генерировать большое количество хэшей и отправлять их по отдельности, а затем выбирать лучший в ходе раздачи.

Расширить ответ knaccc, можно даже использовать схемы фиксации, чтобы доказать (до определенного момента), что сервер не обманывал во время перетасовки, например. как это:

1. Сервер выбирает случайное 128-битное число $х$ и 128-битный коэффициент ослепления $r_x$, и отправляет обязательство $c_x = H(x \,||\, r_x)$ клиенту.
2. Клиент выбирает случайное 128-битное число $у$ и отправляет на сервер. (Здесь никаких обязательств не требуется.)
3. Хэши сервера $х$ и $у$ вместе, чтобы получить 128-битное начальное число $s = H(x \,||\, y)$.
4. Сервер использует $s$ в качестве начального числа для детерминированного ГПСЧ и использует вывод ГПСЧ для детерминированного перемешивания колоды.
5. Игра ведется перетасованной колодой.
6. В конце игры сервер показывает $х$ и $r_x$, позволяя клиенту убедиться, что колода была перетасована правильно (и не была изменена после перетасовки).

Обратите внимание, что сервер может по-прежнему мошенничают, просматривая перетасованную колоду после шага 4 и прерывая игру (например, делая вид, что соединение было разорвано), если колода ему не нравится. Таким образом, клиент должен с подозрением относиться к серверам, которые часто обрывают соединения между шагами 2 и 5 или даже во время игры на шаге 5. В идеале клиент должен иметь способ попросить сервер возобновить прерванную игру в любой момент. и клиент должен быть очень подозрительно относятся к серверам, которые отказываются это делать.

(Надежная реализация такого механизма возобновления работы таким образом, чтобы он работал, даже если сервер выходит из строя и забывает состояние игры, кажется выполнимым, но, вероятно, выходит за рамки этого ответа. Задайте новый вопрос, если вам интересно.)

Также обратите внимание, что ослепляющее значение $r_x$ на самом деле не нужно здесь, так как $х$ сам по себе уже обладает достаточной энтропией, чтобы сделать грубое форсирование обязательства невозможным. На самом деле, возможно, было бы немного безопаснее опустить $r_x$ и просто сделай $х$ сам 256 вместо 128 бит.

Битовая длина $у$ и $s$ также можно увеличить при желании; 128 бит — это безопасный и практичный минимум. Нет смысла делать $s$ длиннее, чем общая длина $х$ и $у$ вместе, однако.