[holywar] CRC, MD5
Не свалено, а собрано. Это бывает иногда очень удобно. Один из ярких примеров - miranda-IM.
---
...Я работаю антинаучным аферистом...
Чтобы выла возможность генерить MD5-суммы. Зачем искать какой-то скрытый смысл?
обязательно запихивать последнюю куда-то вторым номером в
подсчёт CRC.
---
Q21: что такое Win2k?
A21: состема.
дальше что? я знаю о возможности генерить md5 с помощью других утилит. Но чем TC тебя так не устраивает, что ты прям из кожи вот лезешь, чтобы смешать его с дерьмом?
При нынешних-то объёмах данных (читай --- дисков).
Но ТС даже в этом смог смешать всё в одну кучу.
Сможешь объяснить, почему были объединены CRC и MD5,
причём первым номером чётко выделена CRC, а вторым --- MD5?
Где эргономичность?
Где логичность?
Про кучу ошибок (не верю я, что со всеми справились) умолчу.
---
Q21: что такое Win2k?
A21: состема.
Сможешь объяснить, почему были объединены CRC и MD5,Не имею понятия =) файл с языковыми строками не я создавал. Согласен, CRC и md5 не одно и тоже, однако цель их - одна. Так что если бы не "некорректное" название пункта меню, то логичность вполне соблюдена.
причём первым номером чётко выделена CRC, а вторым --- MD5?
Где эргономичность?
Где логичность?
Что касается двухпанельности - tastes' differ.
Про кучу ошибок (не верю я, что со всеми справились) умолчу.Приведи хоть один.
Оконечному пользователю вообще не надо ничего знать о CRC.
Её можно использовать только не для таких больших объёмов данных.
Её, может так оказаться, вообще не имеет смысла использовать на таких быстрых машинах.
В наш век торжества автодополнения заставлять пользователя
бегать по панелькам --- мрак.
Тем более, когда пользователь и на одной панельке не может
отыскать то, что ему нужно.
Этот ТС падал с завидным постоянством.
core dumped.
А "плагинность" ничего хорошего ему не добавляет.
Её можно смело записывать в очень большие недостатки.
---
...Я работаю антинаучным аферистом...
в общем, это holywar. тебе (да и мне тоже) доказывать что-то не имеет смысла.
чем тебе плагинность то не нравиться?
без какой-либо "песочницы."
А плагины часто оказываются кривыми.
А без них, нередко выясняется, "не житьё."
И так далее со всеми вытекающими.
---
...Я работаю...
"Назвался груздем."
---
...Я работаю антинаучным аферистом...
так не ставь кривые плагины, имхо плагины для особых выкрутасов... где это например без них не житьё?
---
Q21: что такое Win2k?
A21: состема.
а где ты о них слышал?
Я войну тебе не объявлял. Это ты сделал. Вот и давай, доказывай.
В наш век торжества автодополнения заставлять пользователя бегать по панелькам --- мрак.Там есть Quick search (current dir)... или ты что имеешь ввиду?
А какие существуют достойные альтернативы ТС?
А плагины весьма неплохие есть: task manager и linux-drive -- например...
Назначение CRC и MD5 очень разное.назначение одно: подсчитать уникальную контрольную сумму. а CRC и MD5 это разные алгоритмы, которые в конечном итоге делают почти одно и тоже, с точки зрения конечного пользователя: считают и проверяют контрольные суммы.
поэтому логично их отнести в одно место.
назначение одно: подсчитать уникальную контрольную сумму.Разве у CRC уникальная сумма?
Иначе получили бы архиватор, который сжимал бы любой файл.
Нет, конечно. И у MD5 - не уникальная.У md5 она более псевдоуникальная. Пока нет возможности составить данные с такой же суммой. Насколько мне известно, в случае CRC можно.
с большой вероятностью, в данном случае, когда считается контрольная сумма для нескольких десятков файлов она, будет уникальной.
конечно MD5 будет лучше, но в локальном рассмотрении они достаточно эквивалентны.
Я к тому, что данные с такой же CRC суммой можно составить, а вот с MD5 пока нельзя. Если я не ошибаюсь.
необратимость - более сильное свойство, чем обнаружение ошибок передачи
crc обнаруживает случайные ошибки
md5 защищает от злоумышленной модификации (должно защищать, недавно опубликовали атаки, которые в некоторых случаях позволяют это ломать)
Насколько я помню: смысл CRC в проверке целостности данных, а смысл mp5 в проверке подлинности.
грамотно подобранная CRC достаточной длинны будет являться весьма уникальным кодом.
конечно этот алгоритм криптографически не стоек.
но напомню ситуацию. есть некая программа которая умеет считать контрольные суммы двумя способами. эти пункты находятся в одном месте.
тут обсуждается именно логичность размещения в одном месте CRC и MD5, а не их стойкость и надежность.
с точки зрения пользователя это примерно одно и то же.
А чем различаются алгоритмы я знаю.
А тогда их не должно быть видно вообще.
Почему бы тогда не использовать простую сумму с дополнением до двух?
Она ведь считается ещё быстрее, чем CRC.
Ещё раз: CRC --- для защиты от случайного искажения данных,
а MD5 --- для защиты от вероятного злонамеренного искажения данных.
---
"Студенту надо повторять всё три раза, Ганс. Три раза. Запомни, Ганс: три раза."
есть два способа предлагаемых этим Коммандером.
логично что они в одном меню.
использование CRC вместо MD5 и наоборот надо объяснять тем кто использует, а, надо заметить, используют не только пользователи "этого Коммандера", но многие-многие другие.
Никогда.
---
"Студенту надо повторять всё три раза, Ганс. Три раза. Запомни, Ганс: три раза."
А ты не задумывался над тем, что CRC - это уже устоявшийся термин, эквивалентный термину checksum? Соответсвенно считать CRC можно как непосредственно через эти самые полиномы, так и через мд5. Разница-то?
Пользователю никогда не потребуется подсчитывать CRC.вот тут ты сильно ошибся.
Никогда.
сейчас очень модно (может и не только сейчас) сопровождать файловый архив с файликом .sfv
Simple FIle Verification
так вот там как раз используется алгоритм CRC.
а используется он именно из-за своей меньшей ресурсоемкости.
Сейчас этого уже не требуется.
---
...Я работаю антинаучным аферистом...
Чувак, если ТЫ чего-то не используешь, это не значит что этого НИКТО не использует.
Это было модно во времена модемов.гон. хорошее подтверждение
Сейчас этого уже не требуется.
я по твоему ДВД по модему выкачиваю?
CRC используется не там, где можно терять время.
Думаю, если бы кто-то сделал такой переход,
ты бы сам не обрадовался.
Тормоза в работе накопителей не очень-то нужны.
А контрольные суммы менее надёжны.
---
...Я работаю антинаучным аферистом...
Чтобы убедиться, что оно полностью скачалось?
---
...Я работаю антинаучным аферистом...
и, главное, правильно.
Чтобы убедиться, что оно полностью скачалось?именно! когда у тебя есть файловый архив на несколько теров в котором происходит постоянная замена/обновление по неустойчивым каналам связи (АКА интернет то такой способ наиболее действенный...
и программами, это самое оборудование обслуживающими.
А они вместе подсчитывают ту же CRC много раз при передаче
каждого отдельного куска.
Поэтому правильность передачи пользователю проверять нафиг не надо.
Тем более, что это только средство успокоения.
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
CRC специально разработано для определения ошибок. Оно тебе гарантирует, что некоторое количество ошибок определенного вида _обязательно_ поймается. Мд5 - это все-таки немножко не то. Оно НЕ гарантирует, что изменение одного бита в исходном слове даст другой хэш. Может и дать, правда, поскольку хэшей довольно много, вероятность такой фигни весьма невелика.
Да, я правильно понял, что юзеру контрольные суммы вообще нафиг не нужны (ни мд5, ни црц поскольку проверка правильности передачи зашита в протокол? Гы гы гы, а че ты тогда тут вообще споришь о чем-то....
RTFM стек протоколов TCP/IP.и там где-то в глубинах RFC написано, что если в австралии порвали кабель, то на китайском ФТП все недокаченные файлы будут помечены как недокаченные и будут сопровождаться пояснительной запиской и телефон тех.поддержки австралийских провайдеров?
А MD5 используется совсем не для того, чтобы проверять правильность передачи.
---
...Я работаю антинаучным аферистом...
передаются в неискажённом виде.
---
...Я работаю антинаучным аферистом...
может у меня ФТП сервер неправильно инфу из файлов выдирает? а может в промежутке стоит правильный НАТ-роутер который меняет заголовки, а следовательно ПАКЕТ? а может у меня винт битый и на него файл записывается с ошибкой? это все гарантируется протоколом TCP/IP ? да я кстати иногда игрушки на винте приношу... без передачи по сети...
Если у тебя FTP-сервер файлы корёжит, то это не FTP-сервер.
Если у тебя накопитель битый, то это отслеживается контроллером
и системным ПО, ты как пользователь стоишь в сторонке и никак не
можешь на это повлиять.
А контроллер, кстати, тебе при чтении или записи на побитом
месте скажет: "CRC error!"
И ты всё равно --- стоишь в сторонке и никак не можешь заставить
этот контроллер не считать CRC.
---
...Я работаю антинаучным аферистом...
Короче, мало того что Настоящие Программисты пишут программы без ошибок (теоретически так еще и вся передача данных тоже происходит без ошибок. Теоретически. Hail Satan.
Там в глубинах RFC написано, что уже на уровне IP пакетыУ TCP и UDP очень слабые контрольные суммы. Обычно спасают контрольные суммы транспортного уровня. Но всё равно, как было замечено, рядом с файлами на ftp серверах лежат контрольные суммы.
передаются в неискажённом виде.
Если у тебя неправильно работает ОС, то её надо сразу
выбрасывать в топку. Потому что от случайных искажений любых
расчётов ты не защитишься.
Так что твои дёрганья, подсчёт CRC, MD5, SHA-1 и чего угодно,
никак не помогут.
Разве что ещё раз напомнят о глючности системы.
Возьми, загляни в /usr/ports и подумай, зачем нужен подсчёт MD5.
Справка для особо ленивых: подсчёт MD5 производится уже после
того, как файл закачен целиком и в целостном виде
(иначе фиг он разтарился).
---
...Я работаю антинаучным аферистом...
От битой памяти в роутере не спасает ни то, ни другое.
Сетевая карта получателя отбросит битый роутером кадр.
При обработке испортится несколько бит, потом на них нормальные контрольные суммы привесят.
Файлы передаются, по-твоему, как?на компактдиске, а что?
Если у тебя FTP-сервер файлы корёжит, то это не FTP-сервер.ну конечно он же написан без ошибок.... и
пример безошибочного ПО, например Winrar 3.11 (это просто как пример)
Если у тебя накопитель битый, то это отслеживается контроллеромв большинстве случаев...
И ты всё равно --- стоишь в сторонке и никак не можешь заставитьа мне этого и не надо...
этот контроллер не считать CRC.
просто я запустил скачиваться 100 файлов, а пять из них не скачались, потому что в австралии перегружали роутер, сервер-источник не смог прочитать один из файлов, клиент приемник не смог записать из-за пятен на солнце.
и когда я после выходных пришел на работу - я хочу узнать какие из фалов скачались неправильно. и запускаю прекрасную утиль cksfv.
и что самое главное, она не знает о стэке TCP/IP и о том что файлы переносятся не только по IP-сетям, но еще и по IPX, и даже на CD а иногда бывает что и по компорту передаются с протоколами такого низкого уровня, которые и не снились автору программы cksfv.
и что самое интересное, .sfv используется... конечно теперь я знаю, что передача данных абсолютно безошибочна и никогда не буду считать контрольные суммы, даже МД5, ведь передача абсолютна.
я правильно понял твою мысль?
Значит --- не докачал.
И считать сумм не надо.
Смотришь, который "wget -c" не закончил работать или сообщил,
что файл не закачал. Всё.
Никаких сумм!
---
...Я работаю антинаучным аферистом...
А мне вот интересно - если скачать файло с фтп в ACSII вместо binary - его размер изменится?
а не извращаться неизвестно с чем.
---
...Я работаю антинаучным аферистом...
Если только не начали ставить серверы на Макинтошах.
---
...Я работаю антинаучным аферистом...
Проверяешь длину файла и узнаёшь, что меньше.ты абсолютно прав.
Значит --- не докачал.
сиди и делай это для 100 файлов.
а потом еще для 100. а если удаленный ФТП предоставляет тебе доступ только по предварительным запросам, то конечно размеры файлов (оригинала и того что есть) будут написаны в специальном файле file_sizes.txt
и кермит тебе конечно же тоже скажет после приема 100 файлов: "пять файлов не докачалось - вот их названия".
И считать сумм не надо.нет, надо руками сравнить кол-во и длины файлов, получив при этом доступ к оригиналу... какие мелочи...
А ещё его можно попросить вообще не останавливаться, пока не закачает.
Вообще, сейчас ты уже оправдываешь своё неумение работать на компьютере.
---
...Я работаю антинаучным аферистом...
wget сообщает о своих неудачах.есть много мест в которых wget не работает, точнее неприменим.
А ещё его можно попросить вообще не останавливаться, пока не закачает.
Вообще, сейчас ты уже оправдываешь своё неумение работать на компьютере.все понятно.... то что тот тот способ о котором я рассказываю используют слишком многие, которые не придумали другого ни о чем не говорит...
просто ты не понимаешь где это можно применить, видимо из-за недостатка знаний...
И ещё доказательства отсутствия таких возможностей в наиболее
ходовых средствах с открытым кодом.
Эти многие тоже могут легко убедиться в том, что файл не докачан
до конца, просто посмотрев на картинку в каком-нибудь ReGet.
---
...Я работаю антинаучным аферистом...
Хо-хо. Я не знаю как у вгета, а у разных даунлоадеров под винду как правило есть мега-опция "резервировать место под файл заранее". Очень полезная опция. Но может привести к разным интересным последствиям. Более того, у меня есть некое подозрение, что даже с выключенной такой опцией если в процессе записи файла комп внезапно перезагрузиццо, то в конце файла могут оказаться нолики. Причем ты сам, конечно, можешь никогда не использовать внезапно перезагружающиеся оси, ненадежные даунлоадеры етс., но заставить так поступать всех тех людей, через которых к тебе шел образ какого-нить диска, порипанного трудолюбивым китайским рабочим Сяо Ляо Вей, ты не можешь. Зато этот трудолюбивый китайский рабочий как правило приаттачивает к файлецу контрольную сумму, и передавать эту контрольную сумму дальше считается хорошим тоном. Вот.
Контрольную сумму лучше считать CRC чем MD5, потому что а) быстрее, б) устойчивее к _ненамеренным_ искажениям данных.
10000 FTP серверов
100 000 пользователей
в 1000 стран по всему миру
фильмообменная сеть.
Эти многие тоже могут легко убедиться в том, что файл не докачана ты кроме клиентского ПО что-нибудь видел?
до конца, просто посмотрев на картинку в каком-нибудь ReGet.
сделай нормальный файлообмен с достаточной степенью надежности и более или мене автоматизированный...
Недавно пытался доказать что Жава активно используется, на ней прогают, очень много програм етс.
Щаз вот доказываю что контрольные суммы все-таки нужны.
Нахуй-нахуй!
Хотя бы из-за того, что там написано, что происходило.
Не, я понимаю, что в варезных случаях файлы часто пропадают до
того, как их успеваешь скачать, но запустить wget ещё раз, чтобы
проверить, всё ли докачалось до перезагрузки (в случае, если
очень сильно сомневаешься--- невелика трудность.
А варез не надо использовать.
Хотя бы из-за вирусов и троянов.
Тут, пожалуй, единственное место, где могла бы оказаться
полезной MD5, только смысл. При взломе файл всё равно меняется.
CRC менее устойчива к любым искажениям данных.
Иначе не было бы смысла в MD5.
Кроме того, есть атака на написание большого количества пробелов
в конце текста.
(Кстати, забыл, как к ней относится MD5. Вопрос к -у.)
---
...Я работаю антинаучным аферистом...
Где доказательства отсутствия возможности записи в журнал о
получении (или неполучении) файла?
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
Где доказательства отсутствия возможности записи в журнал оиди и научи это те 100 000 пользователей.
получении (или неполучении) файла?
а потом посади еще 50 000 которые будут просматривать журнал. и конечно еще надо посадлить тысяч 10 которые будут все фалйы проверять на неискаженность.
а где доказательство того что анализ журнала быстрее и удобнее анализа CRC ?
кто-то путает per-hop и end-to-end мне кажется
количеством полученного: "100%."
И никаких гвоздей.
То есть, заморочка с внешним подсчётом MD5 --- это твоё личное
изобретение.
---
...Я работаю антинаучным аферистом...
Щаз вот доказываю что контрольные суммы все-таки нужны.Самый банальный случай, когда они нужны: запоротая болванка или сбойный сектор.
почему это? подсчет CRC присутсвует на всех промежуточных точках... в чем отличие per-hop от end-to-end в данном случае?
То есть, заморочка с внешним подсчётом MD5 --- это твоё личноегон! преимущества CRC перед МД5 одно - на порядок или более высокая скорость счета.
изобретение.
НО! ты утверждаешь что контрольные суммы не нужны ни в каком виде, а не то что вместо CRC надо использовать MD5. по крайне мере именно это я уловил из твоих постов.
каждый пират по пути анализирует логи и т.д. - это per-hop
одно другого не заменяет
мало того. он используется и там и там.
Кроме того, восстановление битого носителя --- это не очень-то
пользовательское дело.
---
...Я работаю антинаучным аферистом...
Не пользовательское это дело --- суммы подсчитывать.
И даже в случае возникновения у пользователя такой потребности,
подсчитывать суммы, CRC --- нафиг не нужна.
---
...Я работаю антинаучным аферистом...
конечно это пользовательское дело.
давай упомянем так нелюбимый тобой варез.
если смотреть с точки зрения что это не дол пользователя, то он бедный вообще должен олько покупать лицензионный софт, ничего не качать из инета, никогда не переносить файлы в громадных объемах.
а уж что говорить об ученых, которые гоняют терабайты информации и хотят быть более или менее уверенными в неискаженности оной. нехай! пусть статьями в журналах обмениваются.
Пользователь волен использовать свободное ПО
или не использовать его.
Точно так же, как волен соблюдать законы или не соблюдать их.
---
...Я работаю антинаучным аферистом...
Он не будет битый.Не понял тебя. А что тогда:
При обработке испортится несколько бит, потом на них нормальные контрольные суммы привесят.
160 input errors, 5 CRC, 0 frame, 0 overrun, 0 ignored
CRC специально разработано для определения ошибок. Оно тебе гарантирует, что некоторое количество ошибок определенного вида _обязательно_ поймается. Мд5 - это все-таки немножко не то. Оно НЕ гарантирует, что изменение одного бита в исходном слове даст другой хэш.Люди, кто разбирался в математических аспектах MD5, можете сказать, насколько это высказывание верно?
Лошок
1) роутер принимает нормальный пакет, записывает в память
2) некоторая обработка
3) пакет достаётся из памяти, контрольная сумма пересчитывается с новым заголовком, пакет отправляется
при работе с памятью несколько бит портятся, и сумма считается уже с неправильных данных
P.S. не надо только говорить, что правильно считать TCP и UDP-суммы инкрементально, видимо, не все роутеры так делают
маза информация может на любом этапе передачи попротиться, нужно еще учитывать вероятность этого события на каждом из этих этапов
Я к тому, что данные с такой же CRC суммой можно составить, а вот с MD5 пока нельзя. Если я не ошибаюсь.если не ошибаюсь, намеренно составить можно, но это требует больших машинных затрат
кстати, пересечения МД5 сумм для разных последовательностей одинаковой длины неоднократно обнаруживались (случайно)
ЦРЦ отличается на порядок более простым алгоритмом вычисления и вероятность пересечения для разных последовательностей оценивают как 1/2^32
МД5, соответственно более дорогое вычисление, но вероятность пересечения последовательностей одинаковой длины ~ 1/2^64, для разной длины ~ 1/2^128
кстати, CRC всех исошек от Microsoft = 0xFFFFFFFF
А я тебе говорю про то, что в данном случае спасают проверки транспортного уровня, например Ethernet.
А я тебе говорю про то, что в данном случае спасают проверки транспортного уровня, например Ethernet.туда попадет уже испорченный пакет.
и не спасет ничего, только проверки на конечных узлах или ECC на памяти
пишешь на диск одно, а читаешь с него уже другое
такое бывает почаще, чем глючные роутеры
Зашлите какой-нибудь такой файл.
Если не найдёте короткого, то оставьте от списка файлов первые и
последние три строки.
---
"Бди!"
Козьма Прутков
---
...Я работаю...
Ну да ладно.
Судя по всему, эти файлы создаются md5sum либо md5. Так?
---
"Бди!"
Козьма Прутков
Не от хорошей жизни начал
4fc9d6525aa83bc4cc32332b3b3ec020 */etc/DIR_COLORS
33001c1be36f6cbc6bf43386494e54c8 */etc/adjtime
a631879d96cfa58d640af4e5a9e133ee */etc/crontab
................................................
ccad3f7878ea7a1e078796419717c4b2 */etc/xinetd.conf
md5sum: /etc/xinetd.d: Is a directory
md5sum: /etc/xml: Is a directory
Тебя не смущает то, что выдача:
а) не кодирована по Хеммингу;
б) не содержит ни CRC, ни MD[245], ни SHA-1, ни PGP;
в) вообще не содержит никаких средств обнаружения
или исправления ошибок?
---
...Я работаю антинаучным аферистом...
Нет.
Как же ты будешь проверять, что у тебя суммы верно передались?
---
...Я работаю антинаучным аферистом...
Может, файл с данными.
А может, файл с суммами.
Так работают коды, обнаруживающие ошибки.
А какова вероятность, что кроме ошибки в 700 метровой исошке случится еще и ошибка в полукилобайтовом файлике, да так удачно (с что никто не заметит, а вот суммы начнут совпадать? Вот такого точно не бывает.
link, там есть ссылка на статью.
для нетерпеливых:
сравните md5sum от этих файлов, а потом сравните сами файлы. Расширение gif убрать.
,
$ md5sum file1 file2
79054025255fb1a26e4bc422aef54eb4 file1
79054025255fb1a26e4bc422aef54eb4 file2
$ cmp -l file1 file2
20 207 7
46 161 361
60 362 162
84 264 64
110 250 50
124 53 253
разряда так, чтобы это не было замечено при воспроизведении?
Не в этом дело.
У гзипов тоже есть свой формат.
И тоже, подозреваю, с какой-нибудь суммой внутри.
(Лень проверить. У таров -- точно есть.)
Почему в /usr/ports лежат суммы?
---
...Я работаю антинаучным аферистом...
Привести две абстракные последовательности байтов, дающие один и тот же хэш (вряд ли тобой найденные и почти наверняка случайно) - это не интересно, хотя в случае md5 даже это непросто.
А теперь задача для настоящего джидая, из-за которой, кстати, и существуют md5 и им подобные. Есть у тебя слева аватарка. MD5 мы от нее посчитаем - это не проблема. А с тебя требуется файлик, который дает такой же md5. Разумеется, даже этого недостаточно: нужно, чтобы этот файлик был корректным jpg-ом. Но на это требование можешь забить, ибо вряд ли справишься даже с первым.
З.Ы. Линк не работает. Говорит 503 Service Unavailable
Если линк не работает, соответственно статью ты не прочитал, то ты б лучше молчал бы. Честно. Потому что ты так неправ, как вообще мало кто неправ. Лови статью.
Чувака иногда, конечно, заносит. Но в целом более чем забавно. Особенно что, насколько я понял, у оригинальной тётенки Вонг, по мотивам которой данное исследование, есть мега-прога, которая может генерить дупликаты для мд5 с заданным seed, то есть вообще говоря ты можешь дописывать разные куски в _конец_ файла, получая одинаковые хэши.
Ну то есть общая тема статьи в том, что вроде как пока что эксплойтить эту дырку именно как дырку нереально (практически однако несколько забавных применений уже есть. Например, берешь мп3, прихуйачиваешь к ней в начало некоторое количество таких кусков, нагенерив их предварительно много. Мп3 играет нормально (формат мп3 вообще устойчив к ядерному взрыву, по моему зато ты можешь написать себе п2п клиента, который будет рассылать такие мп3шки, каждый раз присобачивая разные куски. Все варианты будут мд5-идентичны, а вот ты сможешь следить, куда потом идут эти мп3шки. А если напиздить прогу для присобачивания таких блоков в конец, то можно каждую копию своей проги так подписывать (незаметно и пиздец.
Заключение: неуязвимость мд5 существенно преувеличена, поэтому если кто-нить полагается на мд5 абсолютно, то он может очень забавно обломаться.
Кстати, ты даже не потрудился объяснить, в чем я неправ.
Может быть в том, что пары, дающие одинаковый хэш - это неинтересно? Но сообщения об их нахождении появились достаточно давно и ничего нового в этом нет.
Может быть в том, что Лео (как и почти никто) не сможет подобрать пару к уже известному массиву данных?
Резюме этой статьи в том, что конечный пользователь может получить облом, если _в начале_ цепочки стоял злоумышленник, который и является автором файла. Имея одну коллизию он может создавать произвольное число файлов, имеющих один и тот же хэш. Защищаться от автора сложно и не нужно: больше важно, чтобы я получил то, что мне предназначал автор. А зло он мне передать может независимо от того, есть уязвимость в хеше или нет (просто потому что он автор)
Здесь обсуждается возможность намаренного или случайного искажения данных при передаче, а в этом смысле данная статья не привносит ничего нового.
В общем, хорошо то, что нашли хоть какое-то применение парам с одинаковым хэшем. Безусловно, нужны новые технологии. Но говорить из-за, что md5 уже не надежен рано. Время еще есть.
---
...Я работаю антинаучным аферистом...
Оставить комментарий
Ivan8209
Тем хуже.Раз у вас всё (в частности, MD5 и CRC) свалено в кучу.
---
Q21: что такое Win2k?
A21: состема.