Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 128
Ну хоть теперь параноики поуспокоятся =)
Этого не будет никогда! Мы не сдадим своих позиций, большой брат не дремлет.
Однако, если он является автором оригинального файла, он может создать две версии файла с одинаковой хеш-суммой: безобидную и вредоносную, отдать на публичное изучение безобидную, а затем на этапе распространения незаметно менять версию на вредоносную — проверка на основе только хеш-функции этого не заметит.
Так и думал что Google Chrome и Android с трояном распространяются… :)
Выживают только параноики
Если у вас паранойя — это еще не значит что за вами ни кто не следит =) (с) видимо «народ»
Европейские криптологи нашли уязвимость в ГОСТ Р 34.11-94
Конференция Crypto 2008 продемонстрировала значительный прогресс криптологов в деле анализа и взлома hash-функций. В частности была представлена модель атаки на ГОСТ Р 34.11-94 — российский криптографический стандарт вычисления хэш-функции. Также специалисты продемонстрировали первый практически реализуемый взлом сокращенного варианта SHA-1 методом инверсии, на основе которого можно из хеша вычислить исходный пароль.
ГОСТ Р 34.11-94 до сих пор считался одним из самых защищенных криптографических стандартов. Но теперь объединенная команда специалистов Технологического Университета из города Граз (Австрия) и Варшавского Военного Технологического университета нашли неожиданную техническую уязвимость и использовали ее для проведения атаки. В результате коллизионная атака завершилась в 2^23 раза быстрее, чем ожидалось. Суть коллизионной атаки заключается в подборе случайной строки, хеш-функция которой совпадает с заданной.
Для сравнения первая успешная коллизионная атака на SHA-1 уменьшила число требуемых вариантов перебора в 2^11 раз, до 2^69 вместо 2^80. Но ГОСТ Р 34.11-94 пока еще рано сбрасывать со счетов: при результирующей сумме размером 256 бит потребуется 2^105 итераций для полной расшифровки исходной строки. Способности современной вычислительной техники пока не позволяют выполнять вычисления такого уровня в реальные сроки.
Все известные атаки на хеш-функции, такие как SHA-1 и теперь ГОСТ Р 34.11-94, были коллизионными атаками. Проведение их на практике имеет смысл только в случае цифровой подписи документов, причем если взломщик имеет доступ к не подписанному оригиналу. Использование криптоалгоритмов для других целей, таких как защита паролей, не подвержено влиянию описанной атаки, поэтому организация по стандартам США — NIST продолжает рекомендовать SHA-1 для этих целей.
Хотя большинство криптоатак пока что представляют чисто теоретическую угрозу, необходимо помнить, что усилия по анализу хеш-функций еще достаточно далеки от адекватных и значительный прорыв в этой области в будущем не может быть исключен. Принимая во внимание ведущийся поиск кандидатуры на стандарт 2012 года SHA-3, задача выбора наилучшей хеш-функции становится как никогда остро.
Конференция Crypto 2008 продемонстрировала значительный прогресс криптологов в деле анализа и взлома hash-функций. В частности была представлена модель атаки на ГОСТ Р 34.11-94 — российский криптографический стандарт вычисления хэш-функции. Также специалисты продемонстрировали первый практически реализуемый взлом сокращенного варианта SHA-1 методом инверсии, на основе которого можно из хеша вычислить исходный пароль.
ГОСТ Р 34.11-94 до сих пор считался одним из самых защищенных криптографических стандартов. Но теперь объединенная команда специалистов Технологического Университета из города Граз (Австрия) и Варшавского Военного Технологического университета нашли неожиданную техническую уязвимость и использовали ее для проведения атаки. В результате коллизионная атака завершилась в 2^23 раза быстрее, чем ожидалось. Суть коллизионной атаки заключается в подборе случайной строки, хеш-функция которой совпадает с заданной.
Для сравнения первая успешная коллизионная атака на SHA-1 уменьшила число требуемых вариантов перебора в 2^11 раз, до 2^69 вместо 2^80. Но ГОСТ Р 34.11-94 пока еще рано сбрасывать со счетов: при результирующей сумме размером 256 бит потребуется 2^105 итераций для полной расшифровки исходной строки. Способности современной вычислительной техники пока не позволяют выполнять вычисления такого уровня в реальные сроки.
Все известные атаки на хеш-функции, такие как SHA-1 и теперь ГОСТ Р 34.11-94, были коллизионными атаками. Проведение их на практике имеет смысл только в случае цифровой подписи документов, причем если взломщик имеет доступ к не подписанному оригиналу. Использование криптоалгоритмов для других целей, таких как защита паролей, не подвержено влиянию описанной атаки, поэтому организация по стандартам США — NIST продолжает рекомендовать SHA-1 для этих целей.
Хотя большинство криптоатак пока что представляют чисто теоретическую угрозу, необходимо помнить, что усилия по анализу хеш-функций еще достаточно далеки от адекватных и значительный прорыв в этой области в будущем не может быть исключен. Принимая во внимание ведущийся поиск кандидатуры на стандарт 2012 года SHA-3, задача выбора наилучшей хеш-функции становится как никогда остро.
Как-то не вяжется: " не должно существовать способа (...) вычислить какую-либо пару входных текстов, дающих на выходе одинаковое хеш-значение" с «Однако, если он является автором оригинального файла, он может создать две версии файла с одинаковой хеш-суммой».
Я понимаю, что здесь по-сути говорится про обратные по направлению операции, но хеширование-то необратимо! Коллизию можно вызвать только брутфорсом, а брутфорс вовсе не обещает, что в обоих случаях вы получите осмысленный материал.
Я понимаю, что здесь по-сути говорится про обратные по направлению операции, но хеширование-то необратимо! Коллизию можно вызвать только брутфорсом, а брутфорс вовсе не обещает, что в обоих случаях вы получите осмысленный материал.
А иногда осмысленный и не нужен, например, в случае с сертификатами. У вас есть сертификат, подписанный серьезной конторой, по сути он является набором 16-ричных символов, вы можете подобрать другой набор 16-ричных символов, который будет проходить проверку подписи сертификата. Ну это так, кратенько, поверхностно, упрощено =)
Но опять же, как сказано в статье, это возможно только в том случае, когда злоумышленник заранее подготовил первый набор символов, который затем подписал центр сертификации. Насколько я понимаю, это сейчас невозможно.
Здравствуйте, я ваша тётя. Очень даже возможно :-)
Да, интересная инфа. Надо будет на досуге почитать и что-нибудь попробовать.
Но вообще говоря, про коллизии MD5 знали уже очень давно. Поэтому при генерации ЭЦП используется SHA-1.
Кроме того, сертификаты на сервера выдаются сроком на 1-2 года, поэтому думаю, что 99,8% процентов ssl-сертификатов подписаны SHA-1.
Думаю, причин для паники нет!
Но вообще говоря, про коллизии MD5 знали уже очень давно. Поэтому при генерации ЭЦП используется SHA-1.
Кроме того, сертификаты на сервера выдаются сроком на 1-2 года, поэтому думаю, что 99,8% процентов ssl-сертификатов подписаны SHA-1.
Думаю, причин для паники нет!
И что это будет?
Мне нужно совершить следующую атаку на ЭЦП: подменить текст «Private text» на что-то другое.
У меня есть возможность перехватить трафик от сервера к клиенту. Надо понимать, что в случае с ЭЦП основной текст вовсе не обязан шифроваться.
Что делает сервер: Хеширует «Private Text», шифрует хеш своим закрытым ключом, приклепляет в чистом виде фразу «Private text» и отправляет ее клиенту.
Сначала я сообщение перехватываю, открепляю фразу «Private text», ставлю «Hacked text» и шлю дальше. Клиент расшифровывает хеш открытым ключом, хеширует «Hacked text» и сравнивает хеши. Они не совпадают. Не работает.
Дальше я снова меняю «Private text» на «Hacked text», подписываю левым ключом, шлю дальше. Клиент не может расшифровать хеш. Снова не работает.
Тогда я брутфорсю в следующем виде: расшифровываю открытым ключом сервера хеш, под этот хеш в течении 40 лет подбираю коллизией другой текст, в почтенных годах клиенту вместо «Private text» приходит "!^%*&Bgwuhg36*%^(*r72". Клиент пытается понять, что это за бред, но почтенный возраст и старческий маразм не дают возможности осмыслить бинарный поток. Клиент разочарован.
Так где конкретно уязвимость? Коллизия была, есть и будет. Но пока нельзя под что-то осмысленное подобрать что-то другое осмысленное, то это, простите, фигня.
Мне нужно совершить следующую атаку на ЭЦП: подменить текст «Private text» на что-то другое.
У меня есть возможность перехватить трафик от сервера к клиенту. Надо понимать, что в случае с ЭЦП основной текст вовсе не обязан шифроваться.
Что делает сервер: Хеширует «Private Text», шифрует хеш своим закрытым ключом, приклепляет в чистом виде фразу «Private text» и отправляет ее клиенту.
Сначала я сообщение перехватываю, открепляю фразу «Private text», ставлю «Hacked text» и шлю дальше. Клиент расшифровывает хеш открытым ключом, хеширует «Hacked text» и сравнивает хеши. Они не совпадают. Не работает.
Дальше я снова меняю «Private text» на «Hacked text», подписываю левым ключом, шлю дальше. Клиент не может расшифровать хеш. Снова не работает.
Тогда я брутфорсю в следующем виде: расшифровываю открытым ключом сервера хеш, под этот хеш в течении 40 лет подбираю коллизией другой текст, в почтенных годах клиенту вместо «Private text» приходит "!^%*&Bgwuhg36*%^(*r72". Клиент пытается понять, что это за бред, но почтенный возраст и старческий маразм не дают возможности осмыслить бинарный поток. Клиент разочарован.
Так где конкретно уязвимость? Коллизия была, есть и будет. Но пока нельзя под что-то осмысленное подобрать что-то другое осмысленное, то это, простите, фигня.
Но пока нельзя под что-то осмысленное подобрать что-то другое осмысленное, то это, простите, фигня.Я правильно понимаю что сертификат на имя банка, проходящий валидацию в браузерах — «это, простите, фигня»?
Вот тут — подробное описание.
Генерируются два сертификата:
Первый — на фирму «Вася Пупкин и Ко», вполне легальный, не вызывающий подозрений.
Второй — неважно на кого, но с флагом, позволяющим подписывать другие сертификаты.
Первый сертификат подписывается за положенные $NN (оплата с подарочной карточки), с помощью второго — генерируются «легальные» сертификаты для сотни-другой банков.
Атака вполне удалась исследователям, хотя пока неизвестно — применяют ли её фишеры или для них это слишком сложно…
Если говорить про доверенные центры сертификации из локального хранилища сертификатов ОС, то никто из них не выпустит вам сертификата, позволяющего подписывать другие сертификаты. Даже если он и будет, то он также должен храниться в локальном хранилище сертификатов ОС.
Я пока не совсем понял, что удалось исследователям, но насколько понял из прочтенного, то все это про коллизию MD5. А с ней описанный вами сценарий реализовать не получится.
Я пока не совсем понял, что удалось исследователям, но насколько понял из прочтенного, то все это про коллизию MD5. А с ней описанный вами сценарий реализовать не получится.
Да, кстати, посмотрите, как устроен сертификат, ну например, здесь: https://bankline.ru/
Помимо MD5 хеша имеется и SHA хеш.
Поймите, что очень часто хакерские атаки бывают синтетическими. Про коллизию MD5 знали очень давно, поэтому и стали вставлять хеш SHA. А эта хакерская атака может скомпрометировать 0,01% от существующих сертификатов. Это моё личное мнение, основанное на том, чему меня когда-то учили.
Помимо MD5 хеша имеется и SHA хеш.
Поймите, что очень часто хакерские атаки бывают синтетическими. Про коллизию MD5 знали очень давно, поэтому и стали вставлять хеш SHA. А эта хакерская атака может скомпрометировать 0,01% от существующих сертификатов. Это моё личное мнение, основанное на том, чему меня когда-то учили.
Посмотрите более детальное описание. Там достаточно интересно. Для MD5 нашли способ формирования коллизии с заданным префиксом сообщения. Т.о. формируются дополнительные данные в комментарии и вуаля.
Там атака на ЭЦП, а не на целостность сертификата если что
А ЭЦП разве не сертификат подписывает??
Сертификат конечно :)
Грубо говоря: ЭЦП связывает некое юридическое лицо и какие то данные. + Контроль целостности. В нашем случае сертификат целостен (не поврежден). Но выпущен другим лицом.
Грубо говоря: ЭЦП связывает некое юридическое лицо и какие то данные. + Контроль целостности. В нашем случае сертификат целостен (не поврежден). Но выпущен другим лицом.
Да, но коллизии позволяют выпустить два сертификата. Один — безобидный, который спокойно подписывается у регистратора, а второй — уже сертификат не для сайта, а сразу для CA (шоб не мелочиться, ага) и на другое лицо (ну это уже опционально).
Сертификат не подписывается регистратором, а выпускается им. На его совести выпустить один или десяток.
Вы идиот или притворяетесь? Регистратор не может создавать сертификат. Иначе он имел бы доступ к соответствующему приватному ключу и мог бы выступать от имени крупных фирм, банков и т.д. Регистратор выступает в роли нотариуса: он заверяет подлинность чужого сертификата. Этот сертификат генерируется по определённым правилам, но его ни при каких условиях не генерирует регистратор.
Видимо, человек просто никогда сам CSR не генерировал, а пользовался веб-интерфейсом когда CSR генерируется на сервере и пользователю отдаётся приватный ключ. Такой интерфейс есть на некоторых CA.
Это дополнительная услуга для случаев когда вы готовы довериться регистратору целиком и полностью. Но вы себе представляете ситуацию при которой регистратору (пусть даже крупному — скажем Verysign, стоит где-то 4 миллиарда долларов) принадлежат ключи сотен фирм, каждая из которых — от ста миллиардов долларов и больше? Я — нет.
Нет, зато я представляю, когда апплет интернет-банка не подписан и передаётся по http, вместо https, о чём я в саппорт еще два года назад писал.
Когда я снова открыл счёт в этом же банке — ситуация не изменилась и я уж думал написать статью на хабрахабр по поводу реальной реализации MITM-атаки, но через два дня после выдачи мне цифрового сертификата вышла новая версия банк-клиента и она уже подписью обзавелась (хотя и отдаётся по-прежнему по http). Вот и думаю — совпадение это или всё-таки служба безопасности не совсем зря хлеб ест. :-)
Банк, кстати, в числе 20 крупнейших банков России.
Когда я снова открыл счёт в этом же банке — ситуация не изменилась и я уж думал написать статью на хабрахабр по поводу реальной реализации MITM-атаки, но через два дня после выдачи мне цифрового сертификата вышла новая версия банк-клиента и она уже подписью обзавелась (хотя и отдаётся по-прежнему по http). Вот и думаю — совпадение это или всё-таки служба безопасности не совсем зря хлеб ест. :-)
Банк, кстати, в числе 20 крупнейших банков России.
Ну это всё-таки прокол меньшего порядка. Что касается http/https: если апплет подписан, то использование https безупасность уже не улучшит, но вот то, что апплет выдавался без подписи — это таки явный прокол.
Это всё пережитки прошлого: я как-то работал по контракту с одной «суръёзной конторой», в которой для доступа к серверу нужно было пройти аж два металлоискателя и предъявить бумагу с разрешением на обоих — но сертификат для всей системы я генерировал в итоге сам на своём личном компьютере ибо у них просто не оказалось специалистов способных это проделать! На металлоискатели и вооружённую охрану деньги нашлись, а на грамотного сисадмина — нет…
Это всё пережитки прошлого: я как-то работал по контракту с одной «суръёзной конторой», в которой для доступа к серверу нужно было пройти аж два металлоискателя и предъявить бумагу с разрешением на обоих — но сертификат для всей системы я генерировал в итоге сам на своём личном компьютере ибо у них просто не оказалось специалистов способных это проделать! На металлоискатели и вооружённую охрану деньги нашлись, а на грамотного сисадмина — нет…
Я не уверен, что не улучшит, т.к. я не знаю политику браузера и javaws по-умолчанию по отношению к неподписанным аплетам.
Вопрос из-за того, что MITM по прежнему же может подменить апплет на неподписанный или на подписанный своей подписью (опять вопрос — проверяется ли браузером/javaws источник апплета).
Вопрос из-за того, что MITM по прежнему же может подменить апплет на неподписанный или на подписанный своей подписью (опять вопрос — проверяется ли браузером/javaws источник апплета).
Да, верно.
Вылетело из головы по CSR.
Признаю ошибку.
Вылетело из головы по CSR.
Признаю ошибку.
>>Вы идиот или притворяетесь?
Че, нервы ни к черту?
У меня почта подписывается сертификатом от Thawte. Я этот сертификат выпустил себе через веб-интерфейс. Дальше додумай сам.
Когда я 3 месяца назад поднимал на работе CA-сервер и хотел, чтобы мне его кто-нибудь подписал, оказалось, что никто так не делает. Как минимум, у нас в России.
После вашего последнего коммента хочется порекомендовать вам форум журнала хакер. Там много «компетентной» молодежи, подстать вам.
Че, нервы ни к черту?
У меня почта подписывается сертификатом от Thawte. Я этот сертификат выпустил себе через веб-интерфейс. Дальше додумай сам.
Когда я 3 месяца назад поднимал на работе CA-сервер и хотел, чтобы мне его кто-нибудь подписал, оказалось, что никто так не делает. Как минимум, у нас в России.
После вашего последнего коммента хочется порекомендовать вам форум журнала хакер. Там много «компетентной» молодежи, подстать вам.
>>Вы идиот или притворяетесь?Да нет — просто было интересно. Теперь ясно — не притворяетесь.
Че, нервы ни к черту?
У меня почта подписывается сертификатом от Thawte. Я этот сертификат выпустил себе через веб-интерфейс. Дальше додумай сам.Додумал. Я был таки прав: таких «баобабов» в службе ИТ-безопасности не нужно. Ты фактически дал право Thawte выступать от твоего имени. Для частной переписки обычного человека — это нормальный подход, но если речь идёт о фирме хотя бы среднего размера — это жуткий прокол.
Когда я 3 месяца назад поднимал на работе CA-сервер и хотел, чтобы мне его кто-нибудь подписал, оказалось, что никто так не делает. Как минимум, у нас в России.И за границей не делает. Зачем им плодить конкурентов? Но техническая возможность — имеется. И MD-5 коллизии позволяют такой CA-сервер сделать легальным.
После вашего последнего коммента хочется порекомендовать вам форум журнала хакер. Там много «компетентной» молодежи, подстать вам.Ну о компетентности этой молодёжи можно долго спорить, но то, что там люди более вменяемые, чем вы — однозначно.
Я этот сертификат выпустил себе через веб-интерфейс.
Не думаю, что генерация приватного ключа сертификата была сделана на javascript, следовательно, потенциально существует возможность, что ваш ключ утёк.
Вполне естественно, что сертификат CA вам никто не подписал, т.к. по сути вы получили бы ту же самую возможность представляться любым именем, которая описана в атаке (см. ссылку про rogue CA).
Там наверное даже не java. В браузерах есть встроенные модули шифрования, поэтому сами модули генерируют CSR-запрос, после чего на него генерится сертификат.
Может быть, но я не уверен.
Причина моей неуверенности в том, что в webmoney, где используется авторизация по сертификатам, возможность браузером генерировать сертификат не используется.
Да и вообще в firefox я не нашел кнопочки «создать сертификат» — у вас пруфлинка нет к своим словам?
Да, и, кстати, java != javascript :-)
Причина моей неуверенности в том, что в webmoney, где используется авторизация по сертификатам, возможность браузером генерировать сертификат не используется.
Да и вообще в firefox я не нашел кнопочки «создать сертификат» — у вас пруфлинка нет к своим словам?
Да, и, кстати, java != javascript :-)
Я думаю, что где-то вот здесь:
А кнопки на запрос сертификата нет наверняка потому, что для юзера это не надо, браузер сам его сможет сгенерить и отправить.
А кнопки на запрос сертификата нет наверняка потому, что для юзера это не надо, браузер сам его сможет сгенерить и отправить.
Ох не знаю, не знаю. По хорошему надо в бы RFC посмотреть, как происходит генерация сертификата в таких случаях и как у юзера, которому «не надо», спрашиваю CN и OU.
Более того — если такая возможность есть в браузере, зачем startcom описывал, как CSR сгенерировать с помощью openssl?
Что-то я не понял. А зачем вам понадобилось доверять генерацию секретного ключа сторонней организации?
Это примерно то же самое, что в мастерскую по копированию обычных ключей принести ключ, не оторвав бирку от квартиры с адресом с указанием, где именно деньги лежат. Не фатально, если ключник — честный, но никому не нужно.
Это примерно то же самое, что в мастерскую по копированию обычных ключей принести ключ, не оторвав бирку от квартиры с адресом с указанием, где именно деньги лежат. Не фатально, если ключник — честный, но никому не нужно.
Да уже вроде разобрались, что я ступил.
Секретный ключ генерится на моей стороне.
Секретный ключ генерится на моей стороне.
Вопрос к тем, кто приводил примеры ситуации, когда пара «закрытый/открытый ключ» генерируется на серверной стороне. Если можно, приведите примеры провайдеров криптоуслуг, которые делают это именно так?
Я себе процесс получения сертификата представляю следующим образом:
1) Вы заходите на сайт, представляющий услуги выдачи сертификатов
2) на ЛОКАЛЬНОЙ машине Вашим локальным криптопровайдером генерируется пара «закрытый/открытый ключ» (причем, этот процесс может происходить и в CPU крипто-токена, например, USB-брелока, которого закрытый ключ вообще никогда ни при каких условиях не покидает)
3) открытый ключ от только что созданной пары пересылается на сервер (защищает его от подделки в этот момент HTTPS);
4) сервер подписывает присланный открытый ключ своей ЭЦП, создавая собственно СЕРТИФИКАТ ключа подписи;
5) сервер отсылает сертификат Вам (и если хочет, то может положить его в свое хранилище для кэширования)
Закрытый ключ Ваш компьютер не покидал !!!
Я себе процесс получения сертификата представляю следующим образом:
1) Вы заходите на сайт, представляющий услуги выдачи сертификатов
2) на ЛОКАЛЬНОЙ машине Вашим локальным криптопровайдером генерируется пара «закрытый/открытый ключ» (причем, этот процесс может происходить и в CPU крипто-токена, например, USB-брелока, которого закрытый ключ вообще никогда ни при каких условиях не покидает)
3) открытый ключ от только что созданной пары пересылается на сервер (защищает его от подделки в этот момент HTTPS);
4) сервер подписывает присланный открытый ключ своей ЭЦП, создавая собственно СЕРТИФИКАТ ключа подписи;
5) сервер отсылает сертификат Вам (и если хочет, то может положить его в свое хранилище для кэширования)
Закрытый ключ Ваш компьютер не покидал !!!
Да, кстати, посмотрите, как устроен сертификат, ну например, здесь: https://bankline.ru/И что? Вот какой процент пользователей будет разбираться в том, как устроен сертификат если браузер нарисует замочек и скажет что всё в порядке — сертификат авторизован для сайта фишера?
Помимо MD5 хеша имеется и SHA хеш.
Опять-таки они могут и SHA-1 подпись для сертификата сделать, а уж то, что этот сертификат подписан CA, который сам подтверждён уже только через MD-5 вам ни один браузер не покажет…
Если в службе ИТ-безопасности (ну, например) банка сидят баобабы, то, уверяю вас, это далеко не самое слабое звено в защите системы.
Любой вменяемый и технически грамотный, если ему есть, что терять в случае мошенничества.
Технически неграмотным людям пользоваться серьёзными техническими средствами противопоказано по определению — в любой области, от судоводства до самолётостроения.
Технически неграмотным людям пользоваться серьёзными техническими средствами противопоказано по определению — в любой области, от судоводства до самолётостроения.
Вы выдаёте желаемое за действительное. Поймите вы: перевод денег — это рутина, а лоцманов и конструкторов самолётов мало. Не нужно их ставить на одну доску.
Технически грамотный бухгалтер может среагировать на ярко-красное предпреждение, выданное браузером (и вызвать «ИТ-специалиста»), но если браузер показывает (зелёным цветом или ещё как-нибудь), что всё в порядке, то ни один из бухгалтеров никуда не полезет.
И это правильно: они занимаются своим делом, а задача админа — настроить всё так, чтобы не было проблем. В частности выкосить из списка сертификатов в браузере всех регистраторов, которые поддерживают MD5. Но и тут всё непросто: если выкосить всех таких регистраторов, а потом у начальника не заработает ICQ (или там mail.ru'шный агент), то можно и своим местом поплатиться…
Технически грамотный бухгалтер может среагировать на ярко-красное предпреждение, выданное браузером (и вызвать «ИТ-специалиста»), но если браузер показывает (зелёным цветом или ещё как-нибудь), что всё в порядке, то ни один из бухгалтеров никуда не полезет.
И это правильно: они занимаются своим делом, а задача админа — настроить всё так, чтобы не было проблем. В частности выкосить из списка сертификатов в браузере всех регистраторов, которые поддерживают MD5. Но и тут всё непросто: если выкосить всех таких регистраторов, а потом у начальника не заработает ICQ (или там mail.ru'шный агент), то можно и своим местом поплатиться…
Как вы считаете, а внятнвя должностная инструкция может решить эту проблему?
Скорее всего нет. Людей, которые будут её соблюдать вы где найдёте? Специальные курсы откроете и обяжете их пройти?
Во сколько это обойдётся? И окупятся ли эти затраты?
Все банки это прекрасно понимают и применяют более простые решения (вместо веб-клиента используется так называемый банк-клиент, который требует для своей работы ключевую дискету), но это годится только для организаций, а кроме них ведь есть ещё и частные лица…
Во сколько это обойдётся? И окупятся ли эти затраты?
Все банки это прекрасно понимают и применяют более простые решения (вместо веб-клиента используется так называемый банк-клиент, который требует для своей работы ключевую дискету), но это годится только для организаций, а кроме них ведь есть ещё и частные лица…
Это достаточно не простой процесс. Хотя тот факт, что для хэш функции можно соверщить атаку селективной подделки не в какие ворота не лезет. Впринципе такой сертификат можно достаточно просто уличить в подделке, но с формальной точки зрения он действителен
А вот это вот вам как -> www.win.tue.nl/hashclash/SoftIntCodeSign/?
Все очень просто.
Длина хеш-кода — 512 бит. Соответственно, пространство состояний — 2^512.
Разработчики этих двух чудо-программ имели возможность дописывать в хвост 832 Байта. Получается, что у них пространство состояний — 2^6656.
Думаю, очевидно, что простым перебором можно написать миллионы миллиардов программ, которые будут хешироваться одинаковым кодом.
Длина хеш-кода — 512 бит. Соответственно, пространство состояний — 2^512.
Разработчики этих двух чудо-программ имели возможность дописывать в хвост 832 Байта. Получается, что у них пространство состояний — 2^6656.
Думаю, очевидно, что простым перебором можно написать миллионы миллиардов программ, которые будут хешироваться одинаковым кодом.
Идея для стартапа-конкурса: участникам дается хеш. Необходимо сбрутфорсить или написать программу, которая даст этот самый хеш при хешировании. Побеждает самая интересная или полезная программа :)
Я к тому, что это уже совсем небезобидный пример с коллизиями MD5.
Поймите, что если я являюсь владельцем сертификата/приватного ключа/исходного_текста_для_хеша, то я, вообще говоря, могу сделать многое.
Таким образом они могли подобрать хеш вообще к любой программе. Но тем не менее, это — брутфорс, а не уязвимость алгоритма.
То, что когда MD5 был разработан (17 лет назад), можно было подбирать, например по 10 хешей в секунду, а сейчас — по 10 000 000 (возьмите CUDA — и вперед!), то это не означает, что MD5 будет жить вечно. Да и все мы в детстве баловались Rainbow-таблицами =))
Таким образом они могли подобрать хеш вообще к любой программе. Но тем не менее, это — брутфорс, а не уязвимость алгоритма.
То, что когда MD5 был разработан (17 лет назад), можно было подбирать, например по 10 хешей в секунду, а сейчас — по 10 000 000 (возьмите CUDA — и вперед!), то это не означает, что MD5 будет жить вечно. Да и все мы в детстве баловались Rainbow-таблицами =))
Таким образом они могли подобрать хеш вообще к любой программе. Но тем не менее, это — брутфорс, а не уязвимость алгоритма.Это таки уязвимость алгоритма. Относительно слабая, но уязвимость. Как раз в случае с веб-сайтами она критична.
Поймите, что если я являюсь владельцем сертификата/приватного ключа/исходного_текста_для_хеша, то я, вообще говоря, могу сделать многое.Нет. Это делает ЭЦП бессмысленной. Если вы можете генерить документы, соответствующие одной и той же ЭЦП, пачками — то что это за подпись такая? Что она заверяет?
>>Нет. Это делает ЭЦП бессмысленной. Если вы можете генерить документы, соответствующие одной и той же ЭЦП, пачками — то что это за подпись такая? Что она заверяет?
Да, верно, но я здесь говорил в том же контексте, что и в обсуждении про одинаковый хеш для двух программ.
Представьте, что у меня есть два документа, в которых есть маловажный текст, но суть представляет какая-то цифра. Один документ — нормальный, другой — подложный. Подложный хешированием нужно выдать за нормальный.
Имея закрытый ключ я могу изменять в обоих документах текст таким образом, что «подгоню» один документ к другому по хеш-коду, сохранив цифру.
Само собой, это тот же самый брутфорс, но имея приватный ключ, я могу сделать это гораздо быстрее!
Да, верно, но я здесь говорил в том же контексте, что и в обсуждении про одинаковый хеш для двух программ.
Представьте, что у меня есть два документа, в которых есть маловажный текст, но суть представляет какая-то цифра. Один документ — нормальный, другой — подложный. Подложный хешированием нужно выдать за нормальный.
Имея закрытый ключ я могу изменять в обоих документах текст таким образом, что «подгоню» один документ к другому по хеш-коду, сохранив цифру.
Само собой, это тот же самый брутфорс, но имея приватный ключ, я могу сделать это гораздо быстрее!
Вы говорите о хорошо известном парадоксе, я так понимаю? Да, его всегда нужно учитывать — потому в MD5 и используется 128бит в то время как в параллельном к нему DES'е использовалось только 56бит.
Но обсуждаемые атаки к брутфорсу не сводятся: перебрать даже «жалкие» 18 квинтиллионов ключей (вместо 340 ундециллионов как требуется для подбора) на персональном компьютере за секунду, в общем, не получится…
Но обсуждаемые атаки к брутфорсу не сводятся: перебрать даже «жалкие» 18 квинтиллионов ключей (вместо 340 ундециллионов как требуется для подбора) на персональном компьютере за секунду, в общем, не получится…
Все дело в том, что сертификат имеет чуть более сложную структуру, чем «Private text». И в часности в X.509 может быть комментарий.
Это относится к тому факту, что создать два текста с одинаковой хеш-суммой теперь возможно, ни о какой обратимости речи не идет. Именно это и реализовано. И автор успокаивает в статье, насчет подбора текста с такой же хеш суммой — нельзя, так что можно за /etc/shadow не переживать.
Надеюсь я верно понял: )
Автору спасибо, но пожелание выверять терминологию, сам страдаю подобным. И вот, как видите, не все поняли ваш текст правильно — попробуйте немного ясности привнести.
Надеюсь я верно понял: )
Автору спасибо, но пожелание выверять терминологию, сам страдаю подобным. И вот, как видите, не все поняли ваш текст правильно — попробуйте немного ясности привнести.
Прогресс в атаках функций хеширования был продемонстрирован на конференции Crypto2008. Австрийско-польской команде криптологов из Гразского технологического и Варшавского военного технологического университетов удалось успешно произвести атаку на российский криптографический стандарт ГОСТ Р 34.11-94. Стандарт, который был введен 1 января 1995 года, определяет алгоритм и процедуру вычисления хэш-функции для последовательности символов. До этого момента, ГОСТ Р 34.11-94 считался одним из самых защищенных криптографических стандартов. Также криптологи продемонстрировали первую практическую инверсионную атаку на сокращенные варианты алгоритма SHA-1, которая может использоваться для вычитания пароля из хеша.
Согласно отчету, криптологам удалось обнаружить неожиданную техническую уязвимость и использоваться ее для проведения коллизионной атаки в 2^23 раза быстрее, чем считалось возможным.
© www.securitylab.ru/news/358391.php
Согласно отчету, криптологам удалось обнаружить неожиданную техническую уязвимость и использоваться ее для проведения коллизионной атаки в 2^23 раза быстрее, чем считалось возможным.
© www.securitylab.ru/news/358391.php
Ммм, статья во первых с весьма желтого ресурса, во вторых я так и не понял — 2^23 это на какой алгоритм? Далее — техническую? То есть аппаратную? Или я не понял: )
Я вот лично удалил sl.ru из подписок — бред очень часто, статьи некачественные.
Я вот лично удалил sl.ru из подписок — бред очень часто, статьи некачественные.
1. Набери в google «уязвимость в ГОСТ Р 34.11-94» выдаст множество результатов.
2. В статье дана ссылка на отчёт (https://online.tu-graz.ac.at/tug_online/voe_main2.getVollText?pDocumentNr=80200&pCurrPk=36649) там рассматривается криптоанализ функции хеширования ГОСТ.
2. Но это всё фигня, всё-равно защищённей чем MD5/SHA-1.
На wikipedia (http://ru.wikipedia.org/wiki/ГОСТ_Р_34.11-94) есть алгоритм хэширования, но он малось сложноват… Никто не встречал готовых реализованных классов для хеширования по этому алгоритму?
2. В статье дана ссылка на отчёт (https://online.tu-graz.ac.at/tug_online/voe_main2.getVollText?pDocumentNr=80200&pCurrPk=36649) там рассматривается криптоанализ функции хеширования ГОСТ.
2. Но это всё фигня, всё-равно защищённей чем MD5/SHA-1.
На wikipedia (http://ru.wikipedia.org/wiki/ГОСТ_Р_34.11-94) есть алгоритм хэширования, но он малось сложноват… Никто не встречал готовых реализованных классов для хеширования по этому алгоритму?
Вот это и дает 2^105 — смотрите:
разрядность ГОСТ Р 34.11 — 256 бит,
по парадоксу дней рождения придостаточном объеме дискового пространства
достаточно 2^(256/2) т.е. 2^128 операций для поиска коллизии,
раз австрийцы улучшили на 2^23 получается 2^(128-23)=2^105,
об этой атаке и упоминается в заметке.
Это нереализуемо на практике и имеет смысл пока только в теории
разрядность ГОСТ Р 34.11 — 256 бит,
по парадоксу дней рождения придостаточном объеме дискового пространства
достаточно 2^(256/2) т.е. 2^128 операций для поиска коллизии,
раз австрийцы улучшили на 2^23 получается 2^(128-23)=2^105,
об этой атаке и упоминается в заметке.
Это нереализуемо на практике и имеет смысл пока только в теории
Вы отстали от жизни лет на 60 :D
Представьте себе, какой вас будет ждать сюрприз при утечке информации о вашем алгоритме )
Представьте себе, какой вас будет ждать сюрприз при утечке информации о вашем алгоритме )
Можно придумать алгоритм, основанный на некоторых неизвестных возможному взломщику параметрах сервера) Или просто каком-то стартовом конфиге.
Даже получив исходники алгоритма, эти параметры не узнать, разве что только каким-либо брутфорсом, но эта проблема впонле решаема :)
Даже получив исходники алгоритма, эти параметры не узнать, разве что только каким-либо брутфорсом, но эта проблема впонле решаема :)
Рациональное зерно есть.
Конечно, надеяться на неизвестность алгоритма не приходится, но если это будет твой собственный алгоритм (который, кстати, не так уж сложно «разработать» и успешно применять) — то хакеру придется ломать твой собственный алгоритм. А это не то же самое, что «скачать ломалку для MD5» — тут подумать надо и куча любителей поломать отсеятся уже на этом этапе. Ну еще плюс надо поковыряться в программе и вытащить алгоритм — не думаю, что вы его его тоже пихнёте в открытом виде. А можно и в открытом — проектируя что-то криптографическое надо всегда рассчитывать на то, что алгоритм станет известен. Другое дело — вы его не обязаны раскрывать, а тот кто раскроет — не обязан делиться с окружающими… Это тоже даст задержку.
То есть тупо использование чего-то своего может существенно усложнить (а может и упростить, если не подумать. но это вряд ли.) количество телодвижений -> стоимость взлома вашей системы.
P.S. насчет разработать в кавычках — практически везде сейчас используются одни и те же операции: подстановки, сложение по модулю и т.д. Комбинируя их в циклы вполне можно получить достаточно нормальный алгоритм как шифрования так и подписи.
Конечно, надеяться на неизвестность алгоритма не приходится, но если это будет твой собственный алгоритм (который, кстати, не так уж сложно «разработать» и успешно применять) — то хакеру придется ломать твой собственный алгоритм. А это не то же самое, что «скачать ломалку для MD5» — тут подумать надо и куча любителей поломать отсеятся уже на этом этапе. Ну еще плюс надо поковыряться в программе и вытащить алгоритм — не думаю, что вы его его тоже пихнёте в открытом виде. А можно и в открытом — проектируя что-то криптографическое надо всегда рассчитывать на то, что алгоритм станет известен. Другое дело — вы его не обязаны раскрывать, а тот кто раскроет — не обязан делиться с окружающими… Это тоже даст задержку.
То есть тупо использование чего-то своего может существенно усложнить (а может и упростить, если не подумать. но это вряд ли.) количество телодвижений -> стоимость взлома вашей системы.
P.S. насчет разработать в кавычках — практически везде сейчас используются одни и те же операции: подстановки, сложение по модулю и т.д. Комбинируя их в циклы вполне можно получить достаточно нормальный алгоритм как шифрования так и подписи.
Комбинируя их в циклы вполне можно получить достаточно нормальный алгоритм как шифрования так и подписи
… но почему-то даже у профессиональных криптографов это получается не всегда.
У них задача посложнее: алгоритм должен быть как можно более прост в реализации + этот алгоритм точно будет известен всем задолго до его использования. Поэтому они и проверяют все, до чего могут дотянуться.
Вот уж не уверен, что ВСЕГДА стоит задача простой реализации.
Тем более сложение и подстановки — это инструмент блочных шифров и хэшей (они, кстати, несколько родственны — может быть напишу на эту тему пост), а вот для ассиметричной криптографии уже в ход идут «сложные задачи», а подписи без использования ассиметричной криптографии по-моему не мыслимы.
Тем более сложение и подстановки — это инструмент блочных шифров и хэшей (они, кстати, несколько родственны — может быть напишу на эту тему пост), а вот для ассиметричной криптографии уже в ход идут «сложные задачи», а подписи без использования ассиметричной криптографии по-моему не мыслимы.
P.P.S. И конечно же я не имел в виду случаи, когда надо обязательно пользоваться сертифицированным алгоритмами. Тут за вас всё придумали и у вас нет выбора, кроме как следовать инструкциям.
> а не зная алгоритма декодировать куда сложнее чем с исходниками на руках
Согласно принципу Керкхофса (и в дальнейшем максиме Шеннона), система имеет право считаться стойкой только если её стойкость сохраняется при полном разглашении информации о её устройстве.
Согласно принципу Керкхофса (и в дальнейшем максиме Шеннона), система имеет право считаться стойкой только если её стойкость сохраняется при полном разглашении информации о её устройстве.
md5 можно довольно быстро отбрутить радужными таблицами :) это не взлом — просто быстрый брут…
может кому то будет интересно
может кому то будет интересно
Да, совершенно верно, я умышленно не упоминал о Rainbow tables, чтобы не перегружать материал.
Именно из-за их существования все переходят на обязательное использование «соли» (salt) при хешировании паролей — в этом случае радужные таблицы станвоятся бесполезными.
Именно из-за их существования все переходят на обязательное использование «соли» (salt) при хешировании паролей — в этом случае радужные таблицы станвоятся бесполезными.
Радужные таблицы обычно используются для атак на паролевые схемы. А для таких схем надо руководствоваться хотя бы PKCS #5. В общем и целом — не суть актуально :] Впрочем, для всяких www-самоделкиных это может быть актуальным )
Интересно. :)
Да-да, коллизии в MD5 это сущая мелочь — см. phreedom.org/research/rogue-ca/
Компьютеры становятся мощнее, алгоритмы запутаннее и так по кругу. пора переходить на квантовую криптографию!!!
а чем не подходит к примеру вариант типа
md5(str + md5(str)) в данном случае для обратной операции потребуется определить правильную последовательность, в случае использования тех же rainbow таблиц, для конечного хэша будет найдена не исходная последовательность. И соответственно str не получится определить.
md5(str + md5(str)) в данном случае для обратной операции потребуется определить правильную последовательность, в случае использования тех же rainbow таблиц, для конечного хэша будет найдена не исходная последовательность. И соответственно str не получится определить.
Поздравляю! Вам начинают приходить в голову те же идеи, что и серъёзным криптографам! В частности MD5 был получен из MD4 примерно по описанному вами алгоритму. Как выяснилось — это улучшило его криптостойкость, но не слишком существенно.
А почему вы уверены, что md5(md5(str)) более криптостойко, чем md5?
По сути, вы предлагаете то же самое — изобрести свой доморощенный алгоритм.
По сути, вы предлагаете то же самое — изобрести свой доморощенный алгоритм.
А почему вы уверены, что md5(md5(str)) более криптостойко, чем md5?Априори это неизвестно, но в принципе все алгоритмы шифрования и криптохеширования включают в себя много раундов. Хотя это помогает далеко не от всех видов аттак, конечно.
По сути, вы предлагаете то же самое — изобрести свой доморощенный алгоритм.Угу. Это улучшит защиту, но неясно — насколько. А если мы уже меняем алгоритм — то не проще ли взять что-то проверенное?SHA-2, к примеру…
Вот и я про то же — кажется оно более стойким, а что делается по факту понять сложно. Я люблю в таком случае приводить вот такой пример:
По-моему существует ровно одно оправдание подходу md5(md5(crc32(str))) и то весьма сомнительное — когда в библиотеке нет реализации других хэшей…
Но, судя по тому, что sha-1 есть даже на javascript, таким оправданием воспользоваться не получится.
Возьмем так называемый совершенный шифр, т.е. XOR с длинной ключа равной длине сообщения. А теперь для «увеличения безопасности» зашифруем этим шифром текст ДВАЖДЫ! Естественно, что вместо ожидаемого улучшенного шифра на выходе двойного XOR-а мы получим просто изначальный текст.
А если мы уже меняем алгоритм — то не проще ли взять что-то проверенное?SHA-2, к примеру…
По-моему существует ровно одно оправдание подходу md5(md5(crc32(str))) и то весьма сомнительное — когда в библиотеке нет реализации других хэшей…
Но, судя по тому, что sha-1 есть даже на javascript, таким оправданием воспользоваться не получится.
На самом деле существует ещё и другое оправдание: когда вы хотите ограничить злоумышленнику возможности перебора. То есть вы делаете что-нибудь типа:
m=sha2(password+salt)
m1=sha2(m+salt)
…
m1000000=sha2(m999999+salt)
Ну и в /etc/passwd записывается m1000000. Но это защита не от слабости криптохеша, а от брутфорса на пароли и от использования «радужных таблиц»…
m=sha2(password+salt)
m1=sha2(m+salt)
…
m1000000=sha2(m999999+salt)
Ну и в /etc/passwd записывается m1000000. Но это защита не от слабости криптохеша, а от брутфорса на пароли и от использования «радужных таблиц»…
Кстати я не уверен что прибавление «соли» на каждом шаге даёт дополнительную защиту — но и проблем вроде не создаёт…
Да, я конечно же не имел ввиду добавление соли, добавление соли это дополнительные входные данные.
Посмотрел на один из своих веб-проектов N-летней давности — там подобная схема и была реализована:
m= hash(salt + password)
mi = hash(mi-1 + password)
stored = salt + m16
Теперь сижу, пытаюсь понять, лучше ли m15random-ной соли :-)
Посмотрел на один из своих веб-проектов N-летней давности — там подобная схема и была реализована:
m= hash(salt + password)
mi = hash(mi-1 + password)
stored = salt + m16
Теперь сижу, пытаюсь понять, лучше ли m15random-ной соли :-)
Подход, примененный в WinRAR.
Среднее время на проверку 1 пароля — примерно 0.1 секунды.
Очень удачное на мой взгляд решение.
Среднее время на проверку 1 пароля — примерно 0.1 секунды.
Очень удачное на мой взгляд решение.
Пример про XOR понравился)) Предлагаю лучше сделать 256 раундов, для более высокой надежности.
А вообще, конечно хеш-алгоритмы надо менять со временем, а то кто знает, что обнаружат завтра.
А вообще, конечно хеш-алгоритмы надо менять со временем, а то кто знает, что обнаружат завтра.
зашифруем этим шифром текст ДВАЖДЫ!Конечно зашифруйте, но с другим ключом.
Ну это удвоение бесконечной длины ключа — так каждый сможет, а вот чтоб сам алгоритм абсолютно стойкого шифра «улучшить» — это совсем другое дело!
;-)
;-)
Понравилась идея про использование сразу двух алгоритмов. Скорее всего не ново, но довольно элегантно и просто.
И это на практике часто используется. Но тут надо быть осторожным: такая защита не увеличивает стойкость по сравнению с одним алгортмом, но позволяет гарантировать что вы получите стойкость самого надёжного из них. А это — тоже немало…
Для быстрого создания коллизии он должен иметь возможность в процессе подбора менять и первый документ и второй. Если первый документ менять нельзя, то процесс затянется очень надолго (вне доступных пределов).
Почитайте на досуге. Есть два способа взломать хеш-функцию. Пока что все «сломанные» хеш-функции сломаны «условно». Этого достаточно чтобы натворить разных бед с сертификатами, но вот подменить файл с помощью этих атак нельзя.
А почему вдруг из первого предложения должно следовать второе? У вас расстройство психики и вы больше одной фразы в голове держать неспособны? Полная цитата выглядит так:
Что мы имеем «в сухом остатке»?Первое предложение раздела «Чем это грозит ?» следует из первого предложения раздела «Что мы имеем «в сухом остатке»?», второе предложение раздела «Чем это грозит ?» следует из второго предложения раздела «Что мы имеем «в сухом остатке»?». Куда уж внятнее… Всё-таки статья писалась не для младшей группы детского сада…
Криптоалгоритмы MD4, MD5, SHA-1, RIPEMD, HAVAL однозначно скомпрометированы в отношении атак генерации коллизий. Однако (!) к счастью, ни одной физически реализуемой атаки на обращение хеш-функций (даже для MD4) на сегодняшний день не опубликовано.
Чем это грозит ?
Злоумышленник имеет возможность создать два разных документа, у которых будет одинаковое хеш-значение (при этом он не имеет возможности «контролировать» какое именно значение получится). Это означает, что создать «двойника» к уже существующему чужому документу/тексту/файлу он не может. Контролирует ситуацию он только в том случае, когда может конструировать и первый и второй документы сам.
Спасибо очень интересно и познавательно для новичков ;)
>> ни одной физически реализуемой атаки на обращение хеш-функций (даже для MD4) на сегодняшний день не опубликовано.
www.win.tue.nl/hashclash/rogue-ca/
www.win.tue.nl/hashclash/rogue-ca/
А кто мешает сделать вот так md5(md5(md5($string)))? :-)
Это экстенсивный путь. Да, на первое время он будет наверное достаточно стойким.
Но обычно, когда обнаружена структурная (идеологическая) ошибка в криптоалгоритме,
стараются изменить именно идеологию его построения (комбинирования
математических выражений, входящих в него).
На самом деле, как только завершится SHA-3 и победитель будет назван,
его ждет такой же успех как AES на сегодняшний день.
Ждать нового алгоритма осталось недолго. Вот хорошая ссылка про конкурс:
ehash.iaik.tugraz.at/wiki/The_SHA-3_Zoo
Но обычно, когда обнаружена структурная (идеологическая) ошибка в криптоалгоритме,
стараются изменить именно идеологию его построения (комбинирования
математических выражений, входящих в него).
На самом деле, как только завершится SHA-3 и победитель будет назван,
его ждет такой же успех как AES на сегодняшний день.
Ждать нового алгоритма осталось недолго. Вот хорошая ссылка про конкурс:
ehash.iaik.tugraz.at/wiki/The_SHA-3_Zoo
В php >= 5.1.2 есть встроенная функция hash(algo, data), позволяющая получить хэш от data, используя алгоритм data. Список поддерживаемых алгоритмов можно получить через функцию hash_algos(). Вот что она возвращает в php 5.1.2:
Array
(
[0] => md4
[1] => md5
[2] => sha1
[3] => sha256
[4] => sha384
[5] => sha512
[6] => ripemd128
[7] => ripemd160
[8] => whirlpool
[9] => tiger128,3
[10] => tiger160,3
[11] => tiger192,3
[12] => tiger128,4
[13] => tiger160,4
[14] => tiger192,4
[15] => snefru
[16] => gost
[17] => adler32
[18] => crc32
[19] => crc32b
[20] => haval128,3
[21] => haval160,3
[22] => haval192,3
[23] => haval224,3
[24] => haval256,3
[25] => haval128,4
[26] => haval160,4
[27] => haval192,4
[28] => haval224,4
[29] => haval256,4
[30] => haval128,5
[31] => haval160,5
[32] => haval192,5
[33] => haval224,5
[34] => haval256,5
)
Вопрос: кто-нибудь в курсе, 16-й алгоритм — 'gost' — это и есть ГОСТ Р 34.11-94, или какой-то другой алгоритм?
Описание функций
Array
(
[0] => md4
[1] => md5
[2] => sha1
[3] => sha256
[4] => sha384
[5] => sha512
[6] => ripemd128
[7] => ripemd160
[8] => whirlpool
[9] => tiger128,3
[10] => tiger160,3
[11] => tiger192,3
[12] => tiger128,4
[13] => tiger160,4
[14] => tiger192,4
[15] => snefru
[16] => gost
[17] => adler32
[18] => crc32
[19] => crc32b
[20] => haval128,3
[21] => haval160,3
[22] => haval192,3
[23] => haval224,3
[24] => haval256,3
[25] => haval128,4
[26] => haval160,4
[27] => haval192,4
[28] => haval224,4
[29] => haval256,4
[30] => haval128,5
[31] => haval160,5
[32] => haval192,5
[33] => haval224,5
[34] => haval256,5
)
Вопрос: кто-нибудь в курсе, 16-й алгоритм — 'gost' — это и есть ГОСТ Р 34.11-94, или какой-то другой алгоритм?
Описание функций
Имелось в виду, используя алгоритм algo.
Да, это ГОСТ Р 34.11-94:
...
memcpy(u, state, sizeof(u));
memcpy(v, data, sizeof(v));
for (i = 0; i < 8; i += 2) {
X(w, u, v); \
P(key, w); \
R(key, h, i, t, l, r); \
S(s, l, r); \
if (i != 6) { \
A(u, l, r); \
if (i == 2) { \
C(u); \
} \
AA(v, l, r); \
}
}
SHIFT12(u, m, s);
SHIFT16(h, v, u);
SHIFT61(h, v);
...
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Взлом хеш-функций (2004-2006 гг.): как это было и что теперь делать?