Tradisys Aug 20 2019 at 12:06

RSA-рандом на блокчейне

5 min

3.6K

Waves corporate blogDecentralized networks*Cryptography*Cryptocurrencies

From sandbox

Comments 15

amarao Aug 20 2019 at 12:09

Я правильно понимаю, что речь про азартные игры на деньги (gambling)?

Tradisys Aug 20 2019 at 12:43

Только в тех странах, где криптовалюты приравниваются к финансовому инструменту. Россия и большинство других стран на текущий момент к таким не относятся.

Disasm Aug 20 2019 at 13:17

Берем одно и то же значение (game id) и применяем к нему метод RSA-подписи. Будем всегда получать один и тот же результат.

У вас какая-то странная RSA-подпись. В нормальной каждый раз должен получаться разный результат для одного и того же подписываемого блока данных.

deemru Aug 20 2019 at 15:12

Вы ошибаетесь.

Сама подпись RSA всегда была и остаётся детерминированной, разница только в схеме padding-а, которая может быть рандомизирована или нет.

Если само сообщение содержит рандомизированную часть, то padding может быть без ущерба для схемы детерминирован.

Disasm Aug 20 2019 at 15:18

Так тут и нет никакой рандомизированной части, как я понимаю. Любой злоумышленник, имеющий доступ к "подписывалке", может заранее узнать подпись, а следовательно и то "случайное" число, которое получится в GenerateRandInt. Если бы в реализации подписи фигурировал случайный паддинг, это было бы невозможно.

Tradisys Aug 20 2019 at 15:49

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

deemru Aug 20 2019 at 15:54

Любой злоумышленник, имеющий доступ к "подписывалке", может заранее узнать подпись

Гениально.

Luxo Aug 20 2019 at 15:23

Мы придумали обходной путь: использовать схему «коммит-раскрытие».

Кто мы? И честно — это вы придумали?

Оказалось, это неудобно, долго и дорого. На тот момент другого безопасного решения не было.

А разве привидённая схема удобней, короче или дешевле? Количество необходимых транзакций так же 2 — по одной от игрока и казино. Стоимость думаю приблизительно одинакова. Удобство — такое же. Сделал ставку, подождал пока она разрешится.

И на счёт RSA. По-моему можно генерировать разные валидные подписи к тем же данным. Что ведёт к тому, что вы можете легко обыгрывать игрока.

deemru Aug 20 2019 at 16:10

Да, действительно, многое зависит от предварительного кодирования сообщения (в основном есть ли там фиксированный паддинг или нет), но попросили именно детерминированную схему проверки, поэтому получили на уровне блокчейна набор s"${digestPrefix}withRSA", который гарантирует проверку на EMSA-PKCS1-v1_5.

k06a Aug 20 2019 at 18:00

Тоже не понял чем приведенная схема качественно отличается от стандартной commit-reveal, вы должны были уменьшить число транзакций хотя бы, а получили новые проблемы: если ваш привтаник один раз утечет выиграть у вас можно будет в любой момент в будущем. С тем же успехом можно было commits собрать в дерево меркла и reveal делать с меркл-пруфом. В известном всем проекте DICE2WIN помимо commit-reveal еще есть защита от реорга блокчейна.