Есть ли backdoor's в шифровании архиваторами?
В частности интересен в этом плане свободный .7z, а также реализация шифрования в нём же при сжатии в формат .zip (там кажется есть выбор из двух типов возможного алгоритма шифрования).
Вопрос возник в основном потому, что в руководствах по Linux, написанных иностранными авторами, 7-zip в качестве средства шифрования практически не упоминается.
Из чего я для себя сделал вывод, что бэкдоры в 7-Zip МОГУТ быть. Или я не прав?
комментариев: 11558 документов: 1036 редакций: 4118
Почему вообще в качестве средства шифрования кто-то должен приводить архиватор? У всякой программы есть основное назначение, задача, которую она призвана решать; помимо этого может быть ряд дополнительных функций, упрощающих решение задачи или решающих сопутствующие. Ресурсы разработчика не безграничны, и на реализацию основного функционала уходит основное внимание, время и силы, на второстепенный же функционал — в меру возможностей. Реализация криптографических функций требует предельного внимания и компетенции, и разработчик архиватора может не располагать ни тем, ни другим просто по той причине, что надёжное шифрование — далеко не основная задача приложения. Отсюда возможные ошибки, которые могут оказаться фатальными даже без намеренных бэкдоров.
Вывод, очевидно, натянутый.
комментариев: 9796 документов: 488 редакций: 5664
Потому что /comment9044. Исторически, в Unix-системах даже архиватор (программа, собирающая много файлов в один поток для записи на стриммер) и программа сжатия — это две разные программы, которые существовали раздельно, а использовались вместе через конвейер.
Встраивание шифрования непосредственно в файловые системы тоже не прижилось, поэтому его разрабатывают отдельно и применяют отдельным ниже- или вышележащим слоем.
Чем берёт rar:
Шифрование в обычном zip взламывается ⇒ не вариант сразу. Если бы не этот факт, zip был бы неплох. Он умеет шифровать названия файлов и директорий, а также поддерживает требование 4 (не так удобно, как rar, но всё же: см. zip -F и zip -FF).
Можно было бы воспользоваться тем типом zip, который создаёт 7z, т.е. 7z -tzip. В этом случае можно принудительно выбрать AES256 как метод шифрования. Казалось бы, всё хорошо! Но тут требование 4 сразу же перестаёт работать, zip категорически отказывается фиксить недокачанные архивы. Более того, при использовании шифрования AES256 формат запрещает шифровать имена файлов (-mhe). Можно было бы извратиться с первичным запаковываеним в обычный zip с нейтральным именем, а потом его пихать в zip с AES-шифрованием, но фикса недокачанного файла не будет. Особенно это чувствительно, когда архивы большие и разбиты на несколько томов. Короче, zip с AES256 тоже не вариант.
Обычный 7z в целом хорош, но он не поддерживает частичное расшифрование файла ни в каком виде. Разработчик мог бы это добавить к себе в тулзу, но он этого не сделал. Вопрос, конечно, чисто технический — сделать это можно, просто готовых инструментов нет. Если вы будете гуглить, как расшифровать обрезанный 7z-архив, вы наткнётесь на инструкции «создайте ещё один архив с таким же объёмом данных, скопируйте заголовки, поработайте в 16-ричном редакторе...». Одним словом, если это вопрос жизни и смерти, то это делается, иначе — ну его нафиг.
Интересно, что 7z агрессивно не поддерживает частичное расшифрование: если скачаны первые несколько volume'ов архива полностью, это всё равно не поможет. 7z даже пытаться не будет это расшифровать. Ему нужно в обязательном порядке иметь все копии и желательно совпадающие по всем контрольным суммам. Я всё же нашёл один хак, позволяющий слегка обуздать 7z: качаем первый том и последний, после этого второй и следующие тома (в предположении, что размер у них такой же, как у первого — не знаю, всегда ли это так) можно создать как формальные копии первого. 7z при этом поругается, но первый том разархивирует и расшифрует. Правило естественным образом обобщается на первые n томов: если они скачаны, недостающие тома создаём руками как копии n-го скачанного тома + даём ему валидный последний том. Это позволяет расшифровать первые n томов.
Про частичное расшифрование PGP-шифрованных файлов я никогда не слышал. Есть ли готовые тулзы для этого? Очень сомневаюсь.
Вообще, у меня есть стойкое впечатление, что все архиваторы писали кулхацкеры. Документация по ним странная, часто скудная и даже неполная. Возьмите классику: zip. Там нет листинга опций с их значениями как в обычных man-страницах, вместо этого вам дают цельный текст, в котором вы должны выискивать, где упомянуты те или иные ключи/опции.
Или вот 7z -p взять... тоже странный мануал. В нём нигде не упомянуто, что шифруется с помощью AES256. Я нашёл несколько клятвенных заверений на форумах, что это так, причём по умолчанию. Однако, на сайте об этом в лоб не сказано. Пишут, что алгоритм в документации не указан просто потому, что выбора нету — там всего один алгоритм. Точнее, там всё ещё хитрее: выбора нет, только если -t7z, что по умолчанию подразумевается, а если у вас -tzip (или что-то ещё?), то выбор есть! И это сильно путает. Честно, я не знаю, почему ни в man, ни в таблицах-спеках на сайте 7z это не отражено. На заглавной странице, правда, утверждается, что 7z поддерживает стойкое шифрование с помощью AES256, но там не сказано, что это так по умолчанию. Т.е. то, что это умолчание, я должен самостоятельно вывести из двух фактов: 1) 7z поддерживает AES256 и 2) Для типа 7z не указаны альтернативы для выбора алгоритма. Это полный дурдом.
Судя по формату опций, автор 7z клонировал rar. Привыкнуть можно, но это выглядит несколько нетрадиционно. Наверное, все, кто пытались освоить 7z, на себе чувствовали, что «непонятно».
И всё-таки возвращаясь к главному вопросу — пункту 4: если кто не понял, то, допустим, я качаю фильм. Он качается долго, с обрывами и сложностями. Если скачка оборвётся в последний момент, мне его придётся качать заново, я его не расшифрую. И чем больше архивы и нестабильнее связь, тем больше нервов при работе с 7z. А, может быть, я бы хотел скачать начало и потом смотреть, стоит ли качать дальше? С rar это можно, с 7z — нет. Всё, кстати, многократно веселей, если файл скачивается через TBB — там ведь нет докачки, и любой обрыв фатален. К тому же, файл часто заливают в такое место, которое вообще не дружит с докачкой (сервису это невыгодно), поэтому даже если вы исхитритесь подсунуть ровно ту же ссылку, по которой качалось, wget'у, это не поможет. Если помимо фильмов у вас идёт работа с бэкапом в 7z, где много файлов, будет та же проблема: обрыв — и вы уже не можете оттуда извлечь ни одного файла.
Теперь, надеюсь, всем понятно, почему rar пока что так повсеместно распространён (особенно для вареза и пиратки), и у него в ближайшем будущем не предвидится альтернатив? Мне кажется, никто даже не осознаёт суть проблемы. Здесь я не буду говорить про порог вхождения в PGP и сложности с гуями для юзеров — это само по себе очевидно. Многие вещи с PGP-файлами, как и ранее, проще всего решаются в командной строке, даже если это винда (гуёвые оболочки часто глючат, даже если соответствующий функционал в них в принципе заявлен). И теперь представьте картину: обычному виндузятнику объясняют, что надо зайти в комстроку Windows (о существовании которой он не подозревает) и там набрать какую-то длинную магическую команду для работы с этим тулом. Куда он вас пошлёт? Мотивированные, сознательные пользователи — это одно, они ещё поймут, зачем нужны такие жертвы, но массы этого не примут. Массам нужно удобство и работа с программой в один клик: скачал → запустил → уже рут.
Ах да, забыл бессмертное: реакция 7z на ошибку в опциях или указание несовместимых опций — написать «ошибка», и всё на том. Никаких деталей. Пусть юзер сам думает, что ему не нравится и почему. Автор софта явно решил не усложнять себе жизнь грамотной диагностикой проблем.
комментариев: 9796 документов: 488 редакций: 5664
Для упрощения задачи, когда эти утилиты отлажены в совместной работе, их можно было бы объединить и реализовать в упрощённый стандарт совместного использования и создать на этой почве комбайн — архиватор с набором библиотек. Такой архиватор можно было бы портировать и под Windows, и под остальное, сделать там гуй и кнопку «всё хорошо».
Если придерживаться стандарта, то особо фанатичные пользователи unix-подобных систем могли бы разбирать такие архивы отдельными командами. Только создавать юзерофильную прогу, да ещё и по продуманному стандарту — никому пока не интересно.
Чё?! Людям просто надо выполнять свои задачи.
А компы и программеры должны прогнуться и сделать то, за что люди готовы платить и так, чтобы людям этим было удобно пользоваться. Потому что желающий получить деньги за схожий функционал довольно много и потому конкуренция.
Юникс вей устарел настолько же, насколько с его появления сменилась аудитория пользователей компьютеров. Иначе говоря, кардинально.
Мнение админов и продвинутых компьютерщиков никого не волнует. Они ни что, а вот кто платит, тот и заказывает музыку.
2.
Потому что все вместе взятые юниксы — это менее 5% десктопов и ноутбуков в мире. Так оно потому, что см.п.1
Это аутисты стремятся выдумать свод правил и всеми силами их придерживаться. Впадая в истерику, когда им этого делать не дают или рассказывают, что есть другие варианты.
комментариев: 9796 документов: 488 редакций: 5664
Некоторые впадают в истерику, когда могут предложить деньги, а им уже отказываются что-то продавать. Качество программ во многих областях, особенно связанных с криптографией, если и оплачивается какими-то деньгами, то не рядовых пользователей — покупателей поштучных копий. Безопасность не монетизируется, даже продажей удобных интерфейсов и консультативных услуг.
Даже если они миллиардеры — их мнение само по себе никого не интересует. Чисто рыночно-денежные отношения во многих сферах уже не работают, по крайней мере не определяют качество программного продукта. Конкуренция за деньги и спрос со стороны массового покупателя это качество может и ухудшить.
Что и происходит, на примере Firefox. Разменяли безопасность, которой врочем там особо и не было, на деньги от продажи пользовательской аудитории гуглу и прочим рекламщикам.
Если вы когда-нибудь что-нибудь качали с файлопомоек, то поймёте о чём я. Качают миллионы людей по миру. И там практически всё в архивах, чтоб не тёрли. Часто с паролем. Если даже это не достаточный аргумент, то я не знаю...
Хорошо. Пусть я — «немасса». Расскажите мне, как расшифровать частично скачанный файл, который зашифрован с помощью той же gpg. Что, например, будет делать gpg -o file.out -d file.gpg, если file.gpg обрезан?
комментариев: 9796 документов: 488 редакций: 5664
Нужно определиться, для чего это аргумент. Есть архиваторы и есть криптосистемы. Заголовок темы вообще про бэкдоры был. Речь о том, что rar единственный может расшифровать свои обрезанные зашифрованные архивы? Ну ок, значит так.
Не пройдет проверку целостности и выдаст decryption failed.
Вменяемыми способами, полагаю, никак, ибо
Одно из требований к криптосистеме – проверка целостности данных.
Типа софт должен быть бесплатным и все должны в ножки кланятся программерам, а чтобы этот самый софт было кому писать — узера должны учиться ходить строем и делать "ку" программерам.
Пристально смотрим в сторону rar'а и сравниваем его с 7zip.
кто из них платный и живёт с продаж конечным пользователям, а кто опенсорсная поделка оставляющая желать лучшего по функционалу?
а шифрование в них обоих как раз и позволяет очень многим людям в мире реализовывать для себя определённую безопасность.
А кто говорил, что монетизируется? сам завёл об этом речь, сам же и опроверг.
Типичные сопли технаря не имеющего ничего за душой, кроме распухшего эго и уверенности в собственной значимости.
Практически все деньги в мире уже давно фиатные — имеют сами по себе нулевую ценность. А значение и оборот лишь в силу того, что кто-то взял их в долг, т.е. обязался работать в обмен на них.
И потому люди меняют на софт отнюдь не какие-то товары, имеющие ценность сами по себе(типа злата\серебра), а количество человеко-часов рабочего времени. Либо деньгами, либо в натуральном виде — времени затрачиваемым на неудобные или кривые интерфейсы и абы как реализованную функциональность.
"free software is not free", как бы этого кому-то там ни хотелось бы.
Потому хватит уже передёргивать и фантазировать.
Шифрование в архиваторе используется
Целостность вторична. Могли бы вообще не архивировать и не шифровать, но тогда, во-первых, были бы большие утечки в паблик, а, во-вторых, файлы бы сносили молниеносно. Это имеет мало общего с целями шифрования двустороннего канала, защищённого от прослушки третьими лицами. Это скорее защищённый от цензуры broadcasting.
Если к обрезанному файлу можно прикрепить проверку целостности, я только за, но главное, чтоб оно функционально работало, прежде всего. Шифруется файл всё равно поблочно, раз там блочный шифр. Никто не запрещает добавлять в заголовок контрольные суммы групп блоков.
По сути да. И это всё равно плохо, потому что rar — не открытый/свободный софт.
Александр Рошаль вовремя уловил тенденцию и встроился в рынок. Другие не уловили. До сих пор не улавливают. Добавьте функционал раровской опции -kb к 7z, и разговор на эту тему уже б не состоялся, но не тут-то было...
Всё как обычно: вначале говорят, что фича не нужна. Когда фичу добавят, будут говорить, что она там реально необходима. А потом перестанут понимать, как они жили без этой фичи.