Есть ли backdoor's в шифровании архиваторами?
В частности интересен в этом плане свободный .7z, а также реализация шифрования в нём же при сжатии в формат .zip (там кажется есть выбор из двух типов возможного алгоритма шифрования).
Вопрос возник в основном потому, что в руководствах по Linux, написанных иностранными авторами, 7-zip в качестве средства шифрования практически не упоминается.
Из чего я для себя сделал вывод, что бэкдоры в 7-Zip МОГУТ быть. Или я не прав?
Ссылки
[link1] https://www.pgpru.com/comment9044
[link2] https://www.pgpru.com/comment2867
[link3] https://en.wikipedia.org/wiki/Parchive
[link4] https://www.linux.org.ru/forum/talks/6505575
[link5] https://ru.wikipedia.org/wiki/Рошал,_Евгений_Лазаревич
[link6] https://www.pgpru.com/comment81600
[link7] https://www.pgpru.com/comment81490
[link8] https://www.pgpru.com/comment81581
[link9] https://www.pgpru.com/comment81115
Почему вообще в качестве средства шифрования кто-то должен приводить архиватор? У всякой программы есть основное назначение, задача, которую она призвана решать; помимо этого может быть ряд дополнительных функций, упрощающих решение задачи или решающих сопутствующие. Ресурсы разработчика не безграничны, и на реализацию основного функционала уходит основное внимание, время и силы, на второстепенный же функционал — в меру возможностей. Реализация криптографических функций требует предельного внимания и компетенции, и разработчик архиватора может не располагать ни тем, ни другим просто по той причине, что надёжное шифрование — далеко не основная задача приложения. Отсюда возможные ошибки, которые могут оказаться фатальными даже без намеренных бэкдоров.
Вывод, очевидно, натянутый.
Потому что /comment9044[link1]. Исторически, в Unix-системах даже архиватор (программа, собирающая много файлов в один поток для записи на стриммер) и программа сжатия — это две разные программы, которые существовали раздельно, а использовались вместе через конвейер.
Встраивание шифрования непосредственно в файловые системы тоже не прижилось, поэтому его разрабатывают отдельно и применяют отдельным ниже- или вышележащим слоем.
Если немного спуститься с небес на землю и попытаться посмотреть на вопрос глазами не только криптографа, но и потребителя, то всё совсем ужасно: у rar толком нет альтернатив.
Чем берёт 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 на ошибку в опциях или указание несовместимых опций — написать «ошибка», и всё на том. Никаких деталей. Пусть юзер сам думает, что ему не нравится и почему. Автор софта явно решил не усложнять себе жизнь грамотной диагностикой проблем.
На windows всю жизнь использовал 7zip, дабы он умеет распаковывать и rar в том числе, если надо упаковать для других простых людей – пакую в zip, для себя в 7z. Какие глубокие проблемы? У вас в тексте я увидел две – неподдерживание недокачанных архивов и нестойкое шифрование. Первое вообще фича, никто не говорил, что это должно быть реализовано. Второе "массам" вообще не нужно, а "немассы" и так разберутся и никогда архиватор для шифрования использовать не будут.
Архивация, сжатие, разбиение на тома, избыточное кодирование для исправления ошибок и шифрование — пять разных задач. Если делать юниксвейно, то это должны быть 5 разных утилит, объединяемых в комстроке через конвейер.
Для упрощения задачи, когда эти утилиты отлажены в совместной работе, их можно было бы объединить и реализовать в упрощённый стандарт совместного использования и создать на этой почве комбайн — архиватор с набором библиотек. Такой архиватор можно было бы портировать и под Windows, и под остальное, сделать там гуй и кнопку «всё хорошо».
Если придерживаться стандарта, то особо фанатичные пользователи unix-подобных систем могли бы разбирать такие архивы отдельными командами. Только создавать юзерофильную прогу, да ещё и по продуманному стандарту — никому пока не интересно.
1.
Чё?! Людям просто надо выполнять свои задачи.
А компы и программеры должны прогнуться и сделать то, за что люди готовы платить и так, чтобы людям этим было удобно пользоваться. Потому что желающий получить деньги за схожий функционал довольно много и потому конкуренция.
Юникс вей устарел настолько же, насколько с его появления сменилась аудитория пользователей компьютеров. Иначе говоря, кардинально.
Мнение админов и продвинутых компьютерщиков никого не волнует. Они ни что, а вот кто платит, тот и заказывает музыку.
2.
Потому что все вместе взятые юниксы — это менее 5% десктопов и ноутбуков в мире. Так оно потому, что см.п.1
Это аутисты стремятся выдумать свод правил и всеми силами их придерживаться. Впадая в истерику, когда им этого делать не дают или рассказывают, что есть другие варианты.
Некоторые впадают в истерику, когда могут предложить деньги, а им уже отказываются что-то продавать. Качество программ во многих областях, особенно связанных с криптографией, если и оплачивается какими-то деньгами, то не рядовых пользователей — покупателей поштучных копий. Безопасность не монетизируется, даже продажей удобных интерфейсов и консультативных услуг.
Даже если они миллиардеры — их мнение само по себе никого не интересует. Чисто рыночно-денежные отношения во многих сферах уже не работают, по крайней мере не определяют качество программного продукта. Конкуренция за деньги и спрос со стороны массового покупателя это качество может и ухудшить.
Что и происходит, на примере Firefox. Разменяли безопасность, которой врочем там особо и не было, на деньги от продажи пользовательской аудитории гуглу и прочим рекламщикам.
Если вы когда-нибудь что-нибудь качали с файлопомоек, то поймёте о чём я. Качают миллионы людей по миру. И там практически всё в архивах, чтоб не тёрли. Часто с паролем. Если даже это не достаточный аргумент, то я не знаю...
Хорошо. Пусть я — «немасса». Расскажите мне, как расшифровать частично скачанный файл, который зашифрован с помощью той же gpg. Что, например, будет делать gpg -o file.out -d file.gpg, если file.gpg обрезан?
Шифрование без аутентификации? Без контроля целостности? С несовпадающей подписью или контрольной суммой? Не нужно же.
Нужно определиться, для чего это аргумент. Есть архиваторы и есть криптосистемы. Заголовок темы вообще про бэкдоры был. Речь о том, что rar единственный может расшифровать свои обрезанные зашифрованные архивы? Ну ок, значит так.
Не пройдет проверку целостности и выдаст decryption failed.
Вменяемыми способами, полагаю, никак, ибо
Одно из требований к криптосистеме – проверка целостности данных.
Типа софт должен быть бесплатным и все должны в ножки кланятся программерам, а чтобы этот самый софт было кому писать — узера должны учиться ходить строем и делать "ку" программерам.
Пристально смотрим в сторону rar'а и сравниваем его с 7zip.
кто из них платный и живёт с продаж конечным пользователям, а кто опенсорсная поделка оставляющая желать лучшего по функционалу?
а шифрование в них обоих как раз и позволяет очень многим людям в мире реализовывать для себя определённую безопасность.
А кто говорил, что монетизируется? сам завёл об этом речь, сам же и опроверг.
Типичные сопли технаря не имеющего ничего за душой, кроме распухшего эго и уверенности в собственной значимости.
Практически все деньги в мире уже давно фиатные — имеют сами по себе нулевую ценность. А значение и оборот лишь в силу того, что кто-то взял их в долг, т.е. обязался работать в обмен на них.
И потому люди меняют на софт отнюдь не какие-то товары, имеющие ценность сами по себе(типа злата\серебра), а количество человеко-часов рабочего времени. Либо деньгами, либо в натуральном виде — времени затрачиваемым на неудобные или кривые интерфейсы и абы как реализованную функциональность.
"free software is not free", как бы этого кому-то там ни хотелось бы.
Потому хватит уже передёргивать и фантазировать.
Шифрование в архиваторе используется
Целостность вторична. Могли бы вообще не архивировать и не шифровать, но тогда, во-первых, были бы большие утечки в паблик, а, во-вторых, файлы бы сносили молниеносно. Это имеет мало общего с целями шифрования двустороннего канала, защищённого от прослушки третьими лицами. Это скорее защищённый от цензуры broadcasting.
Если к обрезанному файлу можно прикрепить проверку целостности, я только за, но главное, чтоб оно функционально работало, прежде всего. Шифруется файл всё равно поблочно, раз там блочный шифр. Никто не запрещает добавлять в заголовок контрольные суммы групп блоков.
По сути да. И это всё равно плохо, потому что rar — не открытый/свободный софт.
Александр Рошаль вовремя уловил тенденцию и встроился в рынок. Другие не уловили. До сих пор не улавливают. Добавьте функционал раровской опции -kb к 7z, и разговор на эту тему уже б не состоялся, но не тут-то было...
Всё как обычно: вначале говорят, что фича не нужна. Когда фичу добавят, будут говорить, что она там реально необходима. А потом перестанут понимать, как они жили без этой фичи.
Сама по себе фича существует с тех времён, когда веб-файлопомоек не было вообще, а интернет был по звуковым модемам, пользовалась ограниченной популярностью при рассылке пиратского контента в ньюс-группах. До сих пор как-то развивается в Parchive[link3]. Никогда не возникало интереса к его использованию, но если бы было надо, то можно было бы нагородить комбайн из tar, par и gpg.
Возможно, что вы качаете/распространяете какое-то многогиговое непотребство (в плане размеров файлов, на содержимое пофиг) через Tor, поэтому вам нужно и слабенькое шифрование, и многотомность, и защита от ошибок при разрывах. Это специфический набор требований — попытка подстроиться под существующую среду, вместо того, чтобы сформулировать задачу в общем виде: построить стойкую анонимную непрослушиваемую сеть с возможностью броадкастингового обмена информацией.
Опять двадцать пять, по части передёргиваний.
Формулировать надо сперва модель угроз в условиях существующей среды. После этого переходить к выстраиванию процесса. Поскольку безопасность не является продуктом или производной какого-то средства.
Но непонятно, как это связано с Parchive. И как вы предствляете конвеер с parchive и 7z? Что поверх чего, как бы это выглядело?
Там, похоже, в другом идея: защита от произвольных повреждений. Здесь же речь идёт об обработке исключительно обрезанных архивов. У нас нет желения делать избыточное кодирование и прочие тонкости, достаточно расшифровывать/разархивировать то, что получается.
Достаточно десятков или сотен мегабайт, которые качаются со скоростью в 10kB/s.
Это было бы слишком. Если исходить из реальности, пока есть только 2 относительно надёжных сети: Tor и Freenet, всё остальное нанизывается на них.
Как можно передёргивать то, что вообще никак внятно не сформулировано?
Никто вообще ничего толком не объяснил: некто хочет, чтобы была реализована какая-то опция, по принципу «чего изволите, любой каприз за ваши деньги», даже не потрудившись разъяснить в общем виде — зачем? Приходиться гадать телепатически. Ну, извините, не угадал, бывает.
Я иногда что-то качал с файлопомоек, и даже шифрованное, но с проблемой битых файлов не разу не сталкивался. Мне битые и недокачанные файлы не нужны в принципе. Мне важно чтобы было зашифровано так надёжно, чтобы не могли умышленно обрезать файл или подменить хоть один бит без знания ключа. Может кто-то видео качает, где это всё не так важно, надо опять гадать? Чтобы неугаданные предположения зачислили в передёргивания?
А когда это Евгений превратился в Александра?
Про winrar, кстати, ответ на вопрос по теме будет такой: неизвестно, проверить сложно. Основания утверждать, что схема шифрования надёжна, отсутствуют. Основания утверждать, что схема шифрования ненадёжна, также отсутствуют.
Здесь должна быть картинка "кто-то купил полную версию winrar". ;)
Чё за детский сад? Чел же изложил всё очень детально и подбробно.
Ему нужна возможность работы с шифрованными данными на нестабильных каналах связи. В условиях, когда передача сообщения обывается из-за проблем в протоколах транспортного уровня.
Это могут радиопомехи или потерян луч спутника — не важно что это.
В тоже время, важен результат, который должен быть достигнут. А именно возможность расшифровать ту часть сообщения, которая была получена. Будучи уверенным, что та часть, которую удалось получить не была повреждена.
Потому что проблемы в протоколе транспортного уровня не обязательно являются форс-мажором, а могут быть вызваны действиями атакующего.
Т.е. в описании модели угроз проставлено, что атакующий не может произвести подмену транслируемого сообщения. Может лишь повредить его до такой степени, что передача прервётся. А то что удалось принять потенциально может оказаться повреждено.
И на основании этого описания, чел проводит сравнение существующих ныне средств. Пригодных к использованию определённым образом, т.е. согласно некоторому сценарию действий из множества доступных принимающей стороне.
Это классический вариант практического применения криптографической защиты в условиях активного противодействия. Со стороны какой-то неодушевлённой силы или же лица наделённого умыслом.
Unknown, в самом же первом посте, чёрным по белому:
Если это не объяснение, то что есть объяснение?
Оговорился, в моей памяти нет системы исправления ошибок...Ан-нет, всё тоньше: не превратился, а создал клона[link4] от своей матери.Да, но есть один косвенный аргумент: unrar открыт и опунесорсен, для расшифрования он действительно использует AES. Конечно, это не страхует от специфических багов/бэкдоров в самом rar, которй архивирует и шифрует, а не распаковывает.
Извиняюсь, пост был объёмный, я пропустил этот абзац. И пост[link7] — третий по счёту, не считая заголовочного.
Если вас интересует только эта задача, то всё примерно так:
Честно говоря, видео под руками не было. Была JPEG-картинка на 150 кб. Отрезал где-то первую треть — первые 50 кб. При расшифровке получился файл, в точности до байта совпадающий с исходным размером — 150 кб. Скорее всего, размер исходного сообщения сохраняется и при попытке насильственной расшифровки файл добивается каким-то псевдорэндомным мусором до исходного размера. При попытке его просмотра, увидел исходную картинку, у которой примерно нижние две трети закрашены жёлтым цветом. Думаю, если бы это было видео, то какой-нибудь mplayer справился бы с таким битым файлом.
Возможно ещё поэкспериментировать и отключить опции MDC (проверки целостности) при зашифровании или расшифровании.
Зная свойство tar, думаю, что из недокачанных битых таров, тоже можно будет что-то вытащить, если шифровать tar через gpg.
Именно первые, а не последние? Это обычно фатально. В начале jpg/mp4-файла хранятся заголовки, критичные для его просмотра вьюерами.
Я команду написал вроде правильную, просто высказался коряво, подразумевалось: отрезаем первую часть и используем её для наших экспериментов по расшифровке, а остаток выбрасываем. Это чтобы как раз имитировать скачивание начала файла.
Если бы отбрасовалось именно отрезанное в начале, то тогда бы вообще и не расшифровалось ничего.
В прыщах с документацией всегда проблемы. Есть сайт автора 7zip, где и документация и исходники. Уязвимостей в его реализации AES256 пока ещё никто не находил.
В мире прыщесорца в качестве средства шифрования архиваторы никогда не указываются. А в мире виндов — только если статья писана журналюгой для ламеров.
В целом, более десяти лет есть высокий спрос на взлом "забытых" паролей rar-архивов. Настолько серьёзный, что очень неплохо продаётся различный инструментарий. Производители которого некисло толкаются между собой в конкурентной борьбе. Ничего лучше, кроме как перебора по словарю, никто из них ещё не предлагал. И это при том, что нет проблемы обладая их ресурсами отсмотреть дизасемблированные бинарники rar/winrar в поисках бэкдора.
Что используют в прыщах и юнихах для выкладывания шифрованных архивов, которые должны открываться даже когда недокачены?
Обычный тарбол, пожатый и шифрованный в gpg через bzip2. Как бы gpg умеет сжимать данные перед тем как шифровать.
Реализация bzip2 в gpg без проблем работает с не до конца скаченными архивами. И само собой файлы вытащить из частично скаченного тарбола тоже не представляет сложностей.
В виндах можно юзать пакет gpg4win, который позволяет и создавать шифрованные тарболы, доступные прыщелюбам и расшифровывать файлы из таковых пришедшие от оных.
Спасибо за наводку, поэкспериментирую. Строго говоря, bzip считается не настолько кошерным, как 7z — якобы последний сжимает всё-таки лучше. Однако, преимущество первого в том, что его не надо применять руками — он уже встроен в gpg, достаточно указать опцию или статично прописать preferences в конфиге (тоже должно делаться).
Только как всё это согласуется с
Кому верить?
Верить обоим. Там пишется куча ошибок, не стал их копипастить. Надо просто ENTER или Y нажимать и оно в итоге выплюнет результат недорасшифрования.
Кроме видео на файлопомойках с трудом можно представить, для каких форматов недокачанных файлов всё это нужно. А видео обычно уже само по себе сжатое. В gpg тогда логичнее сжатие вообще для такого применения отключить.
А если взять режим типа -q? Или, может, есть способ с командами типа классических -y (предполагается "да" на все вопросы). Мусор можно вырезать через 2>/dev/null.
Архивы с фотографиями. В обрезанном архиве будет одна битая фотография и, в нормальном виде, все, которые были в списке до неё.
Во-первых, пожатие, близкое к максимальному, реализуется только на суперкодеках типа H264. Мало кто ими жмёт, ибо это затратно по вычислительным ресурсам. Во-вторых, на современных машинах лишнее сжатие мало на что влияет в плане расходов по времени, поэтому можно его по умолчанию оставить для всех типов файлов.
Надо поэкспериментировать. Скорее, как ранее упоминалось, надо отключить MDC:
Или шифровать с опцией --disable-mdc
Фотки перед шифрованием можно собрать в непожатый архив таром, уже упоминалось, что он выдержит, если он будет обрезан с конца или повреждён и отдаст, что уцелело.
Из-за ошибок с какого-то блока gpg посчитала, что пошифровано алгоритмом IDEA и потребовала ввести пароль второй раз. Но недокачанные файлы таким способом извлекаются. Встроенное шифрование в архиваторах не нужно, значит и нет смысла ставить вопросы по поводу его (не)стойкости и бэкдорности.
За такие утверждения надо бить по ушам и больно щелкать по носу.
Когда на компе нет никаких софтин для шифрования, а лишь традиционный набор архиваторов(умеющих шифровать), то данные можно спокойно хранить в шифрованных архивах. На требования же выдать пароль отвечать, что мол данный архив был скачан с какого-то файлообменника, вроде обещали эротику, но вот не открывается, поскольку нужен какой-то пароль.
И пущай гособвинитель упрыгается пытаясь доказать, что отказываешься сотрудничать со следствием.
В случае же наличия на компе средств шифрования, обвинитель всегда может заявить, что гражданин является достаточно подкованным, чтобы использовать средства праводоподобного отрицания для хранения компрометирующих его данных на скрытых разделах криптоконтейнеров. А потому можно и нужно усомнится в искренности подследственного. Даже в том случае, когда добровольно выдал ключи от всех обнаруженных криптоконтейнеров.
В случае суда присяжных и в сумме с остальными факторами первое может трактоваться в пользу обвиняемого, а вот второй сценарий — ему в минус.
Можно скачать обрезанный архив, а остаток не докачивать — те файлы из архива, что не докачали, всё равно можно будет извлечь. -:)Я вас умоляю... На обычном виндоПК без шифрования остаётся такое количество следов на диске, что можно практически всегда восстановить, когда, куда и зачем вы кликали. И если хотя бы раз архив распаковывался, его расшифрованные обырвки навсегда осядут на диске и во множестве системных журналов (как и сам факт расшифрования), которые вы будете вычищать, вычищать и никогда не вычистите со 100%-гарантией (как и не затрёте всё неиспользуемое место на файловой системе).
Любой стандартный дистрибутив Linux содержит LUKS и OpenSSL, это позволяет шифровать файлы. Наверняка в винде тоже что-то такое есть, раз она с HTTPS работает.
Увы, в винде есть только доступ к CryptoAPI, но никакого прикладного софта (помимо всяких битлокеров).
Более того, Debian, например, без GnuPG вообще не даст поставить ни одного пакета в систему стандартным способом.
Вкладывайте GnuPG-шифровки внутрь запароленных архивов. Наличие программ шифрования всё равно отрицать бессмысленно, но зато сами архивы не будут привлекать внешнего внимания на файлопомойках — Google не будет их усердно индексировать и складировать копии в АНБ. Только используйте разные пароли шифрования для GnuPG внутри и для архива снаружи. Ну разве что, пользователей Linux среди вашей аудитории перспектива ставить левые архиваторы не очень обрадует.
Зато есть Power Shell, который гипотетически позволяет выполнить любую функцию ОС. Я не знаю, Power Shell позволяет вызывать функции дотнет-фреймворка, значит, можно написать cкрипт, который что-то шифрует, но это будет так тяжко и неуклюже, что не хочется даже пробовать. Power Shell и дотнет – это инвалидная коляска...
Поэтому Linux — система террористов[link9], и сам факт её использования является достаточным для обвинения. :)