CRC32 с кодом CRC внутри данных

Доброго времени суток форумчане!
Могу получить CRC32 (со стандартным полиномом 0xEDB88320), но как получить CRC32, контрольная сумма которого должна храниться внутри данных от которых эта контрольная сумма.

Рассчитав CRC32 и поместив ее во внутрь данных автоматически изменяю CRC32 всего этого блока. И так до бесконечности.
Как, например, имея блок данных в N байт ( > M), рассчитать и разместить контрольную сумму CRC32 с позиции M внутри этого блока данных в N байт?

0

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

0

Сообщение от Petrolion Т.е. имею проблему курица <-> яйцо.

Я эту проблему решил.
См. CRC32: Дополнить файл для получения контрольной суммы FFFFFFFF

0

Rius, Видел эту тему - заинтересовала. Эдакая имитовставка. Смысл вставки контрольной суммы теряется, т.к. она всегда одна и та же. Если в своих изысканиях ничего не добьюсь - именно этот вариант и рассматриваю. (Правда с осложнениями которые у меня возникнут при добавлении "лишних" данных) Но что делать, если в данные нельзя вставить ничего дополнительного?

Сообщение от ProgJ В том то и дело, что при проверке контрольной суммы её рассчитывают без учёта самой суммы. Т.е. при проверке сначала извлекают сохранённую контрольную сумму, данные теряют её, и тогда уже пересчитывают и сверяют

в обычной ситуации да, так и есть. При этом полный блок данных получается незащищенным. Т.е. можно изменить весь блок данных, пересчитать crc32 и вписать. И вот уже блок данных "правильный".

0

Сообщение от Petrolion Смысл вставки контрольной суммы теряется, т.к. она всегда одна и та же.

Вы не внимательно вчитались в тему. Повторяю, именно озвученную проблему я и решил.

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

Добавлено через 32 секунды
Но если совсем сдаётесь, поясню...

0

Сообщение от Petrolion При этом полный блок данных получается незащищенным

Чтоб защитить данные проще всего использовать архивирование с паролем. И защита, и место экономим

0

Поясните, где это понадобилось.
Файл на ПК или что?

0

Сообщение от Petrolion Rius в обычной ситуации да, так и есть. При этом полный блок данных получается незащищенным. Т.е. можно изменить весь блок данных, пересчитать crc32 и вписать. И вот уже блок данных "правильный".

Вот что бы сразу проблему не описать?
crc32 не является криптостойкой, поэтому не её основе "защищенный" блок не сделать.
Велосипед давно изобретен, используйте какой-нибудь современный алгоритм вычисления хеш-суммы https://ru.wikipedia.org/wiki/... 0%BC%D0%B0

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

1

Сообщение от Sindbad_M crc32 не является криптостойкой, поэтому не её основе "защищенный" блок не сделать.

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

0

Сообщение от Rius Вам большой привет из мира Embedded, где CRC вполне себе живёт и здравствует. И защищает, т.е. контролирует целостность, прошивки встроенного ПО и данных.

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

0

Sindbad_M, ТС ничего не утверждал о применении, это домыслы. На этот вопрос он ещё не ответил.

Добавлено через 2 минуты

Сообщение от Petrolion Т.е. можно изменить весь блок данных, пересчитать crc32 и вписать. И вот уже блок данных "правильный".

Хотя вот это можно понять по вашему. Согласен.

0

Rius, Вроде вашу тему понял (кстати, код действительно красиво написан), можно сделать ЛЮБОЙ CRC, т.е. зачем его записывать, если можно принять его в софте за константу (я не собираюсь искать коллизий к чужим данным, мне свои защитить). Мне неохота реализовывать криптоалгоритмы - большая и тратная по времени тема.
ProgJ, архивирование не годится - из-за изменения размера упакованных данных в зависимости от содержимого. (вектора не использую из-за дополнительных накладных расходов по памяти, динамические массивы размерами в гигабайты в памяти передвигать слишком затратно по куче параметров)
У меня есть данные которые могут храниться в виде файлов или передаваться в виде пакетов от программ клиентов. Данные - результат больших и ответственных расчетов. У этих данных определенная структура (где есть место под CRC32) и она неизменна. Мне нужно защитить блоки данных от: утечек (ошибок) памяти; сбоях при считывании с носителей; и самое главное подмене при передачи блоков от программ-клиентов. Потому как подмененные данные (если у них сохраняется правильная структура) могут порушить весь результат огромного времени расчетов.
Сами данные могут быть перехвачены. Главное не было бы подмены и сохранялась бы целостность. Лучше пересчитать один блок данных, чем получить неверный общий результат, основываясь на одном или нескольких "левых" блоках.
Данных много, расчеты "тяжелые", поэтому отнимать мощность процессоров и видеокарт на тяжелые криптоалгоритмы шифрования-дешифрования жалко. (Скорость доступа к "чистым" данным тоже немаловажна)
Потому думал разместить внутри данных КС с зависимостью от собственного значения. Если бы это уравнение можно было решить...
(Могу реализовать AES, но "быстрого" доступа к данным уже не получить)
Сейчас задумался, чтобы поле CRC32 использовать под ту самую 4 байтовую вставку для формирования постоянной КС. Но это также не защитит от подмены данных :-( (достаточно будет проанализировать 3-5 пакетов данных)

0

Сообщение от Petrolion можно сделать ЛЮБОЙ CRC, т.е. зачем его записывать, если можно принять его в софте за константу

Неееее, там не так. Это возможно, конечно, эффект только внешний в постоянном CRC.
Алгоритм был такой:

• получить исходный файл;
• подсчитать его оригинальную CRC;
• сохранить её внутри файла;
• восстановить файлу ту самую его оригинальную CRC.

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

1

Сообщение от Rius Алгоритм был такой: получить исходный файл; подсчитать его оригинальную CRC; сохранить её внутри файла; восстановить файлу ту самую его оригинальную CRC.

Верно, но это потребует дополнительных 4 байта в фиксированной структуре данных. А их нет. Можно их получить только используя само поле CRC32 (т.е. вместо него).

Сообщение от Rius В Вашем случае, раз стоит вопрос о подмене, выход, как заметил Sindbad_M, только в нормальной криптографии и подписях.

Боюсь придется разделить данные (со всеми вытекающими последствиями) на внутренние (доверенные) и внешние (недоверенные). Внешним делать инкапсуляцию в крипто (опять же - теряю производительность) и по получении их разворачивать.

0

Petrolion, Задача защиты от подмены передаваемого пакета - криптографическая задача, корректно решить её можно только криптографическими методами. Все что основано на crc порождает уравнения, сложность которых для вас и для злоумышленника одинакова.
Но, если беспокоитесь только об отдельных посылках, можно также считать контрольную сумму для нескольких посылок и при приеме проверять не только сумму посылки, но и дополнительные суммы блока посылок.

Любые вычисления требуют ресурсов, безусловно. Но проблемы реализации криптографии, как правило, сводятся к подключению в проект соответствующей библиотеки. Для популярных средств разработки все давно реализовано.

0

Сообщение от Sindbad_M Но, если беспокоитесь только об отдельных посылках, можно также считать контрольную сумму для нескольких посылок и при приеме проверять не только сумму посылки, но и дополнительные суммы блока посылок.

Думал об этом. Даже была мысль брать только КС нескольких блоков (плюс добавлять по желанию доп. хэши) отдельно делать шифрование в один пакет (для одного мелкого пакета затраты не так критичны). Но это потребует идентификации каждого блока данных. Этого сейчас нет. Они практически независимы (поэтому легко распараллеливаются).
Rius, пока обсуждали придумал куда можно применить ваш метод. Определенная часть данных "длительного" пользования (и не столь быстрого обращения) должна храниться в виде файлов на BD-ROM носителях. В структуре этих файлов предусмотрены тэги-затычки (для выравнивания по границам) вот в них то я и смогу затолкать эти "компенсаторы" КС. Так что спасибо еще раз!

0