Приписывание нулей - чтобы было из чего остаток набрать. Статья вам в помощь. В конце концов, возьмите свой любимый аппаратный вычислитель CRC, и сравните его результаты с вашими.
еще раз дам, а то и сам чуть нашел: http://electronix.ru/redirect.php?http://w...y/algo/crc1.pdf

Вы предупреждайте, что домножаете полином данных на X^4 перед тем, как его делить. С учетом этого - у Вас ошибки нет. И проверка работает, показывая, что было домножение на x^4 - я же ее Вам и сделал, получив 0x300 вместо ожидаемых 0x30. Но скрывать это не следует. Я честно делил полином данных на порождающий полином, без дополнительных операций по припискам нулей. Сразу можно говорить, что Вы выполняете дополнительную операцию - домножение на x^4 перед делением???? Это сверхсекретная информация, чтобы врага (меня) с толку сбить?

"Чтобы остаток набрать" - нули они приписали не для этого. Честно говоря, понятия не имею, зачем. Остаток вычисляется от ЛЮБОГО деления, с приписыванием, и без приписывания тоже. Возможно, домножение на x^4 сделано как раз для получения той самой однозначности, которой без этого домножения, при нахождении остатка в чистом его виде, и взятии 4-х бит от него, нет.

Причем тут вычислители CRC, когда спор чисто в математической области, про тупое деление двух полиномов - 0x30 (x^5+x^4) на 0x13 (x^4+x+1)

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

Вот как раз и я, и Вы делили согласно правилам полиномиального деления. Но я вычислял D(x) mod G(x), о чем честно и говорил. А Вы - (D(x)*x^4) mod G(x).
И поэтому у меня проверка показывала, что я делю правильно, получая в итоге проверки 0x30, а у Вас проверка показывала глюк - 0x300 - и, как оказалось, лишь потому, что Вы скрыли домножение на x^4.

Над блочными кодами не стоит долго размышлять. Берите XTEA - проще нету при приемлемой криптостойкости.

Конечно не было возможности всё прочитать, может уже предлагали, но если хочется задействовать встроенный ЦРЦ для шифрования, то делать нужно не так.
Его нужно просто использовать как генератор ПСП, и тупо ксорить данные с этим ПСП.
А вообще, если уж на то пошло, так в STM и AES тоже встроенный..

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

Для чего дополняем нулями данные при делении на полином для вычисления CRC. Мы получаем остаток от деления, который потом запишем на место этих нулей. И при проверке - делении данных вместе с CRC (опять дополняем нулями, чтобы каждый битик поучаствовал в делении) получим остаток 0.

С каких щей? "Ключом" к этому "шифру" может быть первое 32-бит слово, скормленное ЦРЦатору, а также то, что вы будете делать на следующей итерации: то ли просто подавать на ЦРЦатор результат первой итерации, то ли его предварительно ксорить с ещё каким-то "ключом".
А если вы будете "перемешивать биты", то вся эта идея коту под хвост, потому что перемешивание битов ресурсоёмко.

Зная, что используется встроенный блок CRC, только это первое слово и будет ключом. Вероятность подбора 2^32.

Что делать дальше - вопрос второй. Можно и без CRC запутать шпиона. Например, ксорить со следующим словом.
А перемешивать биты можно по-разному. Даже одной командой.
Можно CRC запустить X раз, прежде, чем использовать. Еще один "секрет".

Ну тогда 2-3-4 первых слова :-)))))))