Pull to refresh

Comments 123

вместо programme обычно пишут program, если это на английском написано
да да — мне тоже эта кроватная функция понравилась =)
Да у автора и с русским не очень:

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

Да, я понял, он всего лишь торопился.
Как эти Розентали уже достали. Ну что вам не имется?
Сынок родной, увидел ошибку — напиши в личку, не надо исполнять на главной, ценность таких коментов равна нулю.
Я Вам не сынок.
Про ценность — Как и ценность комментов про Розенталей.
Про личку — я и не писал про ошибку. Я лишь указал на правила хабра в ответ на Ваш бесценный коммент
UFO just landed and posted this here
UFO just landed and posted this here
Вы, видимо, в свое время эти самые уроки не посещали… А жаль=\
UFO just landed and posted this here
Это правильно, значит тема актуальна. И потерянная карма того стоит. Я все написал верно: я люблю своя язык, но увидел ошибку — напиши в личку, это не блог русского языка
я люблю своя язык


Моя твоя не понимай…

Орда детектед :)
>Я все написал верно: я люблю своя язык...

Нет, вы написали это неверно. Верно будет «я люблю своя языка».
Родной, ты запятую забыл.
таки нет, если «сынок родной» ~ «родной сынок» — одно обращение. «сынок, родной, ...» — два обращения
Запомните, что «не имется» пишется как «неймется», и они начнут доставать вас меньше.
Нет ты посмотри, еще один Розенталь. У вас сообщество?
Ага. Международное. Даже лозунг есть: «Grammatik macht frei!»
Лучше уж — Grammatisch. Praktisch. Gut! )
Да, у нас тут сообщество носителей русского языка.
>Запомните, что «не имется» пишется как «неймется»

Точкофилы протестуют! Это слово пишется как «неймётся»!
Ха, вот не зря сомневался.:)
А вообще конечно я прошу прощения за ошибки. Код и заметка писались глубокой ночью, мозг отказывался реагировать на какие-либо раздражители.
оффтопик::хозяйке_на_заметку {
    отбивайте в коде операторы(=, ==, >> и т.д.) пробелами с обоих сторон
    отбивайте запятую пробелом справа (s2.erase(0, 64);)
    для склейки строк обратный слеш не нужен
}
Такъ что же вам не нравитъся? =)
мне кажется писать programme не правильно
А в IT, в свою очередь, в подавляющем большинстве случаев используется именно American English.
Та ну какая разница, ну нравится человеку так писать, а вы тут тред развели на два экрана. Топик, как вы могли заметить, вообще не об этом.
Смотря кто пишет. Читал тут доку по RFB протоколу и удивлялся слову colour при том, что одно из слов на обложке про авторов — AT&T Labs. Сейчас только что поискал местонахождение компании _текущего_ автора этой доки, таки да, теперь UK. И цвета он аккуратно поправил :).
правильно писать «аппликация»
Это аналогично с «резолюция»? :)
Я имел ввиду, какая разница что выводит программа? Некоторым обязательно надо что-то написать в топик, не важно что…
en.wiktionary.org/wiki/programme
UK: programme is used in all cases except for computer code, in which case program is generally used. Older sources may use programme for computer code.

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

Spelling help
Remember that programme ends with — amme, unless it is used in computing senses, when program is correct. In American English, it is always spelled program.
Похоже на то, спасибо. Поставлю вам плюс в благодарность.
UFO just landed and posted this here
Отличная статья, читал с интересом.
«Ловкость рук и никакого мошенничества!»

Спасибо, с удовольствием прочитал статью.
UFO just landed and posted this here
Эх, тоже самое бы, но на примере действительно Evil кода)))
А ещё такие программы можно написать например проверяя название исполняемого файла самой себя же.
И да, спасибо за интересную статью.
Таким образом открывается простор для злоупотреблений на сервисах хранения файлов, т.к. там они считаются идентичными при равном размере и одинаковом хэше.

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

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

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

Если хеши разные, то файлы разные, если одинаковые, то это ни о чём не говорит.
UFO just landed and posted this here
Это какой-то аргумент что ли? Мало ли где это используется. Нельзя так делать.
У нас в компании при хранении файлов используется хэш+размер файла для их идентичности — чтоб 1 файл 50000 раз не копировать каждому пользователю, физически в единственном виде (не считая бэкапов) существует. Правда, у нас наверное хэш более умный :)
Это сильно ситуацию не влияет :)
Зато как будет обидно, если коллизия всё же произойдёт? И заметят это совсем не сразу. И вообще, хрен поймёшь, что произошло.
UFO just landed and posted this here
Говорит. Вот ровно о том и говорит, что файлы НЕ [точно не идентичны]. Мало того, все-таки говорит, что идентичны, но с точностью до почти наверное (в строгом смысле этого выражения). Наличие одновременно двух хэшей логически ничего не меняет, но существенно уменьшает вероятность строгой неидентичности.

Это, возможно, уязвимо (существование строго необратимых хэш-функций, несколько я понимаю, не доказано), но в значительном числе случаев «достаточно» для бытового использования. Вы же, обещая приехать в гости, не говорите «если только мне по дороге не упадет на голову кирпич, рояль, топор, сундук и далее еще бесконечное множество предметов». Но из этого вовсе не следует, что вам нельзя верить.
Вы какую-то странную вещь говорите. Какая ещё бытовое использование? Что это? Хешем хлеб резать?

Представьте, что операция сравнения в Си выдавала бы полную чушь один раз на десять миллионов? Это «бытовой точности» нам хватило бы, чтобы программировать в Си?

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

И вот, через полгода, ко мне приходит и говорит, что один файл не заливается, утверждается, что он есть, но его точно нет.

И что мне делать, с вашим «бытовым использованием»? Рассказывать заказчику о хешах? Да он меня мудаком назовёт и будет прав.
>Вы какую-то странную вещь говорите. Какая ещё бытовое использование? Что это?

Скачиваем файл. Считаем md5 и sha. Сравниваем с опубликованными. Если совпадает, значит перескачитвать не нужно (почти наверное). Если не совпадает — нужно точно перескачать. Это и есть бытовое использование.

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

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

Любопытно, и сколько же?
Ох. Такое ощущение, что вы либо совсем не в теме, либо троллите. Я не хочу продолжать диалог.
Ну, хамить — дело несложное. А в чем мои рассуждения неверны, я так и не понял.

Смысл хеша ровно в том, чтобы относительно быстро, дешево и сердито дать ответ с точностью до почти наверное.

Ваш пример с хостингом — я также не понимаю, чем вам там хэши мешают. Ну даже совпали они (скажем, оба: и md5, и sha1, и при этом размер у файлов одинаковый) — и чего, жизнь кончилась? Взяли, посчитали для сегмента случайной длины со случайным смещением. Опять совпали? — и еще раз совпали? — «ну тогда я не знаю» © — дальше, если в этом есть коммерческий (или какой там) смысл, побайтное сравнение или что там вам больше нравится.

Вы знаете способ эффективнее? Расскажите, я буду благодарен.
Давайте посчитаем, сколько коллизий будет (независимо от размера файлов), удивитесь.

Общая мощность пространства значений пары хэшей md5+sha1: 288 бит, а значит есть 2^288 возможных значений (на самом деле меньше за счёт неидеальности хэш-функций, но пока пропустим этот момент)
Допустим у вас на хостинге 2^32 файлов (миллиард).
Вероятность того, что случайно произойдёт хоть одна коллизия примерно 2^288 / 2^64 = 2^224
Это 3.7*10^(-68)

Оценка весьма грубая, но всё же.
> Общая мощность пространства значений пары хэшей md5+sha1: 288 бит, а значит есть 2^288 возможных значений (на самом деле меньше за счёт неидеальности хэш-функций, но пока пропустим этот момент)
Во-первых, я не понял почему мы опускаем этот момент. Как относятся распределяются значения md5 + sha1 на одном и том же файле мы не знаем. Они могут давать значения куда у́же, чем 288 бит.

Во-вторых, я не понял почему мы игнорируем длину файла. Я специально привёл в пример видеохостинг, то есть файлы примерно от 800МБ до 4ГБ. Можно ещё ухудшить ситуацию, если взять видеохостинг каких-то определёных рипов, нампример, только HDRip.
> Как относятся распределяются значения md5 + sha1 на одном и том же файле мы не знаем. Они могут давать значения куда у́же, чем 288 бит.
Да, действительно пространство значений меньше чем 288 бит. Мне кажется, что не намного, но аргументировать не смогу — глубоко не копал.
Другой аргумент в их пользу: до сих пор не было найдено (сгенерировано) ни одной пары документов с одновременно совпадающими md5 и sha1. (При чём сгенерировать пару проще, чем получить коллизию случайно)

А длина файла? Разве она вообще как-то влияет на шанс коллизии? Мне кажется тут имеет значение только количество файлов, но не их размер.
> Да, действительно пространство значений меньше чем 288 бит. Мне кажется, что не намного, но аргументировать не смогу — глубоко не копал.

Меня, как математика сильно смущает, что в нашем споре куча переменных, влияющих на порядок вычислений. А ещё — куча зрителей, ничего в этом не понимающих.

> А длина файла? Разве она вообще как-то влияет на шанс коллизии? Мне кажется тут имеет значение только количество файлов, но не их размер.

Ну, например, какой может быть шанс коллизии на файле в один байт?
> Меня, как математика сильно смущает, что в нашем споре куча переменных, влияющих на порядок вычислений. А ещё — куча зрителей, ничего в этом не понимающих.

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

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

> Можно ещё ухудшить ситуацию, если взять видеохостинг каких-то определёных рипов, нампример, только HDRip
Формат видео-то тут причём? Разве что заголовки будут немного совпадать, но хэши двух разных HDRip фильмов не будут иметь ничего общего, тем более что есть лавинный эффект.
Просветите же нас, как влияет длина файла на хеш этого файла?
О, сарказм невежды!
Так просветите, действительно интересно )
UFO just landed and posted this here
Ну наверное имелся ввиду не хеш файла а «хешики» кусков или точнее будет даже «кусочков файла».

Конечно то что в файле есть коллизии не значит что полный хеш будет идентичен с другим файлом в котором так же есть коллизии. Ой как не значит :)
Это все конечно очень правильно, но хотелось бы услышать ваш метод для проверки идентичности видеофайлов.
О! Вы меня нанимаете? :)
О! Вы просто болтаете? :)
Нет, просто потерял интерес к теме.

Вообще, в который раз ругаю себя за то, что ввязался в дискуссию. В этой теме у меня, конечно, есть пара воспитанных собеседников. Но, в основном, после каждого раза, чувствуешь себя как говном облитый. И, самое противное, хочется пойти в комментарии и тоже облить кого-нибудь говном.
>Интересно, какие теперь можно использовать способы для проверки идентичности файлов?
SHA-1, например. в приведенных в статье примерах совпадает только MD5, a CRC32 и SHA-1 отличаются.
Я сталкивался с ситуацией, когда crc32 выдавал одинаковый хэш. Не с файлами, но всё же.
CRC32 никогда не был криптографически стоек, для получения необходимого хеша нужно изменить значения всего лишь 4 байтов, значения которых вычисляются за то же время, что и хеш (т.е. линейное).
UFO just landed and posted this here
Поэтому нужно сравнивать сразу несколько хешей, SHA-1 и MD5, например. Подобрать данные, дающие коллизию по нескольким разным алгоритмам, на несколько порядков сложнее.
UFO just landed and posted this here
UFO just landed and posted this here
к счастью свет не сошелся клином на md5
Есть sha1, sha256,…
Есть Whirpool еще, по которому я так и не увидел ни одной годной статьи на Хабре. Если кто сможет дать линки — буду благодарен.
UFO just landed and posted this here
Не забывайте, что тут можно найти пару блоков, для которых будет коллизия.

То есть если уже есть «хороший» файл, то создать «плохой» файл с тем же хэшем гораздо сложнее.

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

Задумался… Большое спасибо за статью!
Openvpn по умолчанию использует TLS и SHA1.
Не, я имел в виду именно PPP. Там два вида аутентификации: PAP, который почти не используется, и CHAP. CHAP использует MD5.
А как же 128-битный MSCHAPv2?
Он не всеми железками подджерживается.
В вашей статье не хватает вывода, ответа на вопрос: «Так что теперь делать?»
Использовать MD6 или SHA1
И виной тому служит следующая особенность работы любой хеш функции: Хеш функция по своей природе итеративна.

Они точно не обладают теми же недостатками, но с другими условиями ?; )
И для них нужно изобретать свой алгоритм поиска коллизий. А MD6 ещё и сильно сложнее пятой версии.
UFO just landed and posted this here
А теперь то же самое, но проще: проверяем имя исполняемого файла и простым условием:
— если good.exe -> вывод good, если evil.exe -> вывод 'bad code'. Хэш ведь считается без учета имени файла :)
ну то есть вы всерьёз считаете, что человек, сумевший так хорошо замаскировать свой зловред под нечто безобидное — не догадается и название файла выставить идентичное?
Речь не о маскировке зловреда, а о том, что в данном примере программа могла проверять argv[0] и выводить разные сообщения от имени файла.

При этом md5, sha1, crc, да и вообще файлы побитово совпадали, а результат при запуске разный.

Это совсем по теме статьи, но забавная идея.
Был бы хороший хабраприкол. Сколько было бы негодования в комментах, пока кто-нибудь не догадался бы переименовать.
Эта забавная идея давно и успешно, и, главное, с пользой для дела, используется в униксах. Где может быть один бинарник (или скрипт) и кучка разных симлинков на него. В зависимости от имени единственный бинарник выполняет разные операции (из схожей серии).
А, во, простейший пример:
lrwxrwxrwx 1 root root 5 Дек 4 02:05 bunzip2 -> bzip2
lrwxrwxrwx 1 root root 5 Дек 4 02:05 bzcat -> bzip2
-rwxr-xr-x 1 root root 35224 Дек 4 02:05 bzip2
А как это будет работать на реальный примерах с размером кода хотя бы на порядок больше?
Кстати, заподозрить неладное можно уже при открытии архива:


что в принципе неудивительно — код-то разный.

Ну и кроме того, как правильно сказали — есть другие хеши:
evil.exe:
CRC32: B5917900
MD5: ECEA96A6FEA9A1744ADCC9802AB7590D
SHA-1: BE3AEE5D2A99BC88233E331A653D14CA3EB722F8

good.exe:
CRC32: A71D16A9
MD5: ECEA96A6FEA9A1744ADCC9802AB7590D
SHA-1: BE1DF26F1245278611739F49F610DCFF677FBEC2

Хе-хе, а есть еще такая же штука, но для crc32, только она много проще. Я когда программы правил, и у них сверка контрольных сумм шла, а мне было лень ее искать, я брал и правил crc32. Там нужно править было всего 4 байта.
s/argv[0] == 'evil.exe'/strcmp(argv[0], «evil.exe») == 0/, я, увидя заметку в RSS, сначала подумал об этом же :)
Немного не в тему: а нет рекомендаций каких-нибудь в виде «поменяй пару байтиков и получится 'красивая' контрольная сумма»? Просто интересно, такое еще не придумывали?
Навряд ли, то о чем вы говорите это скорее похоже на нахождение прообраза для заданного хеша. А такая задача на сегодняшний день пока решается только методом грубой силой.
UFO just landed and posted this here
Ха, не знаю, наверное, просто еще все не настолько плохо:)
Sign up to leave a comment.

Articles