Когда CRC более подходит для использования, чем MD5 / SHA1? - PullRequest
117 голосов
/ 15 июня 2009

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

Ответы [ 13 ]

102 голосов
/ 15 июня 2009

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

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

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

29 голосов
/ 15 июня 2009

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

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

19 голосов
/ 22 сентября 2011

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

Соответствующее заключение о CRC для хэшей:

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

UPDATE

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

16 голосов
/ 16 апреля 2012

Я запустил каждую строку этого 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
10 голосов
/ 17 июня 2009

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

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

8 голосов
/ 16 июня 2009

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

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

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

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

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

6 голосов
/ 05 февраля 2016

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

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

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

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

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 после 2010 года NIST .

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

Performance

Несколько простых тестов производительности в 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

Связанный:

6 голосов
/ 15 июня 2009

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

Используйте это, когда вы просто хотите быструю и легкую контрольную сумму. CRC используется в Ethernet.

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

5 голосов
/ 09 декабря 2010

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

5 голосов
/ 15 июня 2009

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

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

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

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

...