Comments 39
Что мы имеем: с увеличением количества хешей в массиве значение delta уменьшается и любая цифра почти с одной и той же вероятностью попадется в массиве
Вы берете рандомную строку, хешируете, и анализируете хеш. Поскольку входная строка рандомная, то Вы ожидали на выходе хеша что-то менее рандомное?
Я думаю, что тот же результат можно получить и без хеширования, совсем.
Я понимаю, если бы Вы взяли 0000001, затем 0000002, затем 0000003 и т.д., и тогда проанализировали хеш от этого.
Какой смысл хешировать РАНД?
Выяснить что хеш md5 хорошо работает? Это и так известно, есть много профессиональных доказательств.
Выяснить, что функция RAND дает равномерное распределение? Тогда зачем ее хешировать?
Можно напрямую подвергнуть Вашему статанализу сразу функцию RAND.
И еще.
Таким образом, чем больше выборка – тем меньше разница между часто встречающимся и редко встречающимися цифрами.
Странное утверждение, трудно понять что здесь сказано. Разница чего? Как разнятся «часто встречающиеся цифры» от «редко встречающихся цифр»?
Соответственно и вероятность получения той или иной цифры в хеше — стремится к равномерности.
А по моему, вероятность здесь статична и никуда не стремится.
P.S. Здесь Вас сильно «загнобили», но не унывайте, все образуется. :)
Соответственно и вероятность получения того или иного числа в хеше — равномерна.
Почему вы ставите численный эксперимент во вполне детерминированном алгоритме, который внятно описан? Почему результаты такого эксперименты вы считаете достаточными для такого утверждения? Вами проведены теоретические оценки масштабов ошибки как первого так и второго рода?
И отдельно, вы за три минуты статью про криптографию прочитали, или ответили не читая её?
что при увеличении массива хешей вероятность получения того или иного числа в хеше стремится к равномерностиЯ не спорю с утверждением, это вполне может быть так и есть. Однако те выкладки которые вы приводите не позволяют сделать такого вывода. Вы неграмотно используете слова из математического аппарата, пытаетесь по наитию строить какие-то гипотезы и как-то их проверять.
И отдельно, вы за три минуты статью про криптографию прочитали, или ответили не читая её?
статья старая, читал ранее.
А буковки a-f куда деваете? Отбрасываете? Почему? Зачем? А если весь хэш — это нечто вроде aafdeccdeffaabcaadf?
UPD: Ай, чуточку опоздал :)
А если весь хэш — это нечто вроде aafdeccdeffaabcaadf?
Проверял. Такова вероятность есть, но, например, на выборке в 1000000 хешей все равно в хеше присутствует минимум 8 цифр.
MD5 ("cbaabcdljdac") = cadbfdfecdcdcdacdbbbfadbcccefabd
как и вероятность того что MD5 хеш будет полностью цифровой:
MD5 ("aooalg") = 68619150135523129199070648991237
Но ваш эксперимент на целом миллионе хешей показал что так не бывает.
Нет, вполне могло быть что попадется хеш с меньшим количеством цифр, на скриншоте — анализ миллиона случайных хешей.
Я к тому что качество этого эксперимента и того что описан в статье идентично, они ничего не показывают.
Для меня данные, которые я получил и показал в статье показывают то, что с увеличением количества хешей в массиве значение delta уменьшается и любая цифра почти с одной и той же вероятностью попадется в массиве. На выборке из 100 хешей delta равна 22.17%, но на 10000000 — 0.06%. Для меня эти данные имеют прикладной характер и для проверки этого и делался эксперимент.
Эта информация легла в основу алгоритма, который мы реализовали на платформе для проведения конкурсов bepeam.com
А чем вас не устроил обычный генератор случайных чисел? Практически все они генерят вполне себе равномерно распределенные числа от 0 до скольки скажете. Совершенно непонятно, зачем мудохаться с md5 и выкусывать из hex-строки только цифры, рискуя остаться с очень коротким результатом.
Благодаря алгоритму определения победителя, который мы реализовали на bepeam.com любой посетитель может проверить достоверность результата розыгрыша, обычные генераторы такой возможности не дают.
Помню, был лет двадцать назад бум всяких онлайн-рулеток, так в одной из них предлагалось для проверки честности скачать зашифрованный rar-архив.
Предполагалось примерно такое взаимодействие с пользователем:
1. На сервере «загадывается», куда попадет шарик, и формируется архивчик с загаданным числом.
2. Пользователь скачивает архив и делает ставку.
3. После розыгрыша пользователю дается пароль для расшифровки архива, и он может убедиться, что загадано было именно то, что нарисовалось на экране.
Понятно, что способ проверки был очень муторный и никто этим не занимался.
Еще непонятно, как именно вы шифруете емейлы. Если шифрование секретное — значит, организатор методом подбора может подогнать нужный хэш. Если шифрование открытое, то это подарок для спамеров.
И непонятно, как в примере вы из числа 8505 получили ID пэрэможця 1711. Какая-то магия.
Пользователь делает ставку.
Между пользователем и сервером проходит генерация ключей (distributed key generation).
Каждая сторона имеет по одному ключу BLS, например.
Каждая сторона подписывает одно и тоже значение (initial vector) и шлет подпись другой стороне.
Подпись другой стороны валидируется.
Если верна, то каждая сторона подписывает подпись и получает итоговую подпись. Которая для BLS детерминирована относительно ключей и initial vector.
Каждая сторона смотрит на итоговую подпись mod (сколько у нас допустимых значений для загадывания). И узнает была ли победа.
Схема где никто никому не доверяет, но все получается
Если второе, то очень интересно. А если первое, то можете не утруждаться — таких алгоритмов можно с десяток за час придумать.
Второе пахнет distributed source of randomness. Или еще чем-то, что имеет свойство verifiable.
О! Собственная криптография! А не страшно?
О_о и что? Это же HEX представление хэша. Я могу сделать свой алфавит из abcdefghijklmno1 и анализировать частоту появления цифры 1 в хэше. Глупо же.
Анализ частоты появления цифр в хеше MD5