Безопасность формата архива xz

Ища хороший вариант для хранения больших объемов данных (в основном из численных расчетов) в долгосрочной перспективе, я пришел к использованию xz формат архива (tar.xz). Сжатие по умолчанию LZMA обеспечивает значительно лучший размер архива (для моего типа данных) по сравнению с более распространенным tar.gz (оба с разумными вариантами сжатия).

Тем не менее, первый поиск Google на безопасность долгосрочного использования xz, прибыл на следующую веб-страницу (от одного из разработчиков lzip) который имеет название

Формат XZ не подходит для долгосрочного архивирования

перечисляя несколько причин, в том числе:

  • xz являющийся контейнерным форматом, в отличие от простых сжатых данных, которым предшествует необходимый заголовок
  • xz фрагментация формата
  • необоснованная растяжимость
  • плохой дизайн жатки и отсутствие защиты по длине поля
  • 4-байтовое выравнивание и использование отступов повсюду
  • невозможность добавить конечные данные в уже созданный архив
  • несколько вопросов с xz обнаружение ошибок
  • нет вариантов восстановления данных

Хотя некоторые проблемы кажутся немного искусственными, мне интересно, есть ли какое-то веское основание для того, чтобы не использовать xz как формат архива для долгосрочного архивирования.

Что меня должно беспокоить, если я выберу xz как формат файла? (Я думаю, доступ к xz Сама программа не должна быть проблемой даже через 30 лет)

пара заметок:

  • Сохраненные данные являются результатами численных расчетов, некоторые из которых публикуются в различных конференциях и журналах. И хотя сохранение результатов не обязательно подразумевает воспроизводимость исследований, это важный компонент.
  • При использовании более стандартного tar.gz или даже просто zip может быть более очевидный выбор, мне очень нравится возможность вырезать около 30% размера архива.
Источник

3 ответа

Решение

Если вы внимательно прочитаете страницу, на которую вы ссылаетесь, вы найдете такие вещи: https://www.nongnu.org/lzip/xz_inadequate.html

"Спецификация формата xz устанавливает более строгие требования к целостности заполнения, чем к целостности полезной нагрузки. Спецификация не гарантирует, что целостность распакованных данных будет проверена, но она требует, чтобы декомпрессия должна была быть прекращена, как только как найден поврежденный байт заполнения."

В каком сжатом формате выполняется любое из следующих действий?

  • Использует прокладку.
  • Защищает набивку с помощью CRC.
  • Отменяется, если заполнение повреждено.
Источник

Если целостность и избыточность обеспечиваются на другом уровне (например, файловой системе), я не вижу реальных аргументов против использования , так как он обеспечивает гораздо лучшее сжатие, чемzipилиtar.gz.

Многие аргументы можно довольно легко опровергнуть :

Например, кого волнует, есть ли в формате возможности для расширений 2^63. Это просто потому, что автор использовал int64_t в качестве типа данных — это не значит, что их БУДУТ так много, просто они выбрали большой тип данных.

Целые числа переменной длины тоже подходят. Они не вызывают проблем (если защищены контрольными суммами) и приводят к уменьшению размера файлов. Почему бы вам не воспользоваться такой вещью? Это действительно может привести к ошибкам кадрирования, когда неспособность декодировать одно поле также приводит к сбою следующего, но добро пожаловать в сжатие! Это верно почти для каждого потока, и именно поэтому контрольные суммы имеют значение.

Поврежденное поле длины сообщения (2,5 Xz не может защитить длину полей переменного размера ) будет указывать на неправильную CRC и, следовательно, станет очевидным как несоответствие CRC и, следовательно, обнаружение нарушения целостности (с высокой вероятностью).

Самым важным аргументом будет неточность распакованных данных в разделе 2.10.4 Поле «Проверка блока» . Однако не указано, почему, например, «SHA-256 обеспечивает худшую точность, чем CRC64 для всех возможных размеров блоков», поскольку формула не объясняется. Хотя SHA-256 не предназначен в первую очередь для обнаружения ошибок, он обеспечивает, по крайней мере, защиту от коллизий в зависимости от длины хеша :

Следует помнить, что, в отличие от CRC, где определенные типы ввода с большей или меньшей вероятностью приведут к конфликту (при этом определенные типы ввода имеют вероятность возникновения конфликта 0%), фактическая вероятность коллизий для ввода криптографический хеш является функцией только длины хеша.

Однако вероятность коллизии SHA-256 ниже 2^-128, поэтому даже если принять во внимание все возможные значения файла размером 1 ГБ (1073741824 байт = 2 ^ 30 байт = 2 ^ 30 * 8 бит = 2 ^ 30 * 2^3 бит = 2^33 бита) оставляет запас безопасности в 95 бит (вероятность коллизии 2^-95 = 10^-(95 * ln(2) / ln(10)) = 10^-28,6 ), что весьма хорошо и намного меньше, чем 3*10^-8, показанное на графике.

[ Обновление: автор статьи объясняет это здесь , указывая, что для целей архивирования оптимальным решением является компромисс между целостностью и доступностью, который является разумным и соответствует современной научной литературе [Купман, с. 33] .]

Если данные были сжаты с использованием xzс настройками по умолчанию (предустановленный уровень сжатия 6 и т. д.) в будущем его можно будет без проблем распаковать.

Сказав это, использование действительно может быть лучшим решением. Хотя проблемы, упомянутые в статье, могут возникать редко, они все же могут возникнуть. Концепция lzip на первый взгляд выглядит более убедительно, а использование высочайшего уровня сжатия позволяет lzip -9дает лучшие результаты, чем xz -9и zstd -19(Я использовал barcode-0.99.tar и Calgary.tar ; см. также Lzip сжимает архивы больше, чем xz.)

Исправление ошибок Рида – Соломона, используемое вpar2для обеспечения избыточности и целостности в основном используется для передачи (радио, ТВ) и автономных данных (CD). Для онлайн-хранилища (жесткие диски) я бы предпочел файловую систему ZFS с зеркальными дисками/дисками четности для обеспечения избыточности и регулярной очистки целостности, а также автономную копию (резервную копию).

Источник

Может быть, правильный вопрос таков: "есть ли веские основания для использования такого плохо разработанного формата, как xz, для долгосрочного архивирования, когда существуют правильно разработанные форматы?"

Например, база данных часовых поясов IANA использует gzip и lzip для распространения своих архивов, которые хранятся в архиве навсегда. http://www.iana.org/time-zones

Источник
Другие вопросы по тегам