>> И то что колизии бывают - нормальный разработчик как бы в курсе..
> Просто намеренный гасеж коллизиями вообще-то не является штатным видом эксплуатации ФС.
> И есть большие сомнения что остальные существующие ФС кто-то хоть как-то
> изучал под таким углом вообще. Хотя если хочется поисходить на г-но
> - это круто, конечно, но тогда для справедливости придется полить им
> и кучу иного софта где эту проблему выловили и зачинили.
>> (достаточно подумать 255 байт ужимают до 32
> Вообще-то CRC32 - это 4 байта. Или 32 бита. Критиканить других с
> такими познаниями о криптографии - ну да, это круто.crc32 не является криптохэшем :-) видимо что бы это узнать нужны дикие познания?
а что брякнул до 32 - это было просто пояснение без привязки к конкретному алгоритму - так будет лучше?
>> кто-то заложился что таких колизий не много
> Это совершенно стандартное допущение для реализации хэш-таблиц. Ибо в абсолютно вырожденном
> случае хэш-таблица вырождается например в линейный список ("ничего кроме коллизий нет").
> Нормально? :)
формулировка нормальная - только с тем как используются хэш при построении файловых систем - вы не знакомы. Знакомы только с хэшированными списками - но есть и другие варианты - с другими болячками.
В случае ext3/4 - к примеру есть дерево хэшей в узлах которого расположены ссылки на имена имеющие одинаковых хэш. В этом случае поиск имени сначала ведется по частичному или полному хэшу от имени - дальше производится модификации блоков которые хранят информацию о именах с одинаковым результатом хэш функции. Вот тут то и приплыли - если колизий будет слишком много - затраты на модификацию этих блоков - могут быть очень и очень большими. (split, merge blocks - и создание дополнительных листьев в дерево). Сдается мне что в случае btrfs идет атака как раз на этот кусок - а улучшением хэш функции (как и увеличением размера хэша) - можно только усложнить подбор имен дающих колизию.
Нормально ? :-)
