Comments 23
вместо S-code указываем предыдущее полученное число.хмм… а нет ли тут скрытого предпочтения? Т.е. вероятность, что вы выиграли 1ым — «размазана равномерно», а вот 2й выигрыш и далее — чаще выпадает на начало очереди и нечетные номера?
А почему на начало будет большее предпочтение?
sha256 — криптостойкая функция, что означает, в том числе, равномерное распределение результата для любого практически достижимого способа получения исходных данных
Не очень понимаю смысл перевода байт в hex- или base64-представление, кодирования в ascii и последующее хеширования.
Не проще ли напрямую хешировать массив байт?
Не вижу связи между daf5802953dcb27f89972e38e8900b898733f6a613e6e1c6c5491362c1832596 и числом 1.
А если вы хотели загрузить набор байт в gmp — то вам нужна функция gmp_import
Не важно в каком виде вы получаете данные от оракула — их всегда можно перевести к последовательности байт (в PHP, кажется, это называется "бинарная строка").
Дальше с этой строкой можно делать всё что вам нужно по алгоритму — импортировать в gmp и делить на число участников.
Нет. Вы вместо бинарной строки используете её hex-представление. Которое мало того что в два раза больше — так ещё и неоднозначно.
Если кто-то решит повторить ваш алгоритм на другом языке программирования — ему придется бороться со следующими проблемами:
- hex-представление может использовать прописные буквы вместо строчных, что изменит его хеш;
- hex-представление может содержать пробелы, что изменит его хеш;
- hex-представление может начинаться с префикса "0x" или заканчиваться суффиксом "h", что изменит его хеш;
- сам факт, что нужно считать хеш не от набора байт, а от его hex-представления, неочевиден.
Возможно это упростило бы код и позволило бы избежать лишних операций.
В статье приведен пример конкретной реализации на PHP, на других языках никакой борьбы не будет, получаете bin и доступными средствами преобразовываете его в int, если есть возможность, то без hex
А в данном примере hex представление является однозначным, т.к. мы получаем его самостоятельно, а не из сторонних источников и формат нам известен.
Другими словами: было удобно сделать именно так. Если можно проще — с удовольствием исправлю.
Я поэтому и спросил, знаете ли вы возможность более простого преобразования bin to int посредством PHP? Минуя hex.
Так я и ответил же: gmp_import, а дальше всё по вашему алгоритму.
В статье приведен пример конкретной реализации на PHP, на других языках никакой борьбы не будет, получаете bin и доступными средствами преобразовываете его в int, если есть возможность, то без hex
Увы, в таком случае получится другой результат. То есть провалидировать результаты вашей лотереи не получится.
Спасибо, подумаю над решением этого вопроса.
Хотя нет…
По большому счету суть не поменяется, результат останется прежним.
Как он останется прежним, когда sha256("1234") не равно sha256("\x12\x34")?
На сайте gchq.github.io/CyberChef/#recipe=SHA2('256') в INPUT даем наш S-code, в приведенном примере это:
Ri89jHB4UXZDXY6gT1m4LBDXGMTaYzHozMk4nxiuqVXdC
На выходе получаем:
daf5802953dcb27f89972e38e8900b898733f6a613e6e1c6c5491362c1832596
Дополняем 0x и отправляем на сайт defuse.ca/big-number-calculator.htm в виде:
(0xdaf5802953dcb27f89972e38e8900b898733f6a613e6e1c6c5491362c1832596 % 7 ) + 1
Получаем: 4
Как и в приведенном примере.
Это вы хеш hex-представления посчитали. А теперь добавляем перед sha256 шаг fromhex (он нужен потому что сайт не позволяет удобно ввести бинарную строку) — и получаем вместо вашего daf5802953dcb27f89972e38e8900b898733f6a613e6e1c6c5491362c1832596 какой-то 98f358536272a4550fdea5dbb1020a305b8ac5e38b1ec5af920f250d8a38f064.
Использование случайного оракула на примере лотереи