Длина данных против длины CRC

Я видел 8-битные, 16-битные и 32-битные CRCs.

в какой момент мне нужно перейти к более широкому CRC?

моя реакция кишки заключается в том, что она основана на длине данных:

  1. 1-100 байт: 8-битный CRC
  2. 101 - 1000 байт: 16-битный CRC
  3. 1001 - ??? байты: 32-разрядный CRC

изменить: Глядя на страницу Википедии о CRC и ответе Лотта, вот что у нас есть:

31
crc crc32

6 ответов

это не тема исследования. Это действительно хорошо понятно:http://en.wikipedia.org/wiki/Cyclic_redundancy_check

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

16-битный CRC, аналогично, дает вам одно из 65,536 доступных хэш-значений. Каковы шансы любого два сообщения, имеющие одно из этих значений?

32-битный CRC дает вам около 4 миллиардов доступных хэш-значений.

из статьи Википедии: "максимальная общая длина блока равна 2**r − 1". Это по частям. Вам не нужно делать много исследований, чтобы увидеть это 2**9 - 1 это 511 бит. Используя CRC-8, несколько сообщений длиной более 64 байт будут иметь одинаковое значение контрольной суммы CRC.

29

эффективность CRC зависит от нескольких факторов. Вам нужно не только выбрать размер CRC, но и использовать генерирующий полином. Существуют сложные и неинтуитивные компромиссы в зависимости от:

  • ожидаемая частота битовых ошибок канала.
  • ли ошибки, как правило, происходят в очередях или, как правило, распространяются (burst является общим)
  • длина защищаемых данных - максимальная длина, минимальная длина и распределение.

в статье "Выбор полинома кода циклической избыточности для встроенных сетей" Филиппа Купмана и Тридиба Чакраварти, опубликованной в трудах международной конференции 2004 года по надежным системам и сетям, дается очень хороший обзор и делается несколько рекомендаций. Он также содержит библиографию для дальнейшего понимания.

http://www.ece.cmu.edu/~koopman/roses/dsn04/koopman04_crc_poly_embedded.pdf

6

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

2

CRC должен быть выбран специально для длины сообщений, это не просто вопрос размера CRC: http://www.ece.cmu.edu/~koopman/roses/dsn04/koopman04_crc_poly_embedded.pdf

2

выбор длины CRC по сравнению с размером файла в основном актуален в случаях, когда один, скорее всего, будет иметь вход, который отличается от "правильного" ввода тремя или менее битами, чем иметь один, который сильно отличается. Учитывая два входа, которые сильно отличаются, возможность ложного совпадения будет около 1/256 с большинством форм 8-битного контрольного значения (включая CRC), 1/65536 с большинством форм 16-битного контрольного значения (включая CRC) и т. д. Преимущество CRC приходит от своего обработка входов, которые очень похожи.

с 8-битным CRC, многочлен которого генерирует два периода длины 128, доля одиночных, двойных или тройных битовых ошибок в пакете короче той, которая остается незамеченной, не будет 1/256-она будет равна нулю. Аналогично с 16-битным CRC периода 32768, используя пакеты 32768 бит или меньше.

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

2

вот хорошая оценка" реального мира " CRC-N http://www.backplane.com/matt/crc64.html

Я использую сравнение CRC-32 и размера файла и никогда, в миллиардах проверенных файлов, не сталкивался с совпадением CRC-32 и размера файла. Но я знаю, что некоторые существуют, когда их не заставляют существовать. (Взломанные трюки / эксплойты)

при выполнении сравнения вы также должны проверять "размеры данных". Вы редко сталкиваются одни и те же данные-размер, с соответствуя CRC, в пределах правильных размеров.

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

вы также можете иметь коллизии в пределах размера данных, только по общим пределам используемых формул и ограничения использования битов / байтов и систем base-ten, которые зависят от значений с плавающей запятой, которые усекаются и обрезаются.

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

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

вы можете использовать CRC-8 для индексации всего интернета и разделить все на одну из N-катагорий. Вам нужны эти столкновения. Теперь, с предварительно отсортированными, вам нужно только проверить один из N-каталогов, ища "размер файла" или "обратный CRC", или любое другое сравнение, которое вы можете сделать с этим меньшим набором данных, быстро...

выполнение CRC-32 вперед и назад на одном и том же blob данных более надежно, чем использование CRC-64 только в одном направлении. (Или MD5, если на то пошло.)

1