Як обчислюється контрольна сума CRC32?

Можливо, я просто не бачу цього, але CRC32 здається або непотрібним, або недостатньо поясненим, де б я не міг знайти в Інтернеті.

Я розумію, що це залишок від арифметичного поділу значення повідомлення, що не ґрунтується на перенесенні, розділеного на (багатогранник) поліномом, але фактична реалізація цього мені уникає.

Я прочитав "Безболісний посібник з алгоритмів виявлення помилок CRC" , і повинен сказати, що це не було безболісно. Це досить добре перебирає теорію, але автор ніколи не доходить до простого "це все". Він говорить, які параметри є для стандартного алгоритму CRC32, але він нехтує чітко викласти, як ви до нього дійшли.

Мені здається, коли він каже: "це все", а потім додає: "о, до речі, це можна змінити або почати з різними початковими умовами", і не дає чіткої відповіді, яким буде остаточний шлях обчислення контрольної суми CRC32, враховуючи всі зміни, які він щойно додав.

• Чи існує простіше пояснення того, як розраховується CRC32?

Я намагався кодувати на C, як формується таблиця:

for (i = 0; i < 256; i++)
{
    temp = i;

    for (j = 0; j < 8; j++)
    {
        if (temp & 1)
        {
            temp >>= 1;
            temp ^= 0xEDB88320;
        }
        else {temp >>= 1;}
    }
    testcrc[i] = temp;
}

але це, здається, породжує значення, несумісні зі значеннями, які я знайшов в інших місцях Інтернету. Я міг би використати значення, знайдені в Інтернеті, але я хочу зрозуміти, як вони були створені.

Будемо дуже вдячні за будь-яку допомогу у роз’ясненні цих неймовірно заплутаних цифр .

Поліном для CRC32:

x ³² + x ²⁶ + x ²³ + x ²² + x ¹⁶ + x ¹² + x ¹¹ + x ¹⁰ + x ⁸ + x ⁷ + x ⁵ + x ⁴ + x ² + x + 1

• Вікіпедія
• Розрахунок CRC

Або в шістнадцятковому та двійковому:

0x 01 04 C1 1D B7
1 0000 0100 1100 0001 0001 1101 1011 0111

Найвищий термін (x ³² ), як правило, не написаний явно, тому він може бути представлений у шістнадцятковій формі так само

0x 04 C1 1D B7

Не соромтеся рахувати 1 і 0, але ви виявите, що вони збігаються з поліномом, де 1біт 0 (або перший біт), і xбіт 1 (або другий біт).

Чому цей поліном? Оскільки для даного полінома повинен бути стандарт, а стандарт був встановлений IEEE 802.3. Крім того, надзвичайно важко знайти поліном, який ефективно виявляє різні бітові помилки.

Ви можете уявити CRC-32 як серію "двійкової арифметики без перенесення" або, в основному, "XOR та операції зсуву". Це технічно називається поліноміальна арифметика.

• Праймер CRC, Глава 5

Щоб краще зрозуміти це, подумайте про таке множення:

(x^3 + x^2 + x^0)(x^3 + x^1 + x^0)
= (x^6 + x^4 + x^3
 + x^5 + x^3 + x^2
 + x^3 + x^1 + x^0)
= x^6 + x^5 + x^4 + 3*x^3 + x^2 + x^1 + x^0

Якщо ми припустимо, що х - основа 2, то отримаємо:

x^7 + x^3 + x^2 + x^1 + x^0

• CRC праймер Chp.5

Чому? Оскільки 3x ^ 3 - це 11x ^ 11 (але нам потрібна лише 1 або 0 попередньо розрядних цифр), тому ми переносимо:

=1x^110 + 1x^101 + 1x^100          + 11x^11 + 1x^10 + 1x^1 + x^0
=1x^110 + 1x^101 + 1x^100 + 1x^100 + 1x^11 + 1x^10 + 1x^1 + x^0
=1x^110 + 1x^101 + 1x^101          + 1x^11 + 1x^10 + 1x^1 + x^0
=1x^110 + 1x^110                   + 1x^11 + 1x^10 + 1x^1 + x^0
=1x^111                            + 1x^11 + 1x^10 + 1x^1 + x^0

Але математики змінили правила так, що це mod 2. Отже, в основному будь-який двійковий поліном mod 2 - це просто додавання без перенесення або XOR. Отже, наше вихідне рівняння виглядає так:

=( 1x^110 + 1x^101 + 1x^100 + 11x^11 + 1x^10 + 1x^1 + x^0 ) MOD 2
=( 1x^110 + 1x^101 + 1x^100 +  1x^11 + 1x^10 + 1x^1 + x^0 )
= x^6 + x^5 + x^4 + 3*x^3 + x^2 + x^1 + x^0 (or that original number we had)

Я знаю, що це стрибок віри, але це виходить за рамки моїх можливостей програміста ліній. Якщо ви твердий студент CS або інженер, я кидаю виклик це розбити. Кожен виграє від цього аналізу.

Отже, щоб опрацювати повний приклад:

   Original message                : 1101011011
   Polynomial of (W)idth 4         :      10011
   Message after appending W zeros : 11010110110000

Тепер ми ділимо доповнене повідомлення на полі, використовуючи арифметику CRC. Це такий самий поділ, як і раніше:

            1100001010 = Quotient (nobody cares about the quotient)
       _______________
10011 ) 11010110110000 = Augmented message (1101011011 + 0000)
=Poly   10011,,.,,....
        -----,,.,,....
         10011,.,,....
         10011,.,,....
         -----,.,,....
          00001.,,....
          00000.,,....
          -----.,,....
           00010,,....
           00000,,....
           -----,,....
            00101,....
            00000,....
            -----,....
             01011....
             00000....
             -----....
              10110...
              10011...
              -----...
               01010..
               00000..
               -----..
                10100.
                10011.
                -----.
                 01110
                 00000
                 -----
                  1110 = Remainder = THE CHECKSUM!!!!

Ділення дає частку, яку ми викидаємо, і залишок, який є розрахунковою контрольною сумою. На цьому обчислення закінчується. Зазвичай контрольна сума додається до повідомлення та передається результат. У цьому випадку передача буде: 11010110111110.

• Праймер CRC, Глава 7

Використовуйте лише 32-розрядне число як дільник, а весь потік - як дивіденд. Викиньте частку, а залишок збережіть. Закріпіть залишок у кінці вашого повідомлення, і ви отримаєте CRC32.

Середній відгук хлопця:

         QUOTIENT
        ----------
DIVISOR ) DIVIDEND
                 = REMAINDER

1. Візьміть перші 32 біти.
2. Біт зсуву
3. Якщо 32 біти менше, ніж DIVISOR, перейдіть до кроку 2.
4. XOR 32 біти від DIVISOR. Перейдіть до кроку 2.

(Зверніть увагу, що потік повинен ділитися на 32 біти, або він повинен бути заповнений. Наприклад, 8-розрядний потік ANSI повинен бути забитий. Також у кінці потоку поділ зупинено.)

Для IEEE802.3, CRC-32. Подумайте про все повідомлення як про послідовний бітовий потік, додайте 32 нулі до кінця повідомлення. Далі, ви ПОВИННІ змінити біти КОЖНОГО байта повідомлення і зробити одиниці, доповнюючи перші 32 біти. Тепер поділіть на поліном CRC-32, 0x104C11DB7. Нарешті, ви повинні доповнити 32-бітову залишок цього поділу біт-реверсом кожного з 4 байтів залишку. Це стає 32-розрядною CRC, яка додається до кінця повідомлення.

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

CRC досить простий; ви берете поліном, представлений у вигляді бітів та даних, і ділите поліном на дані (або ви представляєте дані як поліном і робите те саме). Залишок, який знаходиться між 0 і багаточленом, є CRC. Ваш код трохи важко зрозуміти, частково тому, що він неповний: temp та testcrc не оголошуються, тому незрозуміло, що індексується та скільки даних проходить через алгоритм.

Спосіб зрозуміти CRC - це спробувати обчислити кілька, використовуючи короткий фрагмент даних (16 біт або близько того) з коротким поліномом - можливо, 4 біти. Якщо ви практикуєтесь таким чином, ви дійсно зрозумієте, як ви можете піти щодо його кодування.

Якщо ви часто це робите, CRC досить повільно обчислюється в програмному забезпеченні. Апаратні обчислення набагато ефективніші і вимагають лише декількох затворів.

На додаток до перевірки циклічної надмірності у Вікіпедії та обчислення статей CRC , я знайшов хороший довідковий документ під назвою Reversing CRC - Theory and Practice ^* .

По суті, існує три підходи до обчислення CRC: алгебраїчний, бітоорієнтований та таблично-керований. У статті Reversing CRC - Theory and Practice ^* кожен із цих трьох алгоритмів / підходів теоретично пояснюється в супроводі в ДОДАТКУ реалізації для CRC32 мовою програмування C.

<sup>* Зворотний CRC для посилання PDF
- теорія та практика.
Публічний звіт HU Берлін
SAR-PR-2006-05
травня 2006 р.
Автори:
Мартін Штігге, Генрік Плёц, Вольф Мюллер, Йенс-Петер Редліх</sup>

Я витратив якийсь час, намагаючись розкрити відповідь на це запитання, і нарешті сьогодні опублікував підручник з CRC-32: Підручник з хешу CRC-32 - Спільнота AutoHotkey

У цьому прикладі я демонструю, як розрахувати хеш CRC-32 для рядка ASCII 'abc':

calculate the CRC-32 hash for the ASCII string 'abc':

inputs:
dividend: binary for 'abc': 0b011000010110001001100011 = 0x616263
polynomial: 0b100000100110000010001110110110111 = 0x104C11DB7

011000010110001001100011
reverse bits in each byte:
100001100100011011000110
append 32 0 bits:
10000110010001101100011000000000000000000000000000000000
XOR the first 4 bytes with 0xFFFFFFFF:
01111001101110010011100111111111000000000000000000000000

'CRC division':
01111001101110010011100111111111000000000000000000000000
 100000100110000010001110110110111
 ---------------------------------
  111000100010010111111010010010110
  100000100110000010001110110110111
  ---------------------------------
   110000001000101011101001001000010
   100000100110000010001110110110111
   ---------------------------------
    100001011101010011001111111101010
    100000100110000010001110110110111
    ---------------------------------
         111101101000100000100101110100000
         100000100110000010001110110110111
         ---------------------------------
          111010011101000101010110000101110
          100000100110000010001110110110111
          ---------------------------------
           110101110110001110110001100110010
           100000100110000010001110110110111
           ---------------------------------
            101010100000011001111110100001010
            100000100110000010001110110110111
            ---------------------------------
              101000011001101111000001011110100
              100000100110000010001110110110111
              ---------------------------------
                100011111110110100111110100001100
                100000100110000010001110110110111
                ---------------------------------
                    110110001101101100000101110110000
                    100000100110000010001110110110111
                    ---------------------------------
                     101101010111011100010110000001110
                     100000100110000010001110110110111
                     ---------------------------------
                       110111000101111001100011011100100
                       100000100110000010001110110110111
                       ---------------------------------
                        10111100011111011101101101010011

remainder: 0b10111100011111011101101101010011 = 0xBC7DDB53
XOR the remainder with 0xFFFFFFFF:
0b01000011100000100010010010101100 = 0x438224AC
reverse bits:
0b00110101001001000100000111000010 = 0x352441C2

thus the CRC-32 hash for the ASCII string 'abc' is 0x352441C2

Потім завжди є код Розетти, який показує, що crc32 реалізований на десятках комп'ютерних мов. https://rosettacode.org/wiki/CRC-32 і має посилання на багато пояснень та реалізацій.

Щоб звести crc32 до прийняття нагадування, вам потрібно:

1. Інвертувати біти на кожному байті
2. xor перші чотири байти з 0xFF (це для уникнення помилок на провідних 0)
3. Додайте відступ в кінці (це для того, щоб останні 4 байти взяли участь у хеші)
4. Обчислити нагадування
5. Знову змінити біти
6. xor результат знову.

У коді це:

func CRC32 (file []byte) uint32 {
    for i , v := range(file) {
        file[i] = bits.Reverse8(v)
    }
    for i := 0; i < 4; i++ {
        file[i] ^= 0xFF
    }

    // Add padding
    file = append(file, []byte{0, 0, 0, 0}...)
    newReminder := bits.Reverse32(reminderIEEE(file))

    return newReminder ^ 0xFFFFFFFF
}

де нагадуванняIEEE - це чисто нагадування на GF (2) [x]