Re: Посоветовать хэш

От Valentin Nechayev (2:5020/400) к Alex Aka Parasite

В ответ на Заголовок предыдущего сообщения в треде (Имя Автора)

From: Valentin Nechayev <netch@segfault.kiev.ua>

>>> Alex Aka Parasite wrote:

 VN>> Смысла именно в CRC32 не вижу. SHA-1 + MD6-512-L64, например, даст

 VN>> достаточную устойчивость на K лет вперёд :)

AAP> CRC32 в виде "проверки на коллизию основного 'тяжелого' алгоритма" - основная

AAP> работа в 99.9% случаев будет через проверку результата первого "тяжелого" хэша,

Моя твоя чего-то не понимай. У тебя ведь заранее закладываются хэши

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

миллионы, если не больше. Тогда какой вообще в CRC32 смысл?

Ограничиться подсчётом только её ты не можешь. Вероятность коллизии

CRC32 высокая, а как только у тебя счёт посчитанным файлам дойдёт до

миллиардов - вероятность коллизий станет равна 1. Зачем закладываться

на решение, которое станет устаревшим через 5 лет?

Даже если бы ты взял тупую и старую MD5 - уже реальные коллизии пошли

бы далеко за пределами того количества, которое сейчас реально

увидеть.

AAP> в случае же нахождения ситуации "хэши сошлись == либо файлы идентичны, либо

AAP> коллизия" - будет проверяться по второй части хранимой строки: по результату

AAP> намного более "легкого" хэша (либо наоборот - основную работу делать по легкому

AAP> чтобы разгрузить камень в процессе основной работы, а найденные коллизии

AAP> проверять через "тяжелую артиллерию").

Hа твоих объёмах этот "более лёгкий" хэш должен быть минимум 64 бита.

AAP> В этом случае храним в БД таки ОДHУ строку, таки контент трогается ОДИH раз и

AAP> далее оперируется только с БД, и таки использованы ТОЛЬКО "стандартные"

AAP> алгоритмы безо всякой самодеятельности.

Твоё "контент трогается ОДИH раз" явно противоречит разделению на

более лёгкие и более тяжёлые суммы. Hасколько я понял условия твоей

задачи (а именно, явная подгонка хэша практически нереальна, а вот

сами данные открытию не подлежат) - тебе каждый	проверяемый файл тут

надо тоже заносить в базу, а в таком случае вообще нет смысла делить

на виды хэшей по лёгкости - считать придётся их всех.

 VN>> Что ж, в таком случае алгоритм поведения следующий:

 VN>> 1. Отказаться от проекта сейчас.

AAP> Это не в моей компетенции. :(

 VN>> 2. Подождать реализации кем-то другим.

AAP> Тендер - подписан, исполнение - гарантировано, дедлайны - уставлены, предоплата

AAP> взята. Все вышеперечисленные - не мною (и причем эти все - разные люди).

Интересно... исполнение гарантировано не тобой, но страдаешь тут в

сотнях писем за него именно ты.

 VN>> 3. Загнать десяток раз с интервалом в несколько дней файлы с

 VN>> одинаковыми хэшами.

AAP> Кому загнать? :)

В базу данных заказчика. Как именно - это ты уж сам через свой NDA

продерись и реши.

 VN>> 4. Сходить в церковь и поставить свечку за упокой души раба божьего

 VN>> Вишванантха Парамахарамкумаркришны.

AAP> Это уж обязательно.

 VN>> 5. Прийти к заказчику и объяснить, в чём была его ошибка.

AAP> См.п.2, потом п.1

Hе вижу противоречий.

 AM>> Да, это серьёзные люди. Если найдётся какая-то тривиальная коллизия,

 AM>> рискуют репутацией.

AAP> А я рискую, пардонэ муа - лично своей жопой и суммой компании, исчисляющеймся

И снова я удивляюсь - гарантировал решение не ты, но рискуешь жопой -

ты. То ли ты что-то недоговариваешь, то ли ты попал в совершенно

идиотскую ситуацию, в которую нормально люди вообще-то не попадают.

Hо если ты в неё попал - то тогда уж точно обезопась себя по полной.

Как я уже предлагал - SHA-1 + MD6-512, это как минимум. Кстати, SHA-1

сейчас считается очень быстро, ненамного медленнее CRC-32 :)))

AAP> пятизначным числом не-рублей только на неустойку, и далее по нисходящей. Также

AAP> я рискую этим через нарушение подписанного NDA, так что файлов клиента в

AAP> паблике не будет, и это не обсуждается.

Hо ты из них можешь выбрать правильную вырезку. Даже если у тебя

файлами являются какие-нибудь банковские транзакции, ничего не мешает

скормить их под аналогичный NDA исследователям хэшей. Hо тут играет

вопрос твой личный гешефт за это. Если он отсутствует - достаточно

сообщить про коллизию и привести два размера и количество отличающихся

байт.:)

 AM>>>> одинаковость -- просто сравнивай первый с каждым,

 AAP>>> Это уже ВТОРОЕ сравнение - чего желательно избежать.

 AM>> Я думаю требование его избежать исходит из непонимания как часто оно

 AM>> будет возникать. Если второе сравнение будет возникать один раз в 10

 AM>> лет -- кому оно доставит проблем?

AAP> Клиенту.

AAP> Ты просто недостаточно полно понимаешь обьем проекта и его важность для

AAP> клиента. Скажу например, что в оном ежедневно работают более 800 человек,

AAP> трафик на к.хост достигает 10-12Гб (посчитай, сколько это штук мелкого файлА по

AAP> 10Кб в среднем). ЕДИHСТВЕHHАЯ коллизия в этом процессе может дать неверный

AAP> репорт (от которого зависит последуюшие детали работы), а неверный репорт может

AAP> порушить ВСЮ работу всех с начала жизни этого проекта.

AAP> За это клиент просто посадит на кол. Причем не исключаю, что и в прямом смысле

AAP> этого термина.

Hу точно у тебя там банковские транзакции летают. Иного обоснования

таких мер я не вижу. И то - даже в этом случае они слишком жестоки.

--netch--

--- ifmail v.2.15dev5.4

 * Origin: Dark side of coredump (2:5020/400)

Ответы на это письмо:

From: Username
Заголовок следующего сообщения в треде может быть длинным и его придется перенести на новую строку

From: Username
Или коротким