Когда уместно использовать CRC для обнаружения ошибок по сравнению с более современными функциями хеширования, такими как MD5 или SHA1? На встраиваемом оборудовании проще реализовать первое?

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

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

И да, CRC намного проще реализовать на встроенном оборудовании, вы даже можете получить для этого разные пакетные решения на IC.

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

Также посмотрите это .

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

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

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

ОБНОВИТЬ

Похоже, сайт не работает. В интернет-архиве есть копия .

Я запускал каждую строку этого 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» . Там все на CRC.

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

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

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

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,

• серии: SHA-0, SHA-1, SHA-2, SHA-3,

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

Поэтому, если вы ищете простое и быстрое решение для проверки целостности файлов (от повреждения) или для некоторых простых целей кэширования с точки зрения производительности, вы можете рассмотреть CRC-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 () crypto на PHP?

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

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 bit и другие варианты SHA до 512 бит).

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

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

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

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

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

Начнем с основ.

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

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

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

Кроме того, если я выполняю передачу со скоростью 10 Мбит / с, тогда вероятность того, что пакет будет поврежден, чтобы обойти crc32 и продолжить путь к месту назначения и выполнить, очень мала. Допустим, при 10 Мбит / с я получаю 10 ошибок в секунду . Если я увеличу это до 1 Гбит / с, теперь я получаю 1000 ошибок в секунду . Если я набираю до 1 эксабита в секунду, то частота ошибок составляет 1 000 000 000 ошибок в секунду . Скажем, у нас частота столкновений 1 \ 1,000,000Ошибки передачи. Это означает, что 1 из миллиона ошибок передачи приводит к тому, что поврежденные данные проходят незамеченными. На скорости 10 Мбит / с я бы получал данные об ошибках, отправляемые каждые 100 000 секунд или примерно раз в день. При 1 Гбит / с это происходило каждые 5 минут. На скорости 1 эксабит в секунду мы говорим несколько раз в секунду.

Если вы откроете Wireshark, вы увидите, что ваш типичный заголовок Ethernet имеет CRC32, ваш IP-заголовок имеет CRC32, а ваш заголовок TCP имеет CRC32, и это в дополнение к тому, что могут делать протоколы более высокого уровня; например, IPSEC может использовать MD5 или SHA для проверки целостности в дополнение к вышеуказанному. В типичных сетевых коммуникациях есть несколько уровней проверки ошибок, и они ВСЕ ЕЩЕ время от времени работают на скоростях ниже 10 Мбит / с.

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

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

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

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

Для чего они вам нужны?