Делаем отказоустойчивое файловое хранилище поверх JPEG-файлов

В сфере искусственного интеллекта произошло заметное событие. arabramov 21 минуту назад Делаем отказоустойчивое файловое хранилище поверх JPEG-файлов Простой 11 мин 509 Python * Обработка изображений * Информационная безопасность * Из песочницы TL;DR: Идея в том, чтобы использовать набор обычных JPEG-файлов в качестве распределённого носителя для зашифрованного контейнера. Данные разбиваются на избыточные фрагменты и распределяются между изображениями, благодаря чему контейнер может быть восстановлен даже после потери части JPEG-файлов. Мы не будем разбирать код, рассмотрим только общий принцип работы.

Откуда появилась идеяБольшинство стеганографических систем работают по схеме “одно изображение — один файл”. Если изображение потеряно или повреждено, встроенные данные теряются вместе с ним. Возникла идея: распределить контейнер с данными между множеством JPEG-файлов и при этом сохранить возможность восстановления данных после потери части этих файлов.

Технические детали

Сразу отмечу, что это не стеганография в классическом понимании. Дополнительные данные в JPEG-файлы мы будем записывать после маркера EOI (End Of Image), где они легко обнаруживаются при простейшем анализе. Суть не в том, чтобы полностью скрыть наличие данных, а в том, чтобы использовать обычные JPEG-файлы как распределённый носитель для зашифрованного контейнера.

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

Фотографии в этом формате естественным образом накапливаются на компьютерах и телефонах, пересылаются между людьми. Во-вторых, у этого формата есть одна особенность — JPEG заканчивается специальным маркером EOI. Всё, что записано после него, не участвует в декодировании изображения, поэтому дополнительные данные не влияют на отображение фотографии.

Отраслевые последствия

Именно эту область мы и будем использовать: JPEG JPEG Дополнительные данные EOI данные │ │ │ ... ░░░░░░░░░░░░░▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒ На первый взгляд решение выглядит предельно простым: достаточно разделить зашифрованный контейнер на фрагменты и записать по одному фрагменту в конец каждого JPEG-файла. Однако сразу возникает несколько вопросов.

Как понять, какие JPEG-файлы относятся к одному контейнеру? Как определить порядок фрагментов при сборке? Где хранить ключи шифрования?

Как сделать так, чтобы потеря любого отдельного JPEG-файла не делала контейнер невосстановимым? И как сделать весь JPEG-хвост неотличимым от случайного набора байтов? По ту сторону EOIЕстественным образом получается, что помимо самого фрагмента контейнера каждый JPEG-файл должен содержать два блока служебной информации: ключи шифрования и метаданные.

Событие, по словам экспертов, усилит конкуренцию в сфере ИИ.