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

см. Также этой.

Я нашел исследование, которое показывает как неуместный хэши CRC предназначены для хэш-таблиц. Это также объясняет фактические характеристики алгоритма. исследование также включает в себя оценку других хэш-алгоритмов и является хорошей ссылкой для сохранения.

соответствующий вывод о CRC для хэшей:

CRC32 никогда не предназначался для использования хэш-таблицы. На самом деле нет никаких оснований использовать его для этой цели, и я рекомендую чтобы вы этого не делали. Если вы решите использовать CRC32, крайне важно использовать хеш-биты с конца, противоположного тому, в который подаются ключевые октеты. Какой конец это зависит от конкретной реализации CRC32. Не рассматривайте CRC32 как хэш-функцию "черного ящика" и не используйте его в качестве хэша общего назначения. Обязательно проверьте каждое его применение на пригодность.

обновление

кажется, сайт не работает. The интернет архив имеет копию хотя.

Я запустил каждую строку этого PHP-кода в цикле 1.000.000. Результаты в комментариях (#).

hash('crc32', 'The quick brown fox jumped over the lazy dog.');#  750ms   8 chars
hash('crc32b','The quick brown fox jumped over the lazy dog.');#  700ms   8 chars
hash('md5',   'The quick brown fox jumped over the lazy dog.');#  770ms  32 chars
hash('sha1',  'The quick brown fox jumped over the lazy dog.');#  880ms  40 chars
hash('sha256','The quick brown fox jumped over the lazy dog.');# 1490ms  64 chars
hash('sha384','The quick brown fox jumped over the lazy dog.');# 1830ms  96 chars
hash('sha512','The quick brown fox jumped over the lazy dog.');# 1870ms 128 chars

мои выводы:

• используйте "crc32b", когда вам нужноhttp://en.wikipedia.org/wiki/Cyclic_redundancy_check и тебя не волнует безопасность.

• используйте "sha256" (или выше), когда вам нужен дополнительный уровень безопасности.

• Не используйте " md5 "или" sha1", потому что у них есть:

  1. безопасность проблемы, когда вы заботитесь о безопасности
  2. более длинная строка хэша и медленнее, чем" crc32b", когда все, что вам нужно, это CRC

для информации CRC о реализации, скорости и надежности см. безболезненное руководство по алгоритмам обнаружения ошибок CRC. У него есть все на CRCs.

Если кто-то не собирается пытаться изменить ваши данные злонамеренно и скрыть изменение CRC достаточно. Просто используйте "хороший" (стандартный) полиномиал.

вы не говорите, что именно вы пытаетесь защитить.

CRC часто используется во встроенных системах в качестве проверки от случайного повреждения данных, а не предотвращения вредоносной модификации системы. Примеры мест, где CRC может быть полезен, - это проверка образа EPROM во время инициализации системы для защиты от повреждения прошивки. Системный загрузчик вычислит CRC для кода приложения и сравните с сохраненным значением, прежде чем разрешить код для запуска. Это защищает от возможности случайного повреждения программы или неудачной загрузки.

CRC также может использоваться аналогичным образом для защиты данных конфигурации, хранящихся во FLASH или EEPROM. Если CRC неверен, то данные могут быть помечены как недопустимые и используется набор данных по умолчанию или резервного копирования. CRC может быть недействительным из-за сбоя устройства или если пользователь удалил питание во время обновления хранилища данных конфигурации.

были комментарии что хэш обеспечивает большую вероятность обнаружения повреждения, чем CRC с несколькими битными ошибками. Это верно, и решение о том, следует ли использовать 16 или 32-битный CRC, будет зависеть от последствий безопасности используемого поврежденного блока данных и можно ли оправдать вероятность 1 в 2^16 или 2^32 неправильного объявления блока данных действительным.

многие устройства имеют встроенный генератор CRC для стандартных алгоритмов. Серия MSP430F5X из Техаса оборудование осуществление стандарта CRC-CCITT.

CRC32 быстрее, и хэш составляет всего 32 бит.

используйте его, когда вам просто нужна быстрая и легкая контрольная сумма. CRC используется в ethernet.

Если вам нужна большая надежность, предпочтительнее использовать современную функцию хэширования.

используйте только CRC, если вычислительные ресурсы очень жесткие (т. е. некоторые среды встраивания) или вам нужно хранить/транспортировать много выходных значений, а пространство/пропускная способность жесткая (поскольку CRC обычно 32-разрядные, где выход MD5 128-бит, SHA1 160 бит и другие варианты SHA до 512 бит).

никогда не используйте CRC для проверок безопасности, поскольку CRC очень легко "подделать".

даже для случайного обнаружения ошибок (а не обнаружения вредоносных изменений) хэши лучше, чем простой КПР. Частично из-за простого способа вычисления CRC (и частично потому, что значения CRC обычно короче, чем общие хэш-выходы, поэтому имеют гораздо меньший диапазон возможных значений) гораздо более вероятно, что в ситуации, когда есть две или более ошибок, одна ошибка будет маскировать другую, так что вы в конечном итоге с тем же CRC, несмотря на две ошибки.

короче: если у вас есть основания не чтобы использовать достойный алгоритм хэша, избегайте простых CRCs.

CRC32 намного быстрее и иногда имеет аппаратную поддержку (т. е. на процессорах Nehalem). Действительно, единственный раз, когда вы используете его, - это если вы взаимодействуете с оборудованием или если вы действительно плотно на производительность

недавно я столкнулся с использованием CRC, который был умным. Автор jdupe инструмент идентификации и удаления дублирования файлов (тот же автор популярного инструмента exif jhead) использует его во время первого прохода через файлы. CRC вычисляется на первых 32K каждого файла, чтобы отметить файлы, которые кажутся одинаковыми, также файлы должны иметь одинаковый размер. Эти файлы добавляются в список файлов, на которых необходимо выполнить полное бинарное сравнение. Он ускоряет проверку больших мультимедийный файл.

все зависит от ваших требований и ожиданий.

вот быстрые краткие различия между этими хэш-функция алгоритмы:

CRC (CRC-8/16/32/64)

• и не криптографический алгоритм хеширования (он использует линейную функцию, основанную на циклических проверках избыточности)
• смогите произвести или 9, 17, 33 или 65 битов
• не предназначен для использования в криптографии цели с тех пор не дает никаких криптографических гарантий,
• неподобающе для пользы в цифровых подписях, потому что оно легко реверзибельно²⁰⁰⁶,
• не следует использовать в целях шифрования,
• различные строки могут генерировать столкновение,
• изобретен в 1961 году и используется в Ethernet и многих других стандартах,

MD5 в

• является криптографическим хэшем алгоритм,
• создание 128-битного (16-байтового) хэш-значения (32-разрядные шестнадцатеричные числа)
• это криптографический хэш, но является устаревшим, если вы беспокоитесь о безопасности
• есть известные строки, которые имеют то же значение хэша MD5
• может использоваться для целей шифрования,

SHA-1

• является криптографическим хэш-алгоритмом,
• производит 160 бит (20 байт) хэш-значение, известное как дайджест сообщения
• это криптографический хэш и с 2005 года больше не считается безопасным,
• может использоваться для целей шифрования,
• найден пример столкновения sha1
• впервые опубликовано в 1993 году (как SHA-0), затем 1995 как SHA-1,

• серия: ша-0, ша-1, ша-2, ша-3,

  В общем, использование SHA-1 больше не считается безопасным против хорошо финансируемых противников, потому что в 2005 году криптоаналитики обнаружили атаки на SHA-1, что предполагает, что он может быть недостаточно безопасным для постоянного использования^Шнайер. NIST США советуют, что федеральные агентства должны прекратить использовать SHA1-1 для применения, которые требуют сопротивления столкновению и должны использовать SHA-2 после 2010^NIST.

поэтому, если вы ищете простое и быстрое решение для проверки целостности файлы (против коррупции), или для некоторых простых кэширования целей с точки зрения производительности, вы можете рассмотреть КПР-32, для хеширования вы можете рассмотреть, чтобы использовать MD5, однако, если вы разрабатываете приложение (который должен быть надежным и последовательным), чтобы избежать столкновения вероятностей - использовать SHA-2 и выше (таких как SHA-3).

производительность

несколько простых теста в PHP:

# Testing static text.

$ time php -r 'for ($i=0;$i<1000000;$i++) crc32("foo");'
real    0m0.845s
user    0m0.830s
sys     0m0.008s

$ time php -r 'for ($i=0;$i<1000000;$i++) md5("foo");'
real    0m1.103s
user    0m1.089s
sys     0m0.009s

$ time php -r 'for ($i=0;$i<1000000;$i++) sha1("foo");'
real    0m1.132s
user    0m1.116s
sys   0m0.010s

# Testing random number. 

$ time php -r 'for ($i=0;$i<1000000;$i++) crc32(rand(0,$i));'
real    0m1.754s
user    0m1.735s
sys     0m0.012s\

$ time php -r 'for ($i=0;$i<1000000;$i++) md5(rand(0,$i));'
real    0m2.065s
user    0m2.042s
sys     0m0.015s

$ time php -r 'for ($i=0;$i<1000000;$i++) sha1(rand(0,$i));'
real    0m2.050s
user    0m2.021s
sys     0m0.015s

по теме:

• в чем разница между криптографией md5(), crc32() и sha1() на PHP?

давайте начнем с основ.

в криптографии алгоритм хэширования преобразует много битов в меньшее количество битов с помощью операции дайджеста. Хэши используются для подтверждения целостности сообщений и файлов.

все алгоритмы хэширования генерируют коллизии. столкновение когда несколько многоразрядных комбинаций производят такой же меньше выхода бита. Криптографической стойкости алгоритма хэширования определяется невозможностью для индивида определить, что вывод будет для данного ввода, потому что, если бы они могли, они могли бы построить файл с хэшем, который соответствует законному файлу и компрометирует предполагаемую целостность системы. Разница между CRC32 и MD5 заключается в том, что MD5 генерирует больший хэш, который сложнее предсказать.

когда вы хотите реализовать целостность сообщения-это означает, что сообщение не было изменено в пути - невозможность предсказать столкновения является важным свойством. А 32-бит хэш может охарактеризовать 4 миллиардов различных сообщений или файлы, использующие 4 миллиарда различных уникальных хэшей. Если у вас есть 4 миллиарда и 1 файл, вы гарантированно будете иметь 1 столкновение. 1 Tb Bitspace имеет возможность для миллиардов столкновений. Если я злоумышленник и могу предсказать, каким будет 32-битный хэш, я могу создать зараженный файл, который сталкивается с целевым файлом; у него тот же хэш.

дополнительно, если я делаю передачу 10mbps тогда возможность повреждения пакета прямо для обхода crc32 и продолжения по направлению к месту назначения и выполнения очень низка. Скажем, в 10mbps я получаю 10 ошибок\второй. Если я увеличу это до 1gbps, теперь я получаю 1,000 ошибок в секунду. Если я ОЗУ до 1 эксабит в секунду, то у меня ошибка 1,000,000,000 ошибок в секунду. Скажем, у нас скорость коллизии 1\1,000,000 ошибки передачи, смысл 1 на миллион, результаты ошибок передачи поврежденных данных проняло незамеченными. В 10mbps я получал данные об ошибках, отправляемые каждые 100 000 секунд или примерно раз в день. В 1gbps это произойдет раз в 5 минут. На 1 эксабит в секунду, мы говорим несколько раз в секунду.

Если вы откроете wireshark, вы увидите, что ваш типичный заголовок ethernet имеет CRC32, ваш IP-заголовок имеет CRC32, а ваш TCP-заголовок имеет CRC32, и это в дополнение к тому, что более высокий уровень протоколы могут делать, например, IPSec может использовать MD5 или SHA для проверки целостности, в дополнение к вышесказанному. Существует несколько уровней проверки ошибок в типичных сетевых коммуникациях, и они по-прежнему время от времени ошибаются на скоростях sub 10mbps.

Cyclic Redundancy Check (CRC) имеет несколько распространенных версий и несколько необычных, но обычно предназначен для того, чтобы просто сказать, когда сообщение или файл был поврежден в пути (несколько битов листать). CRC32 сам по себе не очень хорошая проверка ошибок протокол по сегодняшним стандартам в больших, скалярных корпоративных средах из-за скорости столкновения; средний жесткий диск пользователей может иметь более 100k файлов, а файловые акции компании могут иметь десятки миллионов. Отношение хэш-пространства к количеству файлов слишком низкое. CRC32 вычислительно дешев для имплиментации, тогда как MD5 нет.

MD5 был разработан, чтобы остановить преднамеренное использование коллизий, чтобы сделать вредоносный файл выглядеть злокачественным. Это считается небезопасным, потому что в hashspace была достаточно сопоставить, чтобы включить некоторые теракты происходят, и некоторые collissions являются preditable. SHA1 и SHA2-новые дети в квартале.

для проверки файлов Md5 начинает использоваться многими поставщиками, потому что вы можете быстро делать многогигабайтные файлы или многотеррабайтные файлы с ним и укладывать это поверх общего использования ОС и поддержки CRC32. Не удивляйтесь, если в течение следующего десятилетия файловые системы начнут использовать MD5 для проверки ошибок.

код CRC проще и быстрее.

для чего вам нужно?