Обсуждение:Криптографическая хеш-функция
Из Википедии, свободной энциклопедии
Перейти к навигации Перейти к поиску
Список дел для криптографической хеш-функции :редактировать  ·  история  ·  смотреть  ·  обновить  ·  Обновлено 2017-04-12

  • Терминология; множество альтернативных имен для криптографических свойств и функций, которые их содержат; различие между хэш-функциями с ключом и без ключа (здесь придерживайтесь неключевого);
  • Обсуждение « структуры Меркле-Дамгарда », за которой следуют MD4/5, SHA и т. д.; схема подойдет.
  • Хеш-функции, построенные из блочных шифров - Дэвиса-Мейера и т. Д. ( Прикладная криптография подробно описывает их)
  • Хэш-функции, используемые для построения других примитивов; например, блочные шифры из хеш-функций (например , SHACAL , BEAR и LION ), потоковые шифры ( SEAL ), MAC-адреса из хеш-функций ( HMAC ) и PRNG.
  • Обсудите рекомендуемые размеры для хеш-функций; количественно определить «жесткий», MD5CRK . Может быть, упомянуть парадокс дня рождения ?
  • Расскажите немного о конкретных популярных хеш-функциях.
  • Приведите пример коллизионной атаки Юваля при подписании хешированных сообщений.
  • История?
  • относительно этого утверждения в статье: «Поэтому Алиса записывает свое решение, добавляет случайный одноразовый номер, вычисляет его хэш и сообщает Бобу хеш-значение (при этом сохраняя решение в секрете)». Пожалуйста, уточните, дает ли Алиса Бобу одноразовый номер в дополнение к хешу.
  • Обсудите таблицы обратного поиска (например, http://md5.crysm.net/ )
  • (Нетехнический) По какой-то причине эта статья не печатается в формате pdf из Википедии. У меня нет проблем с печатью pdf с моего компьютера. Печать была опробована как в Firefox, так и в IE.

8 февраля 2007 года криптографическая хэш-функция была связана с Wired News , веб-сайтом с высокой посещаемостью. ( См. трафик посетителей )

Все предыдущие и последующие изменения статьи отмечаются в истории изменений .

В поле выбран термин Дайджест сообщения

Эта страница должна быть перенаправлена ​​на дайджест сообщений, который является устоявшимся термином искусства в этой области с 80-х годов. В первые дни не делалось различия между дайджестами сообщений и хеш-функциями. И тогда одно и то же имя использовалось для обоих. Затем кто-то подал глупый иск, утверждая, что использование дайджеста сообщения в качестве хэша нарушает их патент. Я подозреваю, что страница была перенаправлена ​​​​из Message Digest во время этого спора. — Предыдущий неподписанный комментарий добавлен пользователем 96.237.138.82 ( обсуждение ) 21:58, 7 января 2020 г. (UTC)


Смущенный????

То, как в этой статье описывается сопротивление второго прообраза и сопротивление столкновению, кажется, что это одно и то же. Я что-то упустил или это просто плохо объяснено ??? 98.213.119.182 ( разговор ) 09:04, 17 мая 2015 г. (UTC)

Объяснение разницы см. в разделе « Атака прообраза». — agr ( обсуждение ) 12:55, 17 мая 2015 г. (UTC)

Редакция статьи

Я согласен с тем, что отчет, представленный здесь в настоящее время, точен. Однако он довольно абстрактен и поэтому мало чем полезен для большого класса читателей. Поскольку эта тема является фундаментальной в современной криптографической практике, я предлагаю пересмотреть эту статью, включив в нее текст, дающий больше контекста. В частности, следует отметить проблемы с использованием такой функции. Дайджест сообщения статьи ошибается почти обратным образом. Возможно, комбинация двух с указателями перенаправления?

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

Я объединил их (хотя, я думаю, это нуждается в реорганизации). - Мэтт 22:18, 19 июля 2004 г. (UTC)

- Мэтт 01:14, 21 июля 2004 г. (UTC)

Крики! Эта статья нуждается в серьезном редактировании! Я тоже буду возвращаться время от времени, чтобы подправить его. Руптор 04:03, 21 февраля 2007 г. (UTC)
Эта статья серьезно нуждается в разделе, написанном с точки зрения непрофессионала. Вот это да. ▫ Шутки Urbane Legend 01:21 , 29 ноября 2008 г. (UTC)
Мне кажется, что головная часть ясна настолько, насколько это возможно. Если это не так, можете ли вы указать на трудные места?
Остальная часть статьи посвящена техническим деталям; Я не вижу, как быть правильным, не будучи техническим.
-- Хорхе Столфи ( разговор ) 21:58, 30 ноября 2008 г. (UTC)

Не стесняйтесь помещать эти наблюдения в список дел по своему желанию. В статье нужно обсудить хотя бы качественно, что подразумевается под "жестким" в разделе свойств. Примеры или просто порядок вычислений были бы в порядке. Также необходима ссылка и/или краткий обзор того, что означает вычислительная неосуществимость. Также, конечно, краткое изложение различных CHF и их особенностей/сходств. - Налоговый инспектор 20:23, 29 июля 2004 г. (UTC)

Онлайн ссылки для редактирования

  • глава ВАК
  • Черновая энциклопедия. статья
  • Часто задаваемые вопросы о RSA: [1]
  • Удаленное снятие отпечатков физических устройств

[2] [3] [4]


'

Я чувствую, что вступление слишком длинное (т.е. заголовок раздела должен быть вставлен после первого абзаца), но я не могу придумать ничего подходящего. Арвиндн 07:33, 30 июля 2004 (UTC)

Я бы сказал, что пример решения головоломки больше связан с обязательствами, чем с отметками времени. Лунквилл 00:27, 5 августа 2004 г. (UTC)

На «совершенно другом» — это требование хеш-функций, это Strong Avalanche Criterion.

На "нет информации о" - злоумышленник может тривиально определить одну часть информации о M из H(M), а именно значение H(M). Я понимаю дух того, что вы пытаетесь донести, но никто никогда не находил способа выразить это формально так, чтобы его можно было удовлетворить.

ciphergoth 11:24, 10 января 2005 г. (UTC)

«Известно, что некоторые из следующих алгоритмов небезопасны»

пожалуйста, обратите внимание на те, которые есть, и насколько они важны. - Омегатрон 16:44, 14 апреля 2005 г. (UTC)
В другом месте статьи обсуждается безопасность, но здесь я бы посоветовал просто убрать это предупреждение. Тот факт, что мы перечисляем схему хэш-функции, не означает, что она каким-то образом одобрена (так же, как статья о «списке тюрем» не содержала бы оговорки о том, что «некоторые из следующих тюрем, как известно, имели побеги заключенных»). — Мэтт Крипто , 19:10, 14 апреля 2005 г. (UTC)
Почему нет? Это информация, которую я искал в этом случае. В некоторых статьях есть что-то вроде «эта версия больше не считается безопасной» в первом абзаце описания. - Омегатрон 19:18, 14 апреля 2005 г. (UTC)
Список того, насколько небезопасны алгоритмы, полезен при выборе того, какой из них применить для конкретной цели. Список тюрем, однако, не был бы столь полезен в этом смысле, поскольку местонахождение тюрьмы может иметь большее значение, чем безопасность: маловероятно, что заключенный, отправленный на Луну, сбежит, однако поместив заключенного туда в первое место невозможно. -- Ihope127 19:05, 10 августа 2005 г. (UTC)

и злоумышленник не должен узнать ничего полезного о сообщении, учитывая только его дайджест, кроме самого дайджеста.

Два редактора (один аноним) утверждали, что последние четыре слова должны быть удалены. Я действительно против этого; на мой взгляд, это жизненно важное предостережение. Без этой оговорки мы могли бы точно определить, что означает для злоумышленника ничего не узнать о сообщении. Как бы то ни было, они определенно узнают по крайней мере одну вещь: дайджест сообщения равен x. Этот, казалось бы, тривиальный факт полностью сводит на нет любые попытки прийти к более точному определению того, что значит для злоумышленника ничего не узнать о сообщении. Это абсолютно жизненно важная разница.

Я не буду возвращать его в третий раз, если он снова будет удален, но я бы очень хотел сначала обсудить это здесь, если это возможно. Спасибо. - ciphergoth 08:30, 24 октября 2005 г. (UTC)

Я согласен с вашим возвратом и правками ciphergoth. Это жизненно важная разница, поскольку в некоторых случаях знание самого дайджеста может иметь значение. (Я профессионально занимался разработкой криптопротокола и преподавал его в университетах.) — Дэвид Гётберг , 11:13, 24 октября 2005 г. (UTC)

Сопротивление прообразу

Согласно статье MD5, это не сопротивление столкновению, поэтому таблицу следует изменить. Есть ли у них возражения против этого? Ламбедан ( разговор ) 23:16, 2 апреля 2009 г. (UTC)

Записи в таблице в порядке. MD5 не устойчив к коллизиям, но до сих пор не опубликовано ни одной атаки на сопротивление прообразам. Однако названия столбцов неоднозначны. Столбец «Сопротивление столкновению» на самом деле означает «Есть ли известные атаки на сопротивление столкновению?». Столбец «Сопротивление прообразу» означает в равной степени «Есть ли какие-либо известные атаки на сопротивление прообразу?». Возможно, стоит сделать названия более понятными. 81.62.21.174 ( разговор ) 07:43, 3 апреля 2009 г. (UTC)
Запись для MD2 имеет пробел в столбце прообраза, хотя в статье MD2 описывается атака прообразом? Если бы я знал больше о криптографии, у меня возникло бы желание исправить это самому; может ли эксперт проверить это , пожалуйста ?

Сопротивление прообразу

Пользователь: C4chandu удалил обсуждение устойчивости к прообразу из заявления о том, что должна делать хеш-функция. Почему? Во всяком случае, мы должны расширить этот раздел, чтобы добавить сопротивление второму прообразу. - ciphergoth 08:30, 24 октября 2005 г. (UTC)

CRC

CRC используются не только из-за скорости и удобства. У них есть свойство, заключающееся в том, что любая ошибка менее определенного количества битов или менее определенной части сообщения гарантированно изменит CRC. В таких обстоятельствах псевдослучайная функция может случайно дать то же самое значение.

Я не уверен, насколько важно это преимущество (больше, если контрольная сумма короткая), но, насколько я понимаю, они всегда продавались именно так. - ciphergoth 15:04, 7 февраля 2006 г. (UTC)

Ну, прежде всего, если мы должны упомянуть, почему CRC используются в сетевых протоколах вместо криптографических хэшей, то мы должны сначала упомянуть основные причины: CRC проще реализовать и намного быстрее, чем криптографические хеш-суммы. В этом я уверен и не вернусь, если добавлю в статью. Может быть, мы должны добавить это?
И да, я думаю, что CRC в какой-то степени должны гарантировать, что короткие пакеты поврежденных битов (короче, чем длина вывода CRC) не должны вызывать такой же CRC. Но хеши, как вы указываете, носят более случайный характер и, следовательно, в этом случае могут вызывать один и тот же хеш. Но я не уверен, что это правда, поэтому я бы не стал добавлять это в статью. И я также думаю, что может быть слишком много подробностей о CRC.
В-третьих: Да, в CRC могут быть некоторые свойства, делающие их более подходящими для попытки выяснить, какие биты были повреждены, и попытаться их восстановить. Поскольку CRC более предсказуемы. Или просто они быстрее, и поэтому быстрее попробовать разные исправления и посмотреть, какое из них соответствует CRC. Я не знаю, что правда, и вы, кажется, тоже не уверены. И я думаю, что это также самая необычная причина для использования CRC. Так что я не думаю, что мы должны иметь это в статье.
-- Дэвид Гётберг 02:34, 8 февраля 2006 г. (UTC)
CRC нельзя напрямую использовать для исправления ошибок, потому что обычно существует много равновероятных исправлений, которые исправят CRC. Однако коды с исправлением ошибок обычно основаны на той же математике (т . е. на полях Галуа ): см., например , сверточные коды .
Я уверен в этом утверждении. Я также уверен, что с CRC можно утверждать целые полезные классы ошибок, которые гарантированно вызовут изменение CRC, в то время как с n-битным криптографически стойким хешем (или MAC) любая ошибка имеет 2^-n шанс остаться незамеченным.
CRC не так быстры или просты в реализации. Что-то вроде Adler32 проще реализовать и намного быстрее, чем любой CRC. CRC используются, потому что есть математическая причина полагать, что они будут особенно хорошими кодами обнаружения ошибок в канале, который вносит очень мало однобитовых ошибок. Я тоже в этом уверен.
FTR, я не выступаю за использование CRC — я хотел бы, чтобы на большинстве каналов использовались настоящие MAC. Обратите внимание, что CRC32 занимает 4,8 цикла/байт; Poly1305 работает со скоростью 3,8 цикла/байт; Adler32 1,3 цикла/байт. - ciphergoth 09:53, 8 февраля 2006 г. (UTC)
Я не могу комментировать Adler32, но CRC намного проще и быстрее, чем криптографическая хэш-функция, и ее намного проще реализовать на оборудовании. Также гораздо более вероятно, что ошибка проскользнет, ​​чем криптографический хеш, для разумных размеров каждого (32 бита для CRC, 128-256 для хэша). Существуют стандартные способы создания ошибок, которые будут проходить CRC; Найдите /любую/ ошибку, которая проходит HMAC, и вы сразу же станете знаменитым. Вы, конечно, не найдете его путем случайного угадывания; 2^-128 слишком велико для большого числа . Вот тесты CRC-32 и SHA-1 для файла размером 100 МБ на моей машине:
[jason@erg] ~/tmp$ cfv -t crc -C foo
tmp.crc: 1 файл, 1 ОК. 0,427 секунды, 228625,5 тыс./с
[jason@erg] ~/tmp$ cfv -t sha1 -C foo
tmp.sha1: 1 файл, 1 ОК. 2,241 секунды, 43585,7 тыс./с
Что касается использования усеченных (скажем, 32-битных) криптографических хэшей в качестве замены CRC, я даже не собираюсь вдаваться в подробности, потому что это путает назначение как CRC, так и хеш-функций. Используйте хеш-функции, если вам нужна серьезная защита от сбоев и злоумышленников. Используйте CRC, если вам нужен дешевый способ просто избежать распространенных сбоев. Лунквилл 20:15, 8 февраля 2006 г. (UTC)
исторически использовались. Это все, что я хочу сказать.
О, и, учитывая ключ MAC, теперь не так уж сложно создать ошибку, которая проходит HMAC-MD5, и HMAC-SHA1 не за горами. Конечно, если у вас нет ключа, все обстоит иначе :-) — ciphergoth 22:27, 8 февраля 2006 г. (UTC)
CRC нельзя напрямую использовать для исправления ошибок ? В статье об исправлении ошибок заголовков подразумевается, что некоторые аппаратные средства банкоматов напрямую используют CRC для исправления однобитовых ошибок. Это то, что нужно исправить?
Но я согласен с вашим общим выводом:
CRC исторически использовались для обнаружения (естественных) ошибок, потому что они имеют более сильную гарантию обнаружения многих видов часто встречающихся ошибок, чем другие более быстрые и простые в реализации коды проверки, такие как Adler-32 и продольная проверка избыточности .
Однако теперь мы знаем другие методы обнаружения и исправления ошибок , которые лучше, чем CRC, для исправления естественных ошибок на каждом отдельном переходе между узлами связи.
MAC лучше, чем CRC, для обнаружения преднамеренной атаки (а также любых естественных ошибок, которые могли быть неправильно «исправлены») по сквозному принципу .
Таким образом, кажется, что в новых протоколах нет места для CRC. -- 68.0.124.33 ( разговор ) 18:08, 23 сентября 2008 г. (UTC)

Хеш-функции на основе блочных шифров

У меня есть небольшой дискомфорт с этим разделом, который я не знаю, как решить. Дело в том, что большинство современных хеш-функций (как минимум MDx, SHA-x, Tiger, Whirlpool) основаны на блочных шифрах либо в режиме Дэвиса-Мейера, либо в режиме Миягучи-Пренила; просто они используют специальные блочные шифры, разработанные для приложения, а не, скажем, AES. Я не знаю, как изменить артикль, чтобы выразить это. - ciphergoth 09:06, 6 марта 2006 г. (UTC)

Мы упоминаем этот факт в статье Меркле-Дамгарда: «Функция сжатия может быть либо специально разработана для хеширования, либо построена на основе блочного шифра. Во многих случаях, включая шифры SHA-1 и SHA-0, функция сжатия на основе блочного шифра, специально разработанного для использования в хэш-функции».
Но фраза «блочный шифр, специально разработанный для хэш-функции вместе с Миягучи-Пренилом» по крайней мере для меня означает примерно то же самое, что и «функция сжатия может быть специально разработана для хеширования» . (Конечно, с чуть меньшими подробностями.) А на самом деле, функция сжатия может быть либо специально разработана, либо существующим блочным шифром, либо вообще сделана из потокового шифра.
Лично я считаю, что здесь, в статье о хэшах, мы должны сделать это простым (как мы делаем сейчас), иначе она станет слишком длинной. Вместо этого мы должны оставить подробные детали для статьи Меркле-Дамгарда.
-- Дэвид Гётберг 10:45, 6 марта 2006 г. (UTC)

Джексум

27 марта я удалил около десятка ссылок из Википедии, таких как эта из WHIRLPOOL :

Джексум — дипл.-инф. (FH) Иоганн Н. Леффльманн на Яве . Различные функции проверки сообщений, включая все три версии WHIRLPOOL. Выпущено под лицензией GPL .

Jonelo  ( talk  · contribs ), автор Jacksum в большинстве случаев восстановил эти ссылки; увидеть его вклад. Мне было бы интересно узнать, что другие редакторы Википедии думают об этом споре. На его странице обсуждения есть обсуждение этого вопроса . Далее следуют мои собственные чувства.

  • Пропустите ссылки - я не думаю, что уместно заполнять Википедию ссылками на ваше программное обеспечение, даже если оно с открытым исходным кодом. - ciphergoth 19:47, 30 марта 2006 г. (UTC)
  • Единственное место, где мне было бы удобно разместить ссылку на это программное обеспечение, находится в списке криптографического программного обеспечения . Арвиндн 00:13, 31 марта 2006 г. (UTC)
  • Джонело не должен возвращать ссылки на свой сайт. Мы можем быть немного деспотичными, если это необходимо, потому что наша политика в отношении внешних ссылок очень ясна и гласит, что редакторы должны избегать добавления: « 3. Ссылки, которые добавляются для продвижения сайта » и « 9. Веб-сайт, который вы владеете или поддерживаете (если это не официальный сайт темы статьи). Если это актуально и информативно, упомяните его как возможную ссылку на странице обсуждения и подождите, пока кто-то другой не включит его, или включите информацию напрямую в статье "Далее говорится, что"ПРИМЕЧАНИЕ, относящееся к пунктам № 3 и № 9: из соображений нейтральности и точки зрения основная политика Википедии заключается в том, что никто с определенного сайта/организации не должен публиковать ссылки на эту организацию/сайт и т. д. Поскольку нейтральность важная — и трудная — цель Википедии, она имеет приоритет над другими политиками, определяющими, что должно быть связано. Принятая процедура заключается в размещении предложенных ссылок в разделе «Обсуждение» статьи, и пусть другие — нейтральные — редакторы Википедии решают, следует ли их включать. " — Мэтт Крипто , 06:52, 31 марта 2006 г. (UTC)
  • Как автор Jacksum, я хотел бы добавить несколько комментариев. Это правда, что я добавил ссылки на Jacksum в октябре 2004 года. См. также обсуждение на моей странице обсуждения.. Я также время от времени менял описание, чтобы сохранить правильность. Однако с 2004 года необходимость восстановления связи возникает всего дважды. См. также мои публикации. А также, судя по отзывам, которые я получил, пользователи сочли эти ссылки весьма полезными. Что ж, все ссылки Википедии на Jacksum на данный момент удалены, и я не собираюсь добавлять ссылки снова, потому что я действительно не хочу нарушать политику Википедии («редакторам следует избегать добавления веб-сайта, которым вы владеете или поддерживать"). Однако я думаю, что бесплатное и независимое от платформы программное обеспечение для контрольных сумм с открытым исходным кодом может помочь читателям Википедии. Поэтому я надеюсь, что есть хотя бы несколько пользователей Википедии, которые согласны со мной, так что ссылки на Jacksum можно будет снова восстановить. Ссылка на Джексумhttp://www.jonelo.de/java/jacksum . Возможно, имеет смысл немного сократить описание. Спасибо за поддержку. Джонело 19:13, 31 марта 2006 г. (UTC)
  • Лично я предпочитаю такие ссылки, если они полезны. Я не видел ссылки на «список криптографического программного обеспечения» нигде на странице и, следовательно, не нашел никакого программного обеспечения для Whirlpool. Тем не менее, поскольку люди публикуют программное обеспечение Whirlpool, я получаю информацию и приложения с одной страницы. Это одна из вещей, которые мне нравятся в Википедии: я получаю информацию, затем я получаю веб-сайты или приложения, которые применяют ее на практике. Я вижу веские причины регулировать эти вещи, но я думаю, что по крайней мере лучшее программное обеспечение должно быть на странице. Если кто-то не согласен, поместите ссылку на этот список программного обеспечения в статью Википедии по каждому криптографическому алгоритму или теме, чтобы случайный пользователь Википедии ничего не пропустил. Я рад, что Crypto++ был в статье AES, иначе я бы никогда не узнал, что он существует. неподписанный комментарий добавлен 76.107.167.109 ( обсуждение ) 05:56, 13 марта 2008 г. (UTC)

Эффективный размер?

Нам нужен столбец для эффективного размера, чтобы дать представление о качестве каждого алгоритма. Например, идеальный 128-битный хэш потребует 2^64 операций, чтобы найти коллизию. Поскольку, например, SHA-1 требует 2 ^ 63 операций, чтобы найти коллизию, его эффективный размер будет 126 бит. В противном случае читателю придется просматривать каждую статью одну за другой, чтобы получить представление о том, насколько криптографически взломан каждый алгоритм. -- Дамиан Йеррик ( ☎ ) 02:40, 3 июня 2006 г. (UTC)

Я думаю, что такое резюме было бы скорее вводящим в заблуждение, чем полезным. Мой опыт работы с eSTREAM показывает, что лучше всего обсуждать состояние безопасности на странице соответствующего примитива, где у вас есть место, чтобы сделать это должным образом. - ciphergoth 08:56, 3 июня 2006 г. (UTC)

Выявление свойств?

Разве хорошим свойством хэш-функции не была бы способность показать, учитывая строку X, что только строка такой же длины (или строка, которая является анаграммой этой или начинается с того же символа, что и эта). , или что-то в этом роде) может привести к получению хеша без раскрытия самой строки (например, раскрытие того, что хеш MD5 6cd3556deb0da54bca060b4c39479839 должен принадлежать строке длиной 13 символов)? -- Ihope127 00:57, 4 июля 2006 г. (UTC)

Являются ли методы хеширования теоретически жизнеспособными?

В статье нет основного теоретического обсуждения. Многие утверждают, что вообще невозможно спроектировать идеально бесконфликтный и односторонний метод хэширования, поэтому все алгоритмы хэширования бесполезны для обеспечения безопасности. Я думаю, что это связано с проблемой P <--> NP. 195.70.48.242 20:36, 5 декабря 2006 г. (UTC)

На самом деле, я бы сказал, что статья неплохо излагает теоретические основы. Если вы хотите больше, вы можете прочитать о случайных оракулах или перейти к Справочнику по прикладной криптографии. «Совершенно бесконфликтный» не имеет смысла по отношению к хэш-функциям (рассмотрите хэш со 128-битным выходом. Подайте ему все 256-битные строки, и каждая из них будет иметь в среднем 2 ^ 128 коллизий, даже если это настоящий случайный оракул .) P<->NP не имеет значения. И «бесполезный для использования в целях безопасности» также не имеет особого смысла — почти вся криптография основана на хорошо проверенных предположениях о том, что сложно, а что нет. Тем не менее, предстоит проделать большую работу по улучшению нашего определения и реализации криптографических хэшей. Лунквилл 19:46, 7 декабря 2006 г. (UTC)

NIST проводит несколько семинаров по криптографическим хэшам.

NIST проводит несколько семинаров по криптографическим хэшам . Было представлено несколько идей для новых хэш-функций; у трех есть веб-страницы и справочный код: LASH , RadioGatún и EDON-C/EDON-R (прокрутите вниз и найдите «Два бесконечных класса криптографических хеш-функций»). Самбой 05:29, 21 декабря 2006 (UTC)

Одностороннее шифрование

Многие люди в отрасли называют криптографические хэш-функции «односторонним шифрованием». Я добавил это, а также добавил ссылки на пару авторитетных книг, в которых говорится об этом. Мое дополнение было удалено. Это удаление было необоснованным. Тот факт, что они так называются, не является неправильным (очевидно, потому что я на это сослался). Представление о том, что это неправильное определение, является спорным и обоснованным. Человек, который удалил мою правку, должен добавить авторитетный источник, который определяет ее иначе, и заявить, что она оспаривается и/или спорна. Джавиджамаэ 04:33, 18 июня 2007 г. (UTC)

Я понимаю что ты имеешь ввиду. Однако существует некоторая значительная путаница в том, как используется этот термин. В некоторых случаях одностороннее шифрование относится к схеме шифрования, которая просто является односторонней, в отличие от более сильных понятий безопасности, таких как защита от атак с выбранным зашифрованным текстом. Насколько я вижу, наиболее часто "одностороннее шифрование" используется для применения односторонней функции к паролям. Криптографические хеш-функции часто (но не всегда) используются для этого процесса. Примером, когда не используется хеш-функция, является хранилище паролей на основе DES в UNIX (т.е. шифрование всего нулевого блока с паролем в качестве ключа). Эта функция достаточно односторонняя, но не устойчива к коллизиям и, следовательно, не является криптографической хеш-функцией. Отсюда то, что многие люди имеют в виду, когда говорят об «одностороннем шифровании».85.2.88.39 12:21, 18 июня 2007 г. (UTC)
О, это было интересно. Я часто думаю и использую хэши как своего рода функции «одностороннего шифрования». И я использую их несколькими способами как одностороннее шифрование, а не только для хеширования паролей. И я думаю, что многие криптопользователи/программисты думают о хэшах как об одностороннем шифровании.
В настоящее время у нас в Википедии нет статьи об одностороннем шифровании . Я думаю, что решением на данный момент может быть создание отдельного раздела об «одностороннем шифровании», где могут быть выражены различные точки зрения на этот вопрос. И если раздел «одностороннее шифрование» разрастется, мы можем сделать его отдельной статьей. Пока что сделал редирект с одностороннего шифрования на эту статью. Я также добавил упоминание об «одностороннем шифровании» в разделе «Применения хеш-функций». Как показать использование выражения, так и заставить любого, кто ищет выражение, найти эту хеш-статью.
-- Дэвид Гётберг 14:44, 18 июня 2007 г. (UTC)
Шифрование, односторонняя функция и криптографические хеш-функции — это разные понятия, которые не следует смешивать друг с другом. Для разработки протокола важно определить, каковы (предполагаемые) свойства примитивов, используемых в протоколе, какие свойства отсутствуют и какие свойства необходимы для обеспечения безопасности протокола. Например, я думаю о криптографических хеш-функциях просто как о функциях, обладающих тем свойством, что трудно найти два входа, которые хэшируют с одним и тем же результатом. Некоторые хэш-функции, такие как семейство SHA, могут иметь дополнительные свойства, делающие их подходящими для таких приложений, как HMAC или хранилище паролей. Другие хэши - нет. Примером является ВШ [5]. У VSH есть веские аргументы в пользу устойчивости к коллизиям. Но у него есть нежелательное свойство, позволяющее инвертировать некоторые короткие сообщения. (Это указано в документе вместе с предупреждением не использовать функцию вслепую для приложений, для которых она не была определена.) Следовательно, не каждая хеш-функция является хорошим выбором для хранения паролей. У меня все еще есть проблемы с пониманием того, что люди на самом деле имеют в виду, когда говорят об одностороннем шифровании, но у меня складывается впечатление, что большинство людей, использующих этот термин, тоже не знают. Вместо перенаправления может быть лучше иметь какую-то страницу устранения неоднозначности. 85.2.67.208 18:22, 19 июня 2007 г. (UTC)

Определение сопротивления столкновению

Я вернул модификацию от 18 марта 2007 года на сопротивление столкновению. Атакующий может выбрать как m1, так и m2. Ему не нужно ограничиваться m1, установленным другими.

НормХарди 00:21, 20 июля 2007 (UTC)

Выбор изображения

Хеш-функция в действии. (ИЗОБРАЖЕНИЕ ДЭВИДА)
Результаты хеш-функции Whirlpool для некоторых входных данных в шестнадцатеричном формате . Обратите внимание на большую разницу в последних двух значениях хеш-функции, созданную простой заменой одной буквы. (ИЗОБРАЖЕНИЕ ДЖАФЕТА)

Несколько дней назад пользователь Jafet.vixle изменил изображение, использованное в статье. Я не согласен с изменением.

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

-- Дэвид Гётберг 16:26, 21 августа 2007 г. (UTC)

Я согласен. Старая фотография предпочтительнее. 169.231.5.121 07:22, 22 августа 2007 г. (UTC)
Поскольку больше никто ничего не сказал, я вернулся к своему изображению в статье. -- Дэвид Гётберг 15:15, 26 августа 2007 г. (UTC)
Поскольку «ввод» цитируется как «сообщение», измените метку на «входное сообщение». — Предыдущий неподписанный комментарий добавлен 82.31.143.204 ( обсуждение ) 20:37, 30 октября 2012 г. (UTC)

Требуется уточнение

Может ли кто-нибудь знающий уточнить единицы, используемые в разделе «Список криптографических хеш-функций»? Например, SHA-1 выводит 160 бит или 160 байт? — Предыдущий неподписанный комментарий добавлен 196.7.19.250 ( обсуждение ) 15:44, 26 октября 2007 г. (UTC)

Это должны быть биты. (анонимно)


Я не понимаю часть использования нескольких хеш-функций для повышения безопасности. Если это не повышает безопасность, что означает, что SSL использует его в случае нарушения одного из MD5 и SHA-1?

ЦИССП?

Почему здесь применяется Категория:CISSP? Просто потому, что хеш-функции связаны с безопасностью в Интернете и их знание необходимо для прохождения этого теста? Существует множество программных протоколов, основанных на хеш-функциях, курсов, обучающих хеш-функциям, книг, в которых они упоминаются — мы их тоже связываем? Я не уверен, что люди, читающие страницу хэш-функции, найдут ценность в этой категории. Упоминание хеш-функций как части теста CISSP на странице CISSP может быть более уместным. NoDepositNoReturn ( обсуждение ) 18:25, 29 июня 2008 г. (UTC)

Неправильный re Debian и сцепленные хэши

В статье неверно указано, почему файлы пакетов Debian содержат несколько хэшей. Apt проверяет только самый сильный хэш, с которым он знает, как обращаться. Для текущего apt это хэш SHA256. Для более старых apts это SHA1 или MD5SUM. Более слабые хэши игнорируются. Более слабые хэши остаются в файлах, чтобы более старые версии apt могли проверять файлы во время обновлений.

Доказательство: Строка 1324 файла accept-item.cc в источнике apt. ExpectedHash устанавливается только для самого надежного найденного хэша. — Предыдущий неподписанный комментарий добавлен 67.223.5.142 ( обсуждение ) 19:39, 31 декабря 2008 г. (UTC)

информационный хэш - информационный хэш

Нет актуальных статей WP о так называемом «информационном хэше», который используется с торрентами. Проходное упоминание о шифровании протокола BitTorrent, похоже, является единственным текущим содержанием. Если вы понимаете эту тему, пожалуйста, добавьте термин в эту статью в правильном контексте.

«Информационный хеш предназначен исключительно для клиента BitTorrent. BT-клиент, который вы используете, использует информационный хеш, чтобы убедиться, что то, что вы загружаете, является законным с точки зрения сервера. Вы ничего не делаете с этим». - 96.237.7.209 ( разговор ) 13:59, 18 января 2009 г. (UTC)

Рандомизированное хеширование, разрыв сертификата SSL MD5 2008 г.

  • Рандомизированное хеширование — это просто причудливое название для подписантов, которые вводят случайное число в контент, который будет хэшироваться для цифровой подписи, более или менее. Но это сделало бы взлом SSL-сертификата 2008 года невозможным, потому что злоумышленники не смогли бы точно выбрать, какой контент будет подписан, и, похоже, это привлекло внимание NIST, потому что могло сделать подписи более устойчивыми к взлому алгоритма. (Чтобы воспроизвести взлом MD5 2008 года с рандомизированным хэшированием, злоумышленникам потребуется либо атака по прообразу, либо атака столкновений, которая работает, даже если часть хеш-ввода неизвестна.) Исследователи, которые сделали взлом 2008 года, предложили нечто подобное — убедитесь, серийный номер случайный.
  • Нарушение сертификата SSL MD5 2008 года показывает, что хеш-функции имеют значение; кажется, что это заслуживает упоминания здесь. Вы не знаете, что у вас есть, пока это не исчезнет; вы не думаете о сантехнике, пока она не сломается; и мы все не ценим хеш-функции, пока некоторые исследователи не взломают Интернет, потому что мы не используем хорошие. :)

Было бы забавно, хотя и безнадежно педантично, отметить, какие именно применения требуют, чтобы хэш-функции выглядели довольно случайным образом (например, проверки целостности), устойчивы к прообразам, устойчивы к коллизиям, псевдослучайны или основаны на надежных блочных шифрах.

Заметки для себя, но если кто-то захочет поднять это, я буду рад.

67.119.195.43 ( разговор ) 04:53, 2 февраля 2009 г. (UTC)

Объединение хеш-функций

Я не согласен со следующим утверждением в тексте:

Объединение выходных данных нескольких хеш-функций обеспечивает безопасность, по крайней мере, не меньшую, чем самый надежный из алгоритмов, включенных в объединенный результат.

Это может быть верно для сопротивления столкновению, но неверно в отношении сопротивления прообраза. Например, если одна хеш-функция является SHA-1, а другая функция является просто функцией тождества, то найти x из SHA-1( x ) || несложно. х . Потенциальная односторонность SHA-1 вообще не помогает защитить x здесь. В конце концов, устойчивость к прообразу является требованием для безопасной хэш-функции. 85.0.14.230 ( разговор ) 08:46, 2 февраля 2009 г. (UTC)

Я считаю, что вы правы, в тексте должен быть четко указан источник этого утверждения и указано, для каких типов атак оно верно; из вашего примера ясно, что атака прообраза на конкатенацию хэшей требует только изучения самого слабого из них и на самом деле может быть даже лучше. Dcoetzee 10:34, 2 февраля 2009 г. (UTC)
Я согласен с тем, что утверждение верно только для сопротивления столкновению. Доказательство безопасности объединенных хэшей http://eprint.iacr.org/2008/075 . Кроме того, он обеспечит безопасность не «как минимум так же хорошо», а «в лучшем случае». Я собираюсь попытаться исправить это, но подозреваю, что для полного исправления потребуется несколько итераций. Quelrod ( разговор ) 19:01, 31 июля 2010 г. (UTC)
это утверждение верно для сопротивления столкновению и сопротивления второго прообраза. Однако цитата, предложенная выше ( http://eprint.iacr.org/2008/075 ), касается другого вопроса. Правильная ссылка на мою статью, которая также намного раньше, но здесь, в журнальной версии: Herzberg, Amir. «Фольклор, практика и теория надежных комбайнеров». Журнал компьютерной безопасности 17.2 (2009): 159-189. — Предыдущий неподписанный комментарий добавлен Амирхе ( обсуждение • вклад ) 21:32, 29 августа 2018 г. (UTC)

две одинаковые вещи

  1. невозможно изменить сообщение без изменения его хэша,
  2. невозможно найти два разных сообщения с одинаковым хешем.

разве они не одно и то же? Твипли ( разговор ) 22:59, 22 июля 2009 г. (UTC)

Нет. Чтобы нарушить первое свойство, вам нужен метод для поиска сообщения с определенным значением хеш-функции (первого сообщения). Чтобы нарушить второе свойство, вам нужен метод для поиска любых двух сообщений, которые имеют общее хеш-значение — любые два сообщения и любое хеш-значение. Чтобы криптографическая хеш-функция была безопасной, не должно быть никакого («выполнимого») метода для этого. — Gavia immer ( разговор ) 23:07, 22 июля 2009 г. (UTC)

Это одно и то же. Если нарушается первое (или второе) свойство, то нарушается и второе (первое). По крайней мере, с точки зрения чистой логики, это сильно коррелированные утверждения, и ни одно из них не может быть самостоятельным. — Предыдущий неподписанный комментарий добавлен 99.240.92.102 ( обсуждение ) 15:59, 10 ноября 2009 г. (UTC)

WP:NOTAFORUM , но обнаружение атаки, нарушающей первый пункт, называется атакой «прообраз»; обнаружение атаки, нарушающей второй пункт, является атакой «столкновение». Атаки столкновения легче найти; MD5 уязвим для коллизий (обнаружение двух разных сообщений с одним и тем же значением MD5), но нет известных атак предварительного изображения на MD5 — например, никто не понял, как создать файл с суммой MD5 0102030405060708090a0b0c0d0e0f. Самбой ( разговор ) 16:41, 10 ноября 2009 г. (UTC)

"с недостатками"

Что означает обозначение «с недостатками» в таблице в конце этой статьи? Я думаю, это означает, что кто-то когда-то думал, что у него была успешная атака на схему, но они ошибались: их атака не работает. Неработающая атака - это вообще не атака. Если я правильно понимаю, вводить в эту таблицу какие-либо цифры с «недостатками» вводит в заблуждение: их следует удалить. — Предыдущий неподписанный комментарий добавлен 128.32.153.194 ( обсуждение ) 00:34, 6 марта 2010 г. (UTC)

Согласен, что в том числе атаки с недоработками включать не стоит. Я обновил некоторые из них новыми исследованиями. Вы правы, что «с ошибками» означает, что кто-то опубликовал атаку, но в большинстве случаев, когда другой исследователь пытался воспроизвести результат, они обнаруживали в нем серьезные проблемы. В меньшем количестве случаев фактические авторы опубликованных исследований сами обнаруживали недостатки и обнародовали эту информацию. Хотя в последнем случае, когда автор обнаружил недостатки, статья обычно удаляется с таких мест, как http://eprint.iacr.org/complete/ Quelrod ( обсуждение ) 18:39, 31 июля 2010 г. (UTC)

Синхронизация последних атак

Мне любопытно, есть ли какой-нибудь способ разделить несколько страниц или какой-то способ поддерживать страницы с одинаковым содержанием в актуальном состоянии. Например, есть как минимум: Cryptographic_hash_function Comparison_of_cryptographic_hash_functions Hash_function_security_summary

Они не всегда синхронизированы друг с другом, не говоря уже о страницах для каждой хеш-функции. Мысли? Quelrod ( разговор ) 19:34, 31 июля 2010 г. (UTC)

Бинарный метод хеширования

Я собираюсь удалить с этой страницы «метод двоичного хеширования», предложенный Даймоном Шредером. Это неопубликованная хэш-функция. Он плохо спроектирован, и коллизии найти почти несложно. Например, две строки "10608939Быстрая коричневая лиса перепрыгивает через ленивую собаку" и "10308969Быстрая коричневая лиса перепрыгивает через ленивую собаку" имеют одинаковый хэш длиной 32 "+!Yguf*aNV!P#Hiw*{*[# ~*;1NfL+!%%". Я проверил хэш на веб-странице автора. — Предыдущий неподписанный комментарий добавлен 85.1.57.131 ( обсуждение ) 10:25, 28 декабря 2010 г. (UTC)

Пожалуйста, не удаляйте комментарии. Если вы не согласны с комментарием и считаете, что BHM следует указать здесь, напишите ответ. Т.е. код, предоставленный для BHM, некачественный и не все реализации дают одинаковые результаты. Это может быть связано с ошибками округления, поскольку хэш-функция использует арифметику с плавающей запятой. Если вы считаете, что приведенный выше пример не является коллизией, укажите, что вы считаете эталонной реализацией. В любом случае есть альтернативные строки, которые, кажется, дают коллизии: т.е. возьмите любую строку длиннее, чем длина хэша, и переставьте символы в конце. Например, «xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx12» и «xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx21» дают один и тот же хэш размера 32 с реализацией Python. 83.78.157.215 ( разговор ) 10:28,

Недостаток иллюстрации

Нынешняя иллюстрация Алисы-Боба кажется ошибочной. Например, рассмотрим следующий сценарий: Алиса создает и сохраняет бессмысленную строку Call A, отправляет хеш (A) Бобу (под предлогом примера). Когда Боб приходит к выводу, что он нашел решение, Алиса просто показывает свой одноразовый номер как все, что она хочет (W) - A. Затем Боб (ошибочно) подтвердит, что у Алисы было W все время. В этом контексте хэш бесполезен, Алиса ни к чему не обязывается, раскрывая свой хэш. В контексте примера последствия неясны, так как это зависит от того, раскроет ли Боб решение первым или нет. Однако мы должны предположить, что он не раскрывает число перед Алисой, как если бы он это сделал, Алиса просто принимает W в качестве решения. Следовательно, весь одноразовый номер и раскрытие являются пропущенными, например

Это можно исправить, потребовав от Алисы разглашения хэша одноразового номера, а также суммы одноразового номера и решения. — Предыдущий неподписанный комментарий добавлен 155.198.75.173 ( обсуждение ) 14:36, 2 июня 2011 г. (UTC)

Значение атак столкновений

В таблице хеш-функций отсутствует ссылка на атаку столкновений против Haval. Возможно, что более важно, он неверно истолковывает ссылку на предполагаемую атаку столкновения против Whirlpool: то, что было достигнуто в статье Lamberger et al. является *различителем* по сравнению с Whirlpool, основанным на *почти столкновении* с базовой *функцией сжатия*. Это всего лишь означает, что можно отличить дайджест Whirlpool от случайной 512-битной строки, затрачивая 2 176 шагов (проверка документации системы с использованием хэша, скорее всего, даст тот же результат гораздо быстрее). Это полностью отличается от заявления о том, что существует атака коллизии против самой *хеш-функции*; авторы [1]ни делать этого, ни заявлять, что они могут это сделать, вопреки тому, что утверждается на столе в этой статье в том виде, в каком она написана в настоящее время. — Предыдущий неподписанный комментарий добавлен 189.38.230.167 ( обсуждение ) 01:20, 9 декабря 2011 г. (UTC)

использованная литература

  1. ^ http://www.springerlink.com/content/9711452444u24861/

Неверная запись в таблице RIPEMD

В таблице указано, что ни один вариант RIPEMD не имеет коллизий. Тем не менее, в статье RIPEMD есть ссылка со ссылкой на документ, в котором указана явная коллизия (не уверен, что это старый RIPEMD 128 или новый). А в разделе «Сравнение криптографических хеш-функций#Криптоанализ » указаны коллизии для RIPEMD 160. Следовательно, утверждение, что у них нет коллизий, вводит в заблуждение. и, очевидно, таблица должна быть исправлена. Поскольку коллизии затрагивают 128- и 160-битные версии, как с этим справиться? Разделить на 4 записи? Или объединить без коллизий вместе (т.е. 256/320) в одну запись? -- pgimeno ( разговор ) 23:57, 22 апреля 2012 г. (UTC)

RIPEMD четко заявляет, что «сообщалось о столкновении для исходного RIPEMD». это та же самая коллизия, которая появляется в таблицах в разделе Сравнение криптографических хэш-функций#Криптоанализ и в этой статье. запись для RIPEMD-160 предназначена для версии с уменьшенным патроном, всего 48 патронов. поскольку таблица в этой статье содержит атаки только на полнораундовые алгоритмы, таблица верна и не нуждается в изменении. -- MarioS ( разговор ) 14:07, 23 апреля 2012 г. (UTC)
Мой плохой, ты прав. Извинения. -- pgimeno ( разговор ) 19:43, 24 апреля 2012 г. (UTC)

чего ждать?

Я немного запутался... Это мое понимание хеширования:

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

Я прав? — Предыдущий неподписанный комментарий добавлен пользователем 96.5.166.66 ( обсуждение ) 20:57, 23 апреля 2012 г. (UTC)

Первое предложение неполное?

Это первое предложение этой статьи кажется неполным предложением. Просто фраза не имеет особого смысла.

Криптографическая хеш-функция — это хеш-функция, то есть алгоритм, который берет произвольный блок данных и возвращает битовую строку фиксированного размера, (криптографическое) хэш-значение, так что (случайное или преднамеренное) изменение данных будет (с очень большой вероятностью) изменить значение хеша.

Хатчад ( разговор ) 21:59, 14 сентября 2012 г. (UTC)

Другие хэш-функции

  • Можно ли добавить SipHash в список криптографических хеш-функций? его 64-битный вывод может не соответствовать другим тяжелым хэш-функциям, но SipHash был определен с криптографическими требованиями. — Предыдущий неподписанный комментарий добавлен Ydroneaud ( обсуждение • вклад ) 09:55, 14 декабря 2012 г. (UTC)

Ссылка на сайт

Утверждение о том, что «стандарт шифрования WEP, но была легко обнаружена атака, использующая линейность контрольной суммы», должно иметь связь линейности с тем, какое значение линейности подразумевается. RJFJR ( разговор ) 18:45, 22 июля 2013 г. (UTC)

Определение «сопротивления перед изображением»

Вот что эта статья дает в качестве определения «сопротивления прообразу»:

Учитывая хэш h, должно быть трудно найти сообщение m такое, что h = hash(m). Это понятие связано с понятием односторонней функции. Функции, у которых отсутствует это свойство, уязвимы для атак на прообразы.

Как уже говорилось, никакая хэш-функция не может быть устойчивой к прообразу. Вот хэш h, для которого очень легко найти прообраз: h(0^n). Подразумевается, конечно, нечто иное, а именно то, что для случайного хеша h должно быть трудно найти любое сообщение m, такое что h = hash(m).

Статья Википедии «Атака прообраза» дает лучшее определение: «практически для всех заранее заданных выходных данных вычислительно невозможно найти какие-либо входные данные, которые хэшируют на этот выход, т. е. найти любой прообраз x по заданному «y», такой, что ч(х) = у».

Я предлагаю использовать эту формулировку, а не формулировку «дан хэш h».

Snapdragon630 ( обсуждение ) 02:34, 16 октября 2014 г. (UTC)

В качестве доказательства работы

Я думаю, что мы можем добавить дополнительное применение хеш-функций, используемых в системе проверки работоспособности, такой как hashcash . Маногуру ( разговор ) 13:25, 25 января 2015 г. (UTC)

хеш-функция с лазейкой

Я мало что знаю об этом, но мне кажется, что криптографическая хеш-функция — это хеш-функция, которая также является функцией -лазейкой . Могут быть тонкости, которые делают их не совсем одинаковыми, но я предлагаю упомянуть и сделать ссылку на эту связь с функциями лазейки во введении к этой статье. 2601:681:4902:31B8:95CC:E49C:E8F:3502 ( разговор ) 03:31, 4 сентября 2015 г. (UTC)

Неоднозначное определение

Текущее определение гласит: «Криптографическая хеш-функция — это хэш-функция, которую практически невозможно инвертировать, то есть воссоздать входные данные только из ее хэш-значения». Однако, например, на вики-странице MD5 мы говорим, что «алгоритм дайджеста сообщения MD5 является широко используемой криптографической хеш-функцией», даже несмотря на то, что «существует атака столкновений, которая может найти коллизии в течение нескольких секунд». В связи с этим возникает вопрос: подходит ли это определение в мире, где хеш-функции ПРЕДНАЗНАЧЕНЫ для обеспечения качества «одностороннего хэширования», даже если позже оно теряет это качество?

Я предлагаю следующее новое определение:

«Криптографическая хеш-функция — это хеш-функция, которую практически невозможно инвертировать, то есть воссоздать входные данные только из ее хэш-значения».

Я также предлагаю добавить предложение или абзац, объясняющий тот факт, что не все «криптографические хеш-функции» на самом деле безопасны из-за того, что обстоятельства иногда меняются таким образом, что это приводит к «одностороннему» аспекту алгоритма. чтобы больше не быть правдой. — Предыдущий неподписанный комментарий добавлен 54.240.196.170 ( обсуждение ) 16:20, 22 октября 2015 г. (UTC)

Неверное вступление

Во введении говорится, что идеальный криптографический хэш должен быстро вычисляться. На самом деле это неправильно в одном из основных приложений криптохэшей, а именно в системах паролей/аутентификации. В таких системах количество вычисляемых хэшей относительно невелико (примерно один раз за вход в систему), поэтому хеш-функция может выполняться долго. Тем не менее, взлом паролей злоумышленнику необходимо попробовать все возможные комбинации хэшей, чтобы взломать пароли, и этот злоумышленник получает большую выгоду от использования быстрой хеш-функции по сравнению с медленной хеш-функцией. 165.134.12.132 ( разговор ) 17:10, 21 сентября 2016 г. (UTC)

я не думаю, что это неправильно. хэш-функция общего назначения, о которой идет речь в статье, должна быть быстрой, потому что есть случаи использования, в которых производительность имеет значение. если у нас есть быстрые хеш-функции, на их основе можно сделать дорогостоящие специальные kdf. так что нам на самом деле не нужны дорогостоящие примитивы. стоимость всегда можно добавить позже. если вы посмотрите на любую дорогостоящую схему, внутри будет высокопроизводительный примитив. Кристиан Пинтер ( разговор ) 22:06, 21 сентября 2016 г. (UTC)
это все еще неправильно, вот ссылка для уточнения: https://www.youtube.com/watch?v=GT_qgImaUS4#t=10m15s - смотреть до 10:40 - хорошая хэш-функция должна быть достаточно сложной, чтобы она не могла вычисляться быстро. Это не вопрос того, чтобы сделать его медленнее позже, поскольку кто-то может просто повторно реализовать его эффективно, например, при создании радужной таблицы. — Предыдущий неподписанный комментарий добавлен 129.234.103.198 ( обсуждение ) 19:19, 10 октября 2017 г. (UTC)

Атака столкновения SHA-1

Похоже, что была проведена успешная атака коллизии против SHA-1 , поэтому в этой статье, вероятно, требуется обновление строки «Хотя теоретические недостатки SHA-1 существуют,[14][15] коллизии (или почти коллизии) не было. все же нашли». 68.116.67.198 ( разговор ) 17:51, 24 февраля 2017 г. (UTC)

Небольшое дополнение: предложение в начале гласит: «функция, которую невозможно инвертировать», SHA-1 был нарушен, эта статья нуждается в обновлении.

Внешние ссылки изменены

Здравствуйте коллеги википедисты.

Я только что изменил 2 внешние ссылки на криптографическую хеш-функцию . Пожалуйста, найдите минутку, чтобы просмотреть мое редактирование . Если у вас есть какие-либо вопросы или вам нужно, чтобы бот игнорировал ссылки или страницу в целом, посетите этот простой FAQ для получения дополнительной информации. Я сделал следующие изменения:

  • Добавлен архив https://archive.is/20121208212741/http://wiki.crypto.rub.de/Buch/movies.php на http://wiki.crypto.rub.de/Buch/movies.php
  • Добавлен архив https://archive.is/20121206020054/http://www.guardtime.com/educational-series-on-hashes/ на http://www.guardtime.com/educational-series-on-hashes/

Когда вы закончите просмотр моих изменений, вы можете следовать инструкциям в приведенном ниже шаблоне, чтобы исправить любые проблемы с URL-адресами.

Это сообщение было опубликовано до февраля 2018 года. После февраля 2018 года разделы страницы обсуждения «Внешние ссылки изменены» больше не генерируются и не отслеживаются InternetArchiveBot . Никаких специальных действий в отношении этих уведомлений на странице обсуждения не требуется, кроме регулярной проверки с использованием приведенных ниже инструкций инструмента архивации. У редакторов есть разрешение на удаление этих разделов страницы обсуждения «Внешние ссылки изменены», если они хотят избавиться от беспорядка на страницах обсуждения, но перед массовым систематическим удалением см. RfC . Это сообщение динамически обновляется через шаблон (последнее обновление: 18 января 2022 г.) .{{source check}}

  • Если вы обнаружили URL-адреса, которые бот ошибочно считал мертвыми, вы можете сообщить о них с помощью этого инструмента .
  • Если вы обнаружили ошибку с какими-либо архивами или самими URL-адресами, вы можете исправить их с помощью этого инструмента .

Ура.— InternetArchiveBot ( Сообщить об ошибке ) 02:39, 15 августа 2017 г. (UTC)

Односторонняя функция

В этой статье термин «односторонняя функция» используется для обозначения «функции, которую невозможно инвертировать». Это проблематично, поскольку критерии невыполнимых, то есть неразрешимых, проблем не определены четко, в то время как односторонние функции имеют конкретное математическое определение. Кроме того, исходя из формального определения односторонней функции, неизвестно, существуют ли вообще такие функции. Было бы благоразумно упомянуть где-нибудь в статье, что когда мы говорим об односторонних функциях, мы делаем это в неформальной манере, несовместимой с точным значением термина. Jwuthe2 ( разговор ) 05:40, 12 января 2018 г. (UTC)

Ложное утверждение в свойствах

«Сопротивление столкновениям подразумевает сопротивление второму предварительному изображению, но не подразумевает сопротивление предварительному изображению».

В соответствии с предоставленным источником устойчивость к коллизиям подразумевает устойчивость к прообразу до преимущества для противника 2 n-m , где n — длина хэша, а m — размер домена. Поскольку m часто намного больше, чем n (m >> n), преимуществом противника во многих случаях можно пренебречь, а приведенное выше утверждение ложно. Пример: размер домена 2n и длина хеша n. Преимущество 1/2 n . Dave4422 ( разговор ) 14:17, 31 января 2018 (UTC)

h(x) := MD5(x) + MD5(x+x) с "+" в смысле конкатенации

Просто идеально. 

-- 84.118.82.226 ( разговор ) 12:12, 16 апреля 2018 г. (UTC)

Практическая неосуществимость не имеет НИЧЕГО общего с неразрешимостью теории сложности.

Кажется, существует общее заблуждение, что понятие «неосуществимое» в криптографии такое же, как (или связано с) понятие «неразрешимое» из теории сложности. (Они были связаны в статье.) Это не так. Теория сложности рассматривает только асимптотическое поведение стоимости вычисления функции, когда размер входных данных стремится к бесконечности. При инвертировании криптографической хэш-функции, такой как SHA или MD5, ввод имеет фиксированный размер. В этом случае теория сложности говорит, что проблема тривиальна и может быть решена за время O(1).
На самом деле теория сложности не имеет ничего общего с практической криптографией. Он не может доказать, что функции практически невозможно инвертировать. Он даже не может доказать, что SHA сложнее инвертировать, чем функцию "взять первые 256 бит сообщения».
На самом деле (насколько мне известно) не существует математического доказательства того, что любая функция является однонаправленной. Надежность криптографических хэш-функций «доказана» только «эмпирически», когда десятилетиями они сопротивлялись атакам самых умных криптографов.
-- Хорхе Столфи ( разговор ) 06:42, 1 июня 2019 г. (UTC)

Давайте держать его сбалансированным

@ Intgr : Зачем выбирать одно свойство в списке «желательных свойств» , чтобы поместить его рядом с тремя обязательными свойствами (цитируя ваш источник: «Ожидается, что основные (классические) свойства, которые хеш-функция сохранит, это: устойчивость к столкновению, предварительное изображение сопротивление и 2-е сопротивление прообраза"). Почему бы не остановиться на этом и не включить вместе с ним в лидеры пять других «желательных свойств, которые желательно сохранять хеш-функциям», перечисленных вашим источником? И да, «статистическая корреляция» плохо определена в данном контексте. Корреляция отдельных входных битов с выходными битами? Корреляция входных текстов с выходными значениями? Источник не определяет это, не расширяет утверждение и не дает ссылки. — Куондум23:58, 3 июля 2019 г. (UTC)

Использование в хеш-таблицах

У нас есть пара абзацев об использовании криптографических хэшей в хеш-таблицах (из этого редактирования [6] ):

Одним из основных применений хэш-функции является возможность быстрого поиска данных в хеш-таблице. Криптографические хеш-функции, являясь особым видом хеш-функций, также хорошо подходят для этого приложения.

Однако по сравнению со стандартными хеш-функциями криптографические хэш-функции, как правило, требуют гораздо больших вычислительных ресурсов. По этой причине они, как правило, используются в контекстах, где пользователям необходимо защитить себя от возможности подделки (создания данных с тем же дайджестом, что и ожидаемые данные) со стороны потенциально злонамеренных участников.

Это без источника. Второй абзац неясен: что такое «ожидаемые данные» в контексте хеш-таблицы? Кроме того, утверждение о том, что «хэш-функции хорошо подходят для этого приложения», сомнительно по точной причине, указанной во втором абзаце: производительность. Учитывая, что претензии сомнительны, неясны и не имеют источников, я планирую удалить оба абзаца. - Кросби 02:36, 15 августа 2019 г. (UTC)

Получено с https://en.wikipedia.org/w/index.php?title=Talk:Cryptographic_hash_function&oldid=1063134223 "
Contribute a better translation