Является ли triple-CRC-32 плохой (или нет) идеей для создания незащищенного хеша равномерного распределения?

Question

У меня есть входные данные 288 бит (включая 4 × 32-битные выходные данные функции идентичности и 10 × 16-битные целые числа). Мне нужно хэшировать это до 96 бит с как можно меньшим количеством коллизий. Цель может быть сформулирована как сжатие ключа с вероятностными столкновениями.

Я знаю, что CRC - это биективный хеш, что обеспечивает 100% равномерное распределение (насколько я понимаю). На мой взгляд, я должен быть в состоянии запустить 3 параллельных пути CRC через вход, что приведет к 96-битному хэшу с потерями (очевидно, не биективному) оптимального распределения.

Тем не менее, я также знаю, что CRC не используется для таких приложений. Такой алгоритм, как MetroHash, обычно используется.

Может ли кто-нибудь объяснить мне, почему CRC является плохой (или нет) идеей для этого приложения?

Примечание: это не предназначено для чего-либо безопасного.

Answer 1

Конечно, это может сработать, но, возможно, есть лучшие подходы.

Чтобы это работало, вам нужно использовать три разных CRC-32 с тремя разными полиномами. И даже тогда, будьте осторожны, чтобы они не имели общих факторов (например, x+1), чтобы убедиться, что между этими тремя нет коррелированных битов.

Лучше был бы подход, подобный используемому в xxhash, но расширенный до 96 бит. Это было бы быстрее в программном обеспечении.

Почему 96 бит? Это похоже на излишне длинный хеш.