Проверка циклическим избыточным кодом

Тип хеш-функции, используемой для обнаружения ошибок при хранении или передаче данных

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

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

CRC была изобретена У. Уэсли Петерсоном в 1961 году; 32-битная функция CRC, используемая в Ethernet и многих других стандартах, является работой нескольких исследователей и была опубликована в 1975 году.

• 1 Введение
• 2 Приложение
• 3 Целостность данных
• 4 Вычисления
  • 4.1 Алгоритм CRC-32
• 5 Математика
  • 5.1 Разработка многочленов
• 6 Спецификация
• 7 Обфускация
• 8 Стандарты и обычное использование
• 9 Полиномиальные представления циклических проверок избыточности
  • 9.1 Реализации
  • 9.2 Каталоги CRC
• 10 См. Также
• 11 Ссылки
• 12 Дополнительная литература
• 13 Внешние ссылки

CRC основаны на теории циклических кодов с исправлением ошибок. Использование систематических циклических кодов, которые кодируют сообщения путем добавления контрольного значения фиксированной длины, с целью обнаружения ошибок в сетях связи, было впервые предложено W. Уэсли Петерсон в 1961 году. Циклические коды не только просты в реализации, но и имеют то преимущество, что они особенно хорошо подходят для обнаружения пакетных ошибок : непрерывных последовательностей ошибочных символов данных в сообщениях. Это важно, потому что пакетные ошибки являются общими ошибками передачи во многих каналах связи, включая магнитные и оптические запоминающие устройства. Обычно n-битный CRC, применяемый к блоку данных произвольной длины, обнаруживает любой одиночный пакет ошибок не длиннее n битов, а доля всех более длинных пакетов ошибок, которые он обнаружит, составляет (1-2).

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

На практике все обычно используемые CRC используют поле Галуа из двух элементов, GF (2). Эти два элемента обычно называются 0 и 1, что удобно для компьютерной архитектуры.

CRC называется n-битным CRC, если его контрольное значение имеет длину n бит. Для заданного n возможно несколько CRC, каждый с различным полиномом. Такой многочлен имеет наивысшую степень n, что означает, что он имеет n + 1 член. Другими словами, полином имеет длину n + 1; для его кодирования требуется n + 1 бит. Обратите внимание, что в большинстве спецификаций полиномов либо отбрасываются MSB, либо LSB, поскольку они всегда равны 1. CRC и связанный с ним многочлен обычно имеют имя в форме CRC-n-XXX, как в таблица ниже.

Простейшая система обнаружения ошибок, бит четности, на самом деле является 1-битным CRC: он использует полином генератора x + 1 (два члена) и имеет название CRC. -1.

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

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

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

Устройство может предпринять корректирующие действия, например повторно прочитать блок или запросить его повторную отправку. В противном случае предполагается, что данные не содержат ошибок (хотя с некоторой небольшой вероятностью они могут содержать необнаруженные ошибки; это свойственно самой природе проверки ошибок).

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

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

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

В-третьих, CRC - это линейная функция с свойство, которое

$crc\; \; (x\; \oplus \; y\; \oplus \; z)\; =\; crc\; \; (x)\; \oplus \; crc\; \; (y)\; \oplus \; crc\; \; (z);\; \{\backslash \; displaystyle\; \backslash \; operatorname\; \{crc\}\; (x\; \backslash \; oplus\; y\; \backslash \; oplus\; z)\; =\; \backslash \; operatorname\; \{crc\}\; (x)\; \backslash \; oplus\; \backslash \; operatorname\; \{crc\}\; (y)\; \backslash \; oplus\; \backslash \; operatorname\; \{crc\}\; (z);\}$

в результате, даже если CRC зашифрован с помощью потокового шифра, который использует XOR в качестве операции объединения (или режим из блочного шифра, который эффективно превращает его в потоковый шифр, такой как OFB или CFB), и сообщением, и связанным CRC можно манипулировать без знания ключа шифрования; это был один из хорошо известных недостатков конструкции протокола Wired Equivalent Privacy (WEP).

Чтобы вычислить n-битный двоичный CRC, выведите строку биты, представляющие ввод в строке, и размещают (n + 1) -битовый шаблон, представляющий делитель CRC (называемый «полиномом ») под левым концом строки.

В этом примере мы закодируем 14 бит сообщения с помощью 3-битной CRC с полиномом x + x + 1. Полином записывается в двоичном формате как коэффициенты; многочлен 3-й степени имеет 4 коэффициента (1x + 0x + 1x + 1). В этом случае коэффициенты равны 1, 0, 1 и 1. Результат вычисления составляет 3 бита.

Начните с сообщения, которое нужно закодировать:

11010011101100

Сначала оно дополняется нулями, соответствующими длине битов n CRC. Это делается для того, чтобы результирующее кодовое слово имело систематическую форму. Вот первое вычисление для вычисления 3-битного CRC:

11010011101100 000 <--- input right padded by 3 bits 1011 <--- divisor (4 bits) = x³ + x + 1 ------------------ 01100011101100 000 <--- result

Алгоритм воздействует на биты непосредственно над делителем на каждом шаге. Результатом этой итерации является побитовое исключающее ИЛИ полиномиального делителя с битами над ним. Биты не выше делителя просто копируются прямо ниже для этого шага. Затем делитель сдвигается вправо, чтобы выровняться с наивысшим оставшимся 1 битом на входе, и процесс повторяется до тех пор, пока делитель не достигнет правого конца входной строки. Вот полный расчет:

11010011101100 000 <--- input right padded by 3 bits 1011 <--- divisor 01100011101100 000 <--- result (note the first four bits are the XOR with the divisor beneath, the rest of the bits are unchanged) 1011 <--- divisor... 00111011101100 000 1011 00010111101100 000 1011 00000001101100 000 <--- note that the divisor moves over to align with the next 1 in the dividend (since quotient for that step was zero) 1011 (in other words, it doesn't necessarily move one bit per iteration) 00000000110100 000 1011 00000000011000 000 1011 00000000001110 000 1011 00000000000101 000 101 1 ----------------- 00000000000000 100 <--- remainder (3 bits). Division algorithm stops here as dividend is equal to zero.

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

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

11010011101100 100 <--- input with check value 1011 <--- divisor 01100011101100 100 <--- result 1011 <--- divisor... 00111011101100 100...... 00000000001110 100 1011 00000000000101 100 101 1 ------------------ 00000000000000 000 <--- remainder

Следующий код Python описывает функцию, которая будет возвращать начальный остаток CRC для выбранного ввода и полинома с 1 или 0 в качестве начального заполнения. Обратите внимание, что этот код работает со строковыми входными данными, а не с необработанными числами:

def crc_remainder (input_bitstring, polynomial_bitstring, initial_filler): "" "Вычислить остаток CRC строки битов, используя выбранный полином. Initial_filler должен быть '1' или '0'. "" "Polynomial_bitstring = polynomial_bitstring.lstrip ('0') len_input = len (input_bitstring) initial_padding = initial_filler * (len (polynomial_bitstring) - 1) input_padded_array = list (input_bitstring + initial_padding_pad) в то время как '1_arded inputpad : len_input]: cur_shift = input_padded_array.index ('1') для i в диапазоне (len (polynomial_bitstring)): input_padded_array [cur_shift + i] = str (int (polynomial_bitstring [i]! = input_padded_array [cur_shift + i])) return ''.join (input_padded_array) [len_input:] def crc_check (input_bitstring, polynomial_bitstring, check_value): "" "Вычислить проверку CRC строки битов, используя выбранный полином." "" polynomial_bitstring = polynomial_bitstring 0.lstrip ') len_input = len (input_bitstring) initial_padding = check_value input_padded_array = список (input_bitstring + initial_padding), а '1' в input_padded_array [: len_input]: cur_shift = input_padded_array.index ('1') для i в диапазоне (len (polynomial_bitstring)): i in range [len (polynomial_bitstring)): i input_pad_shift_array] = str (int (polynomial_bitstring [i]! = input_padded_array [cur_shift + i])) return ('1' не в ''.join (input_padded_array) [len_input:])

>>>crc_check ('11010011101100', '1011', '100') True>>>crc_remainder ('11010011101100', '1011', '0') '100'

Алгоритм CRC-32

Это практический алгоритм для CRC -32 вариант CRC. CRCTable - это мемоизация вычисления, которое должно быть повторено для каждого байта сообщения (Вычисление циклических проверок избыточности § Многобитовое вычисление ).

Функция CRC32 Вход: данные: байты // Массив байтов Вывод: crc32: UInt32 // 32-битное беззнаковое crc-32 value . // Инициализируем crc-32 начальным значением crc32 ← 0xFFFFFFFF. для каждого байта в данных do nLookupIndex ← (crc32 xor byte) и 0xFF; crc32 ← (crc32 shr 8) xor CRCTable [nLookupIndex] // CRCTable - это массив из 256 32-битных констант . // Завершить значение CRC-32, инвертируя все биты crc32 ← crc32 xor 0xFFFFFFFF return crc32

Математический анализ этого подобного делению процесса показывает, как выбрать делитель, который гарантирует хорошие свойства обнаружения ошибок. В этом анализе цифры битовых цепочек берутся в качестве коэффициентов многочлена от некоторой переменной x - коэффициентов, которые являются элементами конечного поля GF (2), вместо более привычных чисел. Набор двоичных полиномов представляет собой математическое кольцо.

Разработка многочленов

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

Самым важным атрибутом полинома является его длина (наибольшая степень (экспонента) +1 любого члена в полиноме) из-за его прямого влияния на длину вычисляемого контрольного значения.

Наиболее часто используемые полиномиальные длины:

• 9 бит (CRC-8)
• 17 бит (CRC-16)
• 33 бита (CRC-32)
• 65 бит (CRC-64)

CRC называется n-битным CRC, если его контрольное значение равно n битам. Для заданного n возможно несколько CRC, каждый с различным полиномом. Такой многочлен имеет наивысшую степень n, а значит, n + 1 член (длина многочлена n + 1). Остаток имеет длину n. CRC имеет имя в форме CRC-n-XXX.

Схема полинома CRC зависит от максимальной общей длины блока, который должен быть защищен (данные + биты CRC), желаемых функций защиты от ошибок и типа ресурсов для реализации CRC, а также желаемая производительность. Распространенное заблуждение состоит в том, что «лучшие» полиномы CRC получаются либо из неприводимых полиномов, либо из неприводимых полиномов, умноженных на множитель 1 + x, что добавляет к коду возможность обнаруживать все ошибки, влияющие на нечетное количество битов.. В действительности все описанные выше факторы должны входить в выбор полинома и могут привести к приводимому полиному. Однако выбор приводимого полинома приведет к определенной доле пропущенных ошибок из-за того, что кольцо частных имеет делителей нуля.

Преимущество выбора примитивного полинома в качестве генератора для кода CRC. заключается в том, что результирующий код имеет максимальную общую длину блока в том смысле, что все однобитовые ошибки в пределах этой длины блока имеют разные остатки (также называемые синдромами ) и, следовательно, поскольку остаток является линейной функцией блока, код может обнаружить все 2-битные ошибки в пределах этой длины блока. Если $r\; \{\backslash \; displaystyle\; r\}$- это степень полинома примитивного генератора, то максимальная общая длина блока будет $2\; r\; -\; 1\; \{\backslash \; displaystyle\; 2\; ^\; \{r\}\; -1\}.$, и связанный с ним код может обнаруживать любые однобитовые или двухбитовые ошибки. Мы можем исправить эту ситуацию. Если мы используем порождающий полином $g\; (x)\; =\; p\; (1\; +\; x)\; \{\backslash \; displaystyle\; g\; (x)\; =\; p\; (1\; +\; x)\}$, где $p\; \{\backslash \; displaystyle\; p\}$- примитивный полином степени $r\; -\; 1\; \{\backslash \; displaystyle\; r-1\}$, тогда максимальная общая длина блока составляет $2\; r\; -\; 1\; -\; 1\; \{\backslash \; displaystyle\; 2\; ^\; \{r-1\}\; -1\}$, и код может обнаруживать одиночные, двойные, тройные и любое нечетное количество ошибок.

Многочлен $g\; (x)\; \{\backslash \; displaystyle\; g\; (x)\}$, который допускает, что тогда могут быть выбраны другие факторизации, чтобы сбалансировать максимальную общую длину блока с желаемым обнаружением ошибок сила. Коды BCH представляют собой мощный класс таких многочленов. Они включают два приведенных выше примера. Независимо от свойств сводимости порождающего полинома степени r, если он включает член «+1», код сможет обнаруживать шаблоны ошибок, которые ограничены окном из r смежных битов. Эти шаблоны называются «пакетами ошибок».

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

• Иногда реализация добавляет фиксированный битовый шаблон к проверяемому битовому потоку. Это полезно, когда ошибки синхронизации могут вставлять 0-биты перед сообщением, изменение, которое в противном случае оставило бы значение проверки неизменным.
• Обычно, но не всегда, реализация добавляет n 0-битов (n - размер CRC) в поток битов, который должен быть проверен до того, как произойдет полиномиальное деление. Такое добавление явно продемонстрировано в статье Вычисление CRC. Это удобно в том, что остаток от исходного потока битов с добавленным контрольным значением равен нулю, поэтому CRC можно проверить, просто выполнив полиномиальное деление полученного потока битов и сравнив остаток с нулем. Благодаря ассоциативным и коммутативным свойствам операции исключающее ИЛИ практические реализации, управляемые таблицами, могут получить результат, численно эквивалентный добавлению нулей без явного добавления нулей, с помощью эквивалентного, более быстрого алгоритма, который объединяет поток битов сообщения с потоком сдвигается из регистра CRC.
• Иногда реализация исключающее ИЛИ использует фиксированный битовый шаблон в оставшуюся часть полиномиального деления.
• Порядок битов: Некоторые схемы рассматривают младший бит каждого байта как «первый», который затем во время полиномиального деления означает «крайний левый», что противоречит нашему обычному пониманию «младшего разряда». Это соглашение имеет смысл, когда передачи последовательного порта проходят аппаратную проверку CRC, потому что некоторые широко распространенные соглашения о передаче последовательного порта сначала передают байты младшего бита.
• Порядок байтов : С многобайтовыми CRC может возникнуть путаница в отношении того, является ли байт, переданный первым (или сохраненный в байте с наименьшим адресом памяти), младшим (LSB) или старшим (MSB) байтом. Например, некоторые 16-битные схемы CRC меняют местами байты контрольного значения.
• Пропуск старшего бита полинома делителя: поскольку старший бит всегда равен 1, и поскольку n- бит CRC должен определяться (n + 1) -битным делителем, который переполняет n-битный регистр, некоторые авторы предполагают, что нет необходимости упоминать старший бит делителя
• Пропуск младшего бита полинома делителя: поскольку младший бит всегда равен 1, такие авторы, как Филип Купман, представляют полиномы с неповрежденным старшим битом, но без младшего разряда. бит ($x\; 0\; \{\backslash \; displaystyle\; x\; ^\; \{0\}\}$или 1 член). Это соглашение кодирует полином вместе со степенью в одно целое число.

Эти сложности означают, что есть три распространенных способа выразить полином в виде целого числа: первые два, зеркальные изображения в двоичном формате, представляют собой константы, найденные в коде. ; третий - номер, найденный в бумагах Купмана. В каждом случае один член опускается. Таким образом, многочлен $x\; 4\; +\; x\; +\; 1\; \{\backslash \; displaystyle\; x\; ^\; \{4\}\; +\; x\; +\; 1\}$можно записать как:

• 0x3 = 0b0011, что представляет $x\; 4\; +\; (0\; x\; 3\; +\; 0\; x\; 2\; +\; 1\; x\; 1\; +\; 1\; x\; 0)\; \{\backslash \; displaystyle\; x\; ^\; \{4\}\; +\; (0x\; ^\; \{3\}\; +\; 0x\; ^\; \{2\}\; +\; 1x\; ^\; \{1\}\; +\; 1x\; ^\; \{0\})\}$(первый код MSB)
• 0xC = 0b1100, представляющий $(1\; x\; 0\; +\; 1\; x\; 1\; +\; 0\; x\; 2\; +\; 0\; x\; 3)\; +\; x\; 4\; \{\backslash \; displaystyle\; (1x\; ^\; \{0\}\; +\; 1x\; ^\; \{1\}\; +\; 0x\; ^\; \{2\}\; +\; 0x\; ^\; \{3\})\; +\; x\; ^\; \{4\}\}$(первый младший бит код)
• 0x9 = 0b1001, что соответствует $(1\; x\; 4\; +\; 0\; x\; 3\; +\; 0\; x\; 2\; +\; 1\; x\; 1)\; +\; x\; 0\; \{\backslash \; displaystyle\; (1x\; ^\; \{4\}\; +\; 0x\; ^\; \{3\}\; +\; 0x\; ^\; \{2\}\; +\; 1x\; ^\; \{1\})\; +\; x\; ^\; \{0\}\}$(нотация Купмана)

В таблице ниже они показаны как:

Примеры представлений CRC

Имя	Нормальный	Обратный	Обратный обратный
CRC-4	0x3	0xC	0x9

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

В технические стандарты включены многочисленные разновидности циклических проверок избыточности. Ни в коем случае не один алгоритм или по одной каждой степени подходит для всех целей; Купман и Чакраварти рекомендуют выбирать полином в соответствии с требованиями приложения и ожидаемым распределением длин сообщений. Количество используемых различных CRC сбивает разработчиков с толку, и авторы стремились исправить эту ситуацию. Сообщается о трех полиномах для CRC-12, о двадцати двух конфликтующих определениях CRC-16 и о семи для CRC-32.

Обычно применяемые полиномы не являются наиболее эффективными из возможных. С 1993 года Купман, Кастаньоли и другие исследовали пространство многочленов размером от 3 до 64 бит и нашли примеры, которые имеют гораздо лучшую производительность (с точки зрения расстояния Хэмминга для данного размера сообщения), чем многочлены. более ранних протоколов и публикация лучших из них с целью улучшения способности обнаружения ошибок будущих стандартов. В частности, в iSCSI и SCTP был принят один из результатов этого исследования - полином CRC-32C (Кастаньоли).

Разработка 32-битного многочлена, наиболее часто используемого органами стандартизации, CRC-32-IEEE, была результатом совместных усилий Римской лаборатории и электронных систем ВВС США. Подразделение Джозефа Хаммонда, Джеймса Брауна и Шиан-Шианг Лю из Технологического института Джорджии и Кеннета Брайера из Mitre Corporation. Самые ранние известные появления 32-битного полинома были в их публикациях 1975 года: Технический отчет 2956 Брайера для Mitre, опубликованный в январе и выпущенный для публичного распространения через DTIC в августе, и отчет Хаммонда, Брауна и Лю. для Римской лаборатории, опубликовано в мае. Оба отчета содержали материалы другой команды. В декабре 1975 года Брайер и Хаммонд представили свою работу в докладе на Национальной телекоммуникационной конференции IEEE: полином IEEE CRC-32 является порождающим полиномом кода Хэмминга и был выбран за его способность обнаруживать ошибки. Даже в этом случае полином CRC-32C Кастаньоли, используемый в iSCSI или SCTP, соответствует своей производительности для сообщений от 58 бит до 131 кбит и превосходит его в нескольких диапазонах размеров, включая два наиболее распространенных размера интернет-пакетов. Стандарт ITU-T G.hn также использует CRC-32C для обнаружения ошибок в полезной нагрузке (хотя он использует CRC-16-CCITT для заголовков PHY ).

Вычисление CRC32C реализовано аппаратно как операция (CRC32) набора инструкций SSE4.2, впервые представленная в процессорах Intel Микроархитектура Nehalem. Операции CRC32C также определены в AArch64.

В таблице ниже перечислены только полиномы различных используемых алгоритмов. Варианты конкретного протокола могут накладывать преинверсию, постинверсию и обратный порядок битов, как описано выше. Например, CRC32, используемый в Gzip и Bzip2, использует один и тот же многочлен, но Gzip использует обратный порядок битов, а Bzip2 - нет. Обратите внимание, что полиномы четности в GF (2) со степенью больше 1 никогда не являются примитивными. Полином четности, помеченный как примитив в этой таблице, представляет примитивный полином, умноженный на $(x\; +\; 1)\; \{\backslash \; displaystyle\; \backslash \; left\; (x\; +\; 1\; \backslash \; right)\}$.

Имя	Использует	Полиномиальные представления				Четность	Примитив	Максимальное количество битов полезной нагрузки на расстояние Хэмминга
		Нормальное	Обратное	Взаимное	Обратное обратное			≥ 16	15	14	13	12	11	10	9	8	7	6	5	4	3	2
CRC-1	большая часть оборудования; также известен как бит четности	0x1	0x1	0x1	0x1	даже
		$x\; +\; 1\; \{\backslash \; displaystyle\; x\; +1\}$
CRC-3- GSM	мобильные сети	0x3	0x6	0x5	0x5	нечетное	да	–	–	–	–	–	–	–	–	–	–	–	–	–	4	∞
		$x\; 3\; +\; x\; +\; 1\; \{\backslash \; displaystyle\; x\; ^\; \{3\}\; +\; x\; +\; 1\}$
CRC-4-ITU	ITU-T G.704, стр. 12	0x3	0xC	0x9	0x9	нечетное
		$x\; 4\; +\; x\; +\; 1\; \{\backslash \; displaystyle\; x\; ^\; \{4\}\; +\; x\; +\; 1\}$
CRC-5-EPC	RFID поколения 2	0x09	0x12	0x05	0x14	нечетное
		$x\; 5\; +\; x\; 3\; +\; 1\; \{\backslash \; displaystyle\; x\; ^\; \{5\}\; +\; x\; ^\; \{3\}\; +1\}$
CRC-5-ITU	ITU-T G.704, стр. 9	0x15	0x15	0x0B	0x1A	даже
		$x\; 5\; +\; x\; 4\; +\; x\; 2\; +\; 1\; \{\; \backslash \; displaystyle\; x\; ^\; \{5\}\; +\; x\; ^\; \{4\}\; +\; x\; ^\; \{2\}\; +1\}$
CRC-5-USB	USB токен-пакеты	0x05	0x14	0x09	0x12	нечетное
		$x\; 5\; +\; x\; 2\; +\; 1\; \{\backslash \; displaystyle\; x\; ^\; \{5\}\; +\; x\; ^\; \{2\}\; +1\; \}$
CRC-6- CDMA2000 -A	мобильные сети	0x27	0x39	0x33	0x33	нечетное
CRC-6- CDMA2000 -B	мобильные сети	0x07	0x38	0x31	0x23	даже
CRC-6-DARC	Радиоканал данных	0x19	0x26	0x0D	0x2C	даже
CRC-6- GSM	мобильные сети	0x2F	0x3D	0x3B	0x37	даже	да	–	–	–	–	–	–	–	–	–	–	1	1	25	25	∞
		$x\; 6\; +\; x\; 5\; +\; x\; 3\; +\; x\; 2\; +\; x\; +\; 1\; \{\backslash \; displaystyle\; x\; ^\; \{6\}\; +\; x\; ^\; \{5\}\; +\; x\; ^\; \{3\}\; +\; x\; ^\; \{2\}\; +\; x\; +\; 1\}$
CRC-6-ITU	ITU-T G.704, стр. 3	0x03	0x30	0x21	0x21	нечетное
		$x\; 6\; +\; x\; +\; 1\; \{\backslash \; displaystyle\; x\; ^\; \{6\}\; +\; x\; +\; 1\}$
CRC-7	телекоммуникационные системы, ITU-T G.707, ITU-T G.832, MMC, SD	0x09	0x48	0x11	0x44	нечетное
		$x\; 7\; +\; x\; 3\; +\; 1\; \{\backslash \; displaystyle\; x\; ^\; \{7\}\; +\; x\; ^\; \{3\}\; +1\}$
CRC-7-MVB	Train Communication Network, IEC 60870-5	0x65	0x53	0x27	0x72	нечетное
CRC-8	DVB-S2	0xD5	0xAB	0x57	0xEA	четный	нет	–	–	–	–	–	–	–	–	–	–	2	2	85	85	∞
		$x\; 8\; +\; x\; 7\; +\; x\; 6\; +\; x\; 4\; +\; x\; 2\; +\; 1\; \{\backslash \; displaystyle\; x\; ^\; \{8\}\; +\; x\; ^\; \{7\}\; +\; x\; ^\; \{6\}\; +\; x\; ^\; \{4\}\; +\; x\; ^\; \{2\}\; +1\}$
CRC-8- AUTOSAR	автомобильный интеграция, OpenSafety	0x2F	0xF4	0xE9	0x97	даже	да	–	–	–	–	–	–	–	–	–	–	3	3	119	119	∞
		$x\; 8\; +\; x\; 5\; +\; x\; 3\; +\; x\; 2\; +\; x\; +\; 1\; \{\backslash \; displaystyle\; x\; ^\; \{8\}\; +\; x\; ^\; \{5\}\; +\; x\; ^\; \{3\}\; +\; x\; ^\; \{2\}\; +\; x\; +\; 1\}$
CRC-8- Bluetooth	беспроводное соединение	0xA7	0xE5	0xCB	0xD3	даже
		$x\; 8\; +\; x\; 7\; +\; x\; 5\; +\; x\; 2\; +\; x\; +\; 1\; \{\backslash \; displaystyle\; x\; ^\; \{8\}\; +\; x\; ^\; \{7\}\; +\; x\; ^\; \{5\}\; +\; x\; ^\; \{2\}\; +\; x\; +\; 1\}$
CRC-8- CCITT	ITU-T I.432.1 (02/99) ; ATM HEC, ISDN HEC и выделение ячеек, SMBus PEC	0x07	0xE0	0xC1	0x83	даже
		$x\; 8\; +\; x\; 2\; +\; x\; +\; 1\; \{\backslash \; displaystyle\; x\; ^\; \{8\}\; +\; x\; ^\; \{2\}\; +\; x\; +\; 1\}$
CRC- 8- Даллас / Максим	1-Wire шина	0x31	0x8C	0x19	0x98	даже
		$x\; 8\; +\; x\; 5\; +\; x\; 4\; +\; 1\; \{\backslash \; displaystyle\; x\; ^\; \{8\}\; +\; x\; ^\; \{5\}\; +\; x\; ^\; \{4\}\; +1\}$
CRC- 8-DARC	Радиоканал данных	0x39	0x9C	0x39	0x9C	нечетный
		$x\; 8\; +\; x\; 5\; +\; x\; 4\; +\; x\; 3\; +\; 1\; \{\backslash \; displaystyle\; x\; ^\; \{8\}\; +\; x\; ^\; \{5\}\; +\; x\; ^\; \{4\}\; +\; x\; ^\; \{3\}\; +1\}$
CRC-8- GSM -B	мобильные сети	0x49	0x92	0x25	0xA4	даже
		$x\; 8\; +\; x\; 6\; +\; x\; 3\; +\; 1\; \{\backslash \; displaystyle\; x\; ^\; \{8\}\; +\; x\; ^\; \{6\}\; +\; x\; ^\; \{3\}\; +1\}$
CRC-8- SAE J1850	AES3 ; OBD	0x1D	0xB8	0x71	0x8E	нечетное
		$x\; 8\; +\; x\; 4\; +\; x\; 3\; +\; x\; 2\; +\; 1\; \{\backslash \; displaystyle\; x\; ^\; \{8\}\; +\; x\; ^\; \{4\}\; +\; x\; ^\; \{3\}\; +\; x\; ^\; \{2\}\; +1\}$
CRC-8-	мобильные сети	0x9B	0xD9	0xB3	0xCD	даже
		$x\; 8\; +\; x\; 7\; +\; x\; 4\; +\; x\; 3\; +\; x\; +\; 1\; \{\; \backslash \; displaystyle\; x\; ^\; \{8\}\; +\; x\; ^\; \{7\}\; +\; x\; ^\; \{4\}\; +\; x\; ^\; \{3\}\; +\; x\; +\; 1\}$
CRC-10	Банкомат; ITU-T I.610	0x233	0x331	0x263	0x319	даже
		$x\; 10\; +\; x\; 9\; +\; x\; 5\; +\; x\; 4\; +\; x\; +\; 1\; \{\backslash \; displaystyle\; x\; ^\; \{10\}\; +\; x\; ^\; \{9\}\; +\; x\; ^\; \{5\}\; +\; x\; ^\; \{4\}\; +\; x\; +\; 1\}$
CRC-10- CDMA2000	мобильные сети	0x3D9	0x26F	0x0DF	0x3EC	даже
CRC-10- GSM	мобильные сети	0x175	0x2BA	0x175	0x2BA	нечетное
CRC-11	FlexRay	0x385	0x50E	0x21D	0x5C2	даже
		$x\; 11\; +\; x\; 9\; +\; x\; 8\; +\; x\; 7\; +\; x\; 2\; +\; 1\; \{\backslash \; displaystyle\; x\; ^\; \{11\}\; +\; x\; ^\; \{9\}\; +\; x\; ^\; \{8\}\; +\; x\; ^\; \{7\}\; +\; x\; ^\; \{2\}\; +1\}$
CRC-12	телекоммуникационные системы	0x80F	0xF01	0xE03	0xC07	даже
		$x\; 12\; +\; x\; 11\; +\; x\; 3\; +\; x\; 2\; +\; x\; +\; 1\; \{\backslash \; displaystyle\; x\; ^\; \{12\}\; +\; x\; ^\; \{11\}\; +\; x\; ^\; \{3\}\; +\; x\; ^\; \{2\}\; +\; x\; +\; 1\}$
CRC-12- CDMA2000	мобильные сети	0xF13	0xC8F	0x91F	0xF89	даже
CRC-12- GSM	мобильные сети	0xD31	0x8CB	0x197	0xE98	нечетный
CRC-13-BBC	Сигнал времени, Радиотелевизионный переключатель	0x1CF5	0x15E7	0x0BCF	0x1E7A	даже
		$x\; 13\; +\; x\; 12\; +\; x\; 11\; +\; x\; 10\; +\; x\; 7\; +\; x\; 6\; +\; x\; 5\; +\; x\; 4\; +\; x\; 2\; +\; 1\; \{\backslash \; displaystyle\; x\; ^\; \{13\}\; +\; x\; ^\; \{12\}\; +\; x\; ^\; \{11\}\; +\; x\; ^\; \{10\}\; +\; x\; ^\; \{7\}\; +\; x\; ^\; \{6\}\; +\; x\; ^\; \{5\}\; +\; x\; ^\; \{4\; \}\; +\; x\; ^\; \{2\}\; +1\}$
CRC-14-DARC	Радиоканал данных	0x0805	0x2804	0x1009	0x2402	даже
CRC-14- GSM	мобильные сети	0x202D	0x2D01	0x1A03	0x3016	даже
CRC-15-CAN		0xC599	0x4CD1	0x19A3	0x62CC	даже
		$x\; 15\; +\; x\; 14\; +\; x\; 10\; +\; x\; 8\; +\; x\; 7\; +\; x\; 4\; +\; x\; 3\; +\; 1\; \{\backslash \; displaystyle\; x\; ^\; \{15\}\; +\; x\; ^\; \{14\}\; +\; x\; ^\; \{10\}\; +\; x\; ^\; \{8\; \}\; +\; x\; ^\; \{7\}\; +\; x\; ^\; \{4\}\; +\; x\; ^\; \{3\}\; +1\}$
CRC-15- MPT1327		0x6815	0x540B	0x2817	0x740A	нечетный
CRC-16-Chakravarty	Оптимально для полезной нагрузки ≤64 бита	0x2F15	0xA8F4	0x51E9	0x978A	нечетные
CRC-16-ARINC	ACARS приложения	0xA02B	0xD405	0xA80B	0xD015	нечетное
CRC-16-CCITT	X.25, V.41, HDLC FCS, XMODEM, Bluetooth, PACTOR, SD, DigRF и многие другие; известный как CRC-CCITT	0x1021	0x8408	0x811	0x8810	даже
		$x\; 16\; +\; x\; 12\; +\; x\; 5\; +\; 1\; \{\backslash \; displaystyle\; x\; ^\; \{16\}\; +\; x\; ^\; \{12\}\; +\; x\; ^\; \{5\}\; +1\}$
CRC-16- CDMA2000	мобильные сети	0xC867	0xE613	0xCC27	0xE433	нечетное
CRC-16- DECT	беспроводные телефоны	0x0589	0x91A0	0x2341	0x82C4	даже
		$x\; 16\; +\; x\; 10\; +\; x\; 8\; +\; x\; 7\; +\; x\; 3\; +\; 1\; \{\backslash \; displaystyle\; x\; ^\; \{16\}\; +\; x\; ^\; \{10\}\; +\; x\; ^\; \{8\}\; +\; x\; ^\; \{7\}\; +\; x\; ^\; \{3\}\; +1\}$
CRC-16- T10 - DIF	SCSI DIF	0x8BB7	0xEDD1	0xDBA3	0xC5DB	нечетное
		$x\; 16\; +\; x\; 15\; +\; x\; 11\; +\; x\; 9\; +\; x\; 8\; +\; x\; 7\; +\; x\; 5\; +\; x\; 4\; +\; x\; 2\; +\; x\; +\; 1\; \{\backslash \; displaystyle\; x\; ^\; \{16\}\; +\; x\; ^\; \{15\}\; +\; x\; ^\; \{11\}\; +\; x\; ^\; \{9\}\; +\; x\; ^\; \{8\}\; +\; x\; ^\; \{7\}\; +\; x\; ^\; \{5\}\; +\; x\; ^\; \{4\}\; +\; x\; ^\; \{2\}\; +\; x\; +\; 1\}$
CRC-16- DNP	DNP, IEC 870, M-Bus	0x3D65	0xA6BC	0x4D79	0x9EB2	четный
		$x\; 16\; +\; x\; 13\; +\; x\; 12\; +\; x\; 11\; +\; x\; 10\; +\; x\; 8\; +\; x\; 6\; +\; x\; 5\; +\; x\; 2\; +\; 1\; \{\backslash \; displaysty\; le\; x\; ^\; \{16\}\; +\; x\; ^\; \{13\}\; +\; x\; ^\; \{12\}\; +\; x\; ^\; \{11\}\; +\; x\; ^\; \{10\}\; +\; x\; ^\; \{8\}\; +\; x\; ^\; \{6\}\; +\; x\; ^\; \{5\}\; +\; x\; ^\; \{2\}\; +1\}$
CRC-16- IBM	Bisync, Modbus, USB, ANSI X3.28, SIA DC-07, многие другие; также известные как CRC-16 и CRC-16-ANSI	0x8005	0xA001	0x4003	0xC002	даже
		$x\; 16\; +\; x\; 15\; +\; x\; 2\; +\; 1\; \{\backslash displaystyle\; x^\{16\}+x^\{15\}+x^\{2\}+1\}$
CRC-16-OpenSafety -A	safety fieldbus	0x5935	0xAC9A	0x5935	0xAC9A	odd
CRC-16-OpenSafety -B	safety fieldbus	0x755B	0xDAAE	0xB55D	0xBAAD	odd
CRC-16-Profibus	fieldbus networks	0x1DCF	0xF3B8	0xE771	0x8EE7	odd
Fletcher-16	Used in Adler-32 A B Checksums	Often confused to be a CRC, but actually a checksum; see Fletcher's checksum
CRC-17-CAN	CAN FD	0x1685B	0x1B42D	0x1685B	0x1B42D	even
CRC-21-CAN	CAN FD	0x102899	0x132281	0x064503	0x18144C	even
CRC-24	FlexRay	0x5D6DCB	0xD3B6BA	0xA76D75	0xAEB6E5	even
		$x\; 24\; +\; x\; 22\; +\; x\; 20\; +\; x\; 19\; +\; x\; 18\; +\; x\; 16\; +\; x\; 14\; +\; x\; 13\; +\; x\; 11\; +\; x\; 10\; +\; x\; 8\; +\; x\; 7\; +\; x\; 6\; +\; x\; 3\; +\; x\; +\; 1\; \{\backslash displaystyle\; x^\{24\}+x^\{22\}+x^\{20\}+x^\{19\}+x^\{18\}+x^\{16\}+x^\{14\}+x^\{13\}+x^\{11\}+x^\{10\}+x^\{8\}+x^\{7\}+x^\{6\}+x^\{3\}+x+1\}$
CRC-24-Radix-64	OpenPGP, RTCM 104v3	0x864CFB	0xDF3261	0xBE64C3	0xC3267D	even
		$x\; 24\; +\; x\; 23\; +\; x\; 18\; +\; x\; 17\; +\; x\; 14\; +\; x\; 11\; +\; x\; 10\; +\; x\; 7\; +\; x\; 6\; +\; x\; 5\; +\; x\; 4\; +\; x\; 3\; +\; x\; +\; 1\; \{\backslash displaystyle\; x^\{24\}+x^\{23\}+x^\{18\}+x^\{17\}+x^\{14\}+x^\{11\}+x^\{10\}+x^\{7\}+x^\{6\}+x^\{5\}+x^\{4\}+x^\{3\}+x+1\}$
CRC-24-WCDMA	Used in OS-9 RTOS. Residue = 0x800FE3.	0x800063	0xC60001	0x8C0003	0xC00031	even	yes	–	–	–	–	–	–	–	–	–	–	4	4	8388583	8388583	∞
		$x\; 24\; +\; x\; 23\; +\; x\; 6\; +\; x\; 5\; +\; x\; +\; 1\; \{\backslash displaystyle\; x^\{24\}+x^\{23\}+x^\{6\}+x^\{5\}+x+1\}$
CRC-30	CDMA	0x2030B9C7	0x38E74301	0x31CE8603	0x30185CE3	even
		$x\; 30\; +\; x\; 29\; +\; x\; 21\; +\; x\; 20\; +\; x\; 15\; +\; x\; 13\; +\; x\; 12\; +\; x\; 11\; +\; x\; 8\; +\; x\; 7\; +\; x\; 6\; +\; x\; 2\; +\; x\; +\; 1\; \{\backslash displaystyle\; x^\{30\}+x^\{29\}+x^\{21\}+x^\{20\}+x^\{15\}+x^\{13\}+x^\{12\}+x^\{11\}+x^\{8\}+x^\{7\}+x^\{6\}+x^\{2\}+x+1\}$
CRC-32	ISO 3309 (HDLC ), ANSI X3.66 (ADCCP ), FIPS PUB 71, FED-STD-1003, ITU-T V.42, ISO/IEC/IEEE 802-3 (Ethernet ), SATA, MPEG-2, PKZIP, Gzip, Bzip2, POSIX cksum,PNG,ZMODEM, many others	0x04C11DB7	0xEDB88320	0xDB710641	0x82608EDB	odd	yes	–	10	–	–	12	21	34	57	91	171	268	2974	91607	4294967263	∞
		$x\; 32\; +\; x\; 26\; +\; x\; 23\; +\; x\; 22\; +\; x\; 16\; +\; x\; 12\; +\; x\; 11\; +\; x\; 10\; +\; x\; 8\; +\; x\; 7\; +\; x\; 5\; +\; x\; 4\; +\; x\; 2\; +\; x\; +\; 1\; \{\backslash displaystyle\; x^\{32\}+x^\{26\}+x^\{23\}+x^\{22\}+x^\{16\}+x^\{12\}+x^\{11\}+x^\{10\}+x^\{8\}+x^\{7\}+x^\{5\}+x^\{4\}+x^\{2\}+x+1\}$
CRC-32C (Castagnoli)	iSCSI, SCTP, G.hn payload, SSE4.2, Btrfs, ext4, Ceph	0x1EDC6F41	0x82F63B78	0x05EC76F1	0x8F6E37A0	even	yes	6	–	8	–	20	–	47	–	177	–	5243	–	2147483615	–	∞
		$x\; 32\; +\; x\; 28\; +\; x\; 27\; +\; x\; 26\; +\; x\; 25\; +\; x\; 23\; +\; x\; 22\; +\; x\; 20\; +\; x\; 19\; +\; x\; 18\; +\; x\; 14\; +\; x\; 13\; +\; x\; 11\; +\; x\; 10\; +\; x\; 9\; +\; x\; 8\; +\; x\; 6\; +\; 1\; \{\backslash displaystyle\; x^\{32\}+x^\{28\}+x^\{27\}+x^\{26\}+x^\{25\}+x^\{23\}+x^\{22\}+x^\{20\}+x^\{19\}+x^\{18\}+x^\{14\}+x^\{13\}+x^\{11\}+x^\{10\}+x^\{9\}+x^\{8\}+x^\{6\}+1\}$
CRC-32K (Koopman {1,3,28})	Excellent at Ethernet frame length, poor performance wi th long files	0x741B8CD7	0xEB31D82E	0xD663B05D	0xBA0DC66B	even	no	2	–	4	–	16	–	18	–	152	–	16360	–	114663	–	∞
		$x\; 32\; +\; x\; 30\; +\; x\; 29\; +\; x\; 28\; +\; x\; 26\; +\; x\; 20\; +\; x\; 19\; +\; x\; 17\; +\; x\; 16\; +\; x\; 15\; +\; x\; 11\; +\; x\; 10\; +\; x\; 7\; +\; x\; 6\; +\; x\; 4\; +\; x\; 2\; +\; x\; +\; 1\; \{\backslash displaystyle\; x^\{32\}+x^\{30\}+x^\{29\}+x^\{28\}+x^\{26\}+x^\{20\}+x^\{19\}+x^\{17\}+x^\{16\}+x^\{15\}+x^\{11\}+x^\{10\}+x^\{7\}+x^\{6\}+x^\{4\}+x^\{2\}+x+1\}$
CRC-32K2(Koopman {1,1,30})	Excellent at Ethernet frame length, poor performance with long files	0x32583499	0x992C1A4C	0x32583499	0x992C1A4C	even	no	–	–	3	–	16	–	26	–	134	–	32738	–	65506	–	∞
CRC-32Q	авиация; AIXM	0x814141AB	0xD5828281	0xAB050503	0xC0A0A0D5	даже
		$x\; 32\; +\; x\; 31\; +\; x\; 24\; +\; x\; 22\; +\; x\; 16\; +\; x\; 14\; +\; x\; 8\; +\; x\; 7\; +\; x\; 5\; +\; x\; 3\; +\; x\; +\; 1\; \{\backslash \; displaystyle\; x\; ^\; \{32\}\; +\; x\; ^\; \{31\}\; +\; x\; ^\; \{24\}\; +\; x\; ^\; \{22\}\; +\; x\; ^\; \{16\}\; +\; x\; ^\; \{14\}\; +\; x\; ^\; \{8\}\; +\; x\; ^\; \{7\}\; +\; x\; ^\; \{5\}\; +\; x\; ^\; \{3\}\; +\; x\; +\; 1\}$
Адлер-32		Часто путают быть CRC, но на самом деле контрольной суммой; см. Адлер-32
CRC-40- GSM	Канал управления GSM	0x0004820009	0x9000412000	0x2000824001	0x8002410004	даже
		$x\; 40\; +\; x\; 26\; +\; x\; 23\; +\; x\; 17\; +\; x\; 3\; +\; 1\; =\; (x\; 23\; +\; 1)\; (x\; 17\; +\; x\; 3\; +\; 1)\; \{\backslash \; displaystyle\; x\; ^\; \{\; 40\}\; +\; x\; ^\; \{26\}\; +\; x\; ^\; \{23\}\; +\; x\; ^\; \{17\}\; +\; x\; ^\; \{3\}\; +\; 1\; =\; (x\; ^\; \{23\}\; +1)\; (x\; ^\; \{17\}\; +\; x\; ^\; \{3\}\; +1)\}$
CRC-64- ECMA	ECMA-182 стр. 51, XZ Utils	0x42F0E1EBA9EA3693	0xC96C5795D7870F42	0x92D8AF2BAF0E1E85	0xA17870F5D4F51B49 + xA17870F5D4F51B49 + xA17870F5D4F51B49 + x4 + x 55 + x 54 + x 53 + x 52 + x 47 + x 46 + x 45 + x 40 + x 39 + x 38 + x 37 + x 35 + x 33 + {\ displaystyle x ^ {64} + x ^ {62} + x ^ {57} + x ^ {55} + x ^ {54} + x ^ {53} + x ^ {52} + x ^ {47} + x ^ {46} + x ^ { 45} + x ^ {40} + x ^ {39} + x ^ {38} + x ^ {37} + x ^ {35} + x ^ {33} +}$x\; 32\; +\; x\; 31\; +\; x\; 29\; +\; x\; 27\; +\; x\; 24\; +\; x\; 23\; +\; x\; 22\; +\; x\; 21\; +\; x\; 19\; +\; x\; 17\; +\; x\; 13\; +\; x\; 12\; +\; x\; 10\; +\; x\; 9\; +\; x\; 7\; +\; x\; 4\; +\; x\; +\; 1\; \{\backslash \; displaystyle\; x\; ^\; \{\; 32\}\; +\; x\; ^\; \{31\}\; +\; x\; ^\; \{29\}\; +\; x\; ^\; \{27\}\; +\; x\; ^\; \{24\}\; +\; x\; ^\; \{23\}\; +\; x\; ^\; \{22\}\; +\; x\; ^\; \{21\}\; +\; x\; ^\; \{19\}\; +\; x\; ^\; \{17\}\; +\; x\; ^\; \{13\}\; +\; x\; ^\; \{12\}\; +\; x\; ^\; \{10\}\; +\; x\; ^\; \{9\}\; +\; x\; ^\; \{7\}\; +\; x\; ^\; \{4\}\; +\; x\; +\; 1\}$
		CRC-64-ISO	ISO 3309 (HDLC ), Swiss-Prot / TrEMBL ; считается слабым для хеширования	0x000000000000001B	0xD800000000000000	0xB000000000000001	0x800000000000000D	нечетное
$x\; 64\; +\; x\; 4\; +\; x\; 3\; +\; x\; +\; 1\; \{\backslash \; displaystyle\; x\; ^\; \{64\}\; +\; x\; ^\; \{4\}\; +\; x\; ^\; \{3\}\; +\; x\; +\; 1\}$

Реализации

• Реализация CRC32 в Gnuradio ;
• Код класса C для контрольной суммы CRC расчет с множеством различных CRC на выбор из

каталогов CRC

• Каталог параметризованных алгоритмов CRC
• Зоопарк полиномов CRC

• Математика циклических проверок избыточности
• Вычисление циклических проверок избыточности
• Список хэш-функций
• Список алгоритмов контрольной суммы
• Информационная безопасность
• Простая проверка файлов
• LRC

• Уоррен-младший, Генри С. ( 2013). Восторг хакера (2-е изд.). Эддисон Уэсли - Pearson Education, Inc. ISBN 978-0-321-84268-8.

• ISO / IEC 13239: 2002: Информационные технологии - Телекоммуникации и обмен информацией между системами - Процедуры управления каналом передачи данных высокого уровня (HDLC)
• CRC32-Библиотека Castagnoli Linux