Что такое «магическое число» (0xdebb20e3) в APPNOTE pkzip?

Это дополнение к CRC-32 исходного сообщения, любого исходного сообщения, к которому добавляется CRC-32 в порядке прямого порядка байтов.

Итак, если я возьму девятибайтовое сообщение, состоящее из цифр ASCII «123456789», я получу 0xcbf43926. Если затем я возьму 13-байтовое сообщение «123456789», за которым следуют четыре байта 0x26 0x39 0xf4 0xcb, CRC в порядке с прямым порядком байтов, я получу 0x2144df1c. Дополнением к этому является 0xdebb20e3.

Это константа для любого определения CRC и называется «остатком». Вы можете найти его в описании этого CRC здесь (прокрутите вправо до конца строки):

width=32 poly=0x04c11db7 init=0xffffffff refin=true refout=true xorout=0xffffffff check=0xcbf43926 residue=0xdebb20e3 name = "CRC-32/ISO-HDLC"

Остаток — это окончательное содержимое регистра CRC перед последним исключающим «или», которое для этого CRC равно 0xffffffff, отсюда и дополнение. Этот CRC добавляется к сообщению в порядке с прямым порядком байтов, поскольку он отражен (refin=true и refout=true).

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

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