Ответ 1
Revisited, август 2014
Подтвержденный Арно Бушезом в недавнем комментарии, и с учетом других ответов и комментариев, я подтверждаю, что исходный ответ должен быть изменен или наименее квалифицирован. Я оставил оригинал как есть, в конце, для справки.
Во-первых, и, возможно, самое важное, справедливый ответ на вопрос зависит от предполагаемого использования хеш-кода: что означает "хороший" [хэш-функция...]? Где/как будет использоваться хеш? (например, это для хэширования относительно короткого входного ключа? Является ли он для целей индексирования/поиска, для создания дайджестов сообщений или для других целей? Сколько времени занимает желаемый хеш-код, все 32 бита [из CRC32 или их производных], больше бит, меньше... и т.д.
Вопросы OP требуют " быстрее хэш-функции общего назначения", поэтому основное внимание уделяется SPEED (что-то меньшее, чем интенсивность ЦП и/или что-то, что может использоваться параллельно обработка различной природы). Здесь мы можем отметить, что время вычисления самого хеш-кода часто является лишь частью проблемы в приложении хеша (например, если размер хеш-кода или его внутренних характеристик приводит к множеству столкновений, для которых требуются дополнительные циклы с). Также требование "общего назначения" оставляет много вопросов относительно возможных применений.
С учетом этого, короткий и лучший ответ, возможно:
Да, аппаратные реализации CRC32C на более новых процессорах Intel могут использоваться для создания более быстрых хэш-кодов; однако, в зависимости от конкретной реализации хэша и его применения общие результаты могут быть неоптимальными из-за частоты столкновений, необходимости использования более длинных кодов. Кроме того, конечно, криптографическое использование хеша должно быть тщательно проверено, потому что сам алгоритм CRC32 очень слаб в этом отношении.
В исходном ответе была приведена статья об оценке функций хеширования Брет Малви и как указано в ответе Mdlg: вывод этой статьи ошибочен в отношении CRC32, поскольку реализация CRC32 была основана на был ошибочным/ошибочным. Несмотря на эту основную ошибку в отношении CRC32, статья дает полезные указания относительно свойств хэш-алгоритмов в целом. URL-адрес этой статьи теперь не функционирует; Я нашел его на archive.today, но я не знаю, есть ли у автора его в другом месте, а также обновил ли он его.
Другие ответы здесь цитируют CityHash 1.0 как пример хэш-библиотеки, использующей CRC32C. По-видимому, это используется в контексте некоторых более длинных (более 32 бит) хэш-кодов, но не для самой функции CityHash32(). Кроме того, использование CRC32 по функциям City Hash относительно невелико, по сравнению со всеми смещениями и перетасовкой и другими операциями, которые выполняются для создания хеш-кода. (Это не критика CityHash, для которой у меня нет практического опыта. Я пойду на конечность, из поверхностного обзора исходного кода, который функции CityHash дают хорошие, например, распределенные коды, но не значительно быстрее чем другие другие хэш-функции.)
Наконец, вы также можете найти представление по этому вопросу в квазидвуклевом вопросе о SO.
Оригинальный ответ и редактирование (апрель 2010 г.)
Априори, это звучит как плохая идея!.
CRC32 не был разработан для целей хэширования, и его распространение, вероятно, не будет однородным, поэтому делает его относительно слабым хэш-кодом. Кроме того, его "скремблирующая" мощность относительно слабая, что делает очень слабый односторонний хеш, как это будет использоваться в криптографических приложениях.
[BRB: Я ищу онлайн-ссылки на этот эффект...]
Google первый [ключевые слова = распределение CRC32], похоже, подтверждает это:
Оценка CRC32 для хэш-таблиц
Изменить: приведенная выше страница, и действительно полная статья обеспечивает хорошую основу для что искать в хэш-функциях.
Чтение [быстро] этой статьи, подтвердило выражение о бланке, что в общем случае CRC32 не следует использовать как хеш, однако, и в зависимости от конкретной цели хеша, возможно, будет возможно использовать, по крайней мере частично, CRC32 как хэш-код.
Например, нижняя (или более высокая, в зависимости от реализации) 16 бит кода CRC32 имеют относительно равномерное распределение и при условии, что их не интересуют криптографические свойства хэш-кода (то есть, например, факт что аналогичные ключи генерируют очень похожие коды), может быть возможно построить хеш-код, который использует, например, конкатенацию младших [или более высоких] 16 бит для двух кодов CRC32, созданных с двумя половинами (или любым делением) оригинальный ключ.
Нужно было бы запустить тесты, чтобы убедиться, что эффективность встроенной команды CRC32 относительно альтернативных хеш-функций будет такова, что накладные расходы на вызов команды дважды и объединение кода вместе и т.д. Не приведет к общая медленная функция.