Длина данных по сравнению с продолжительностью CRC
Я видел 8-разрядный, 16-разрядный, и 32-разрядный CRCs.
В какой точке я должен перейти к более широкому CRC?
Моя реакция пищеварительного тракта состоит в том, что это основано на длине данных:
- 1-100 байтов: 8-разрядный CRC
- 101 - 1 000 байтов: 16-разрядный CRC
- 1001-??? байты: 32-разрядный CRC
Править: Рассмотрение страницы Wikipedia о CRC и ответе Lott, здесь', что мы имеем:
<64 байта: 8-разрядный CRC
<16K байты: 16-разрядный CRC
<512M байты: 32-разрядный CRC
3 ответа
Это не тема исследования. Это действительно хорошо понятно: http: // en .wikipedia.org / wiki / Cyclic_redundancy_check
Математика довольно проста. 8-битная CRC сводит все сообщения к одному из 256 значений. Если ваше сообщение длиннее нескольких байтов, вероятность того, что несколько сообщений будут иметь одно и то же значение хеш-функции становится все выше и выше.
16-битный CRC, аналогично, дает вам одно из 65 536 доступных значений хеш-функции. Каковы шансы любых двух сообщений, имеющих одно из этих значений?
A 32- бит CRC дает вам около 4 миллиардов доступных значений хэша.
Из статьи в Википедии: «максимальная общая длина блока равна 2 ** г - 1 ". Это в битах. Вам не нужно проводить много исследований, чтобы увидеть, что 2 ** 9 - 1 составляет 511 бит. При использовании CRC-8 несколько сообщений длиной более 64 байтов будут иметь одинаковое значение контрольной суммы CRC.
CRC должен быть выбран специально для длины сообщений, это не просто вопрос размера CRC:http://www. ece.cmu.edu/~koopman/roses/dsn04/koopman04_crc_poly_embedded.pdf
Я думаю, что размер CRC больше связан с тем, насколько уникален CRC, который вам нужен, а не с размером входных данных. Это связано с конкретным использованием и количеством элементов, для которых вы вычисляете CRC.