Есть ли backdoor's в шифровании архиваторами?
В частности интересен в этом плане свободный .7z, а также реализация шифрования в нём же при сжатии в формат .zip (там кажется есть выбор из двух типов возможного алгоритма шифрования).
Вопрос возник в основном потому, что в руководствах по Linux, написанных иностранными авторами, 7-zip в качестве средства шифрования практически не упоминается.
Из чего я для себя сделал вывод, что бэкдоры в 7-Zip МОГУТ быть. Или я не прав?
комментариев: 9796 документов: 488 редакций: 5664
Сама по себе фича существует с тех времён, когда веб-файлопомоек не было вообще, а интернет был по звуковым модемам, пользовалась ограниченной популярностью при рассылке пиратского контента в ньюс-группах. До сих пор как-то развивается в Parchive. Никогда не возникало интереса к его использованию, но если бы было надо, то можно было бы нагородить комбайн из tar, par и gpg.
Возможно, что вы качаете/распространяете какое-то многогиговое непотребство (в плане размеров файлов, на содержимое пофиг) через Tor, поэтому вам нужно и слабенькое шифрование, и многотомность, и защита от ошибок при разрывах. Это специфический набор требований — попытка подстроиться под существующую среду, вместо того, чтобы сформулировать задачу в общем виде: построить стойкую анонимную непрослушиваемую сеть с возможностью броадкастингового обмена информацией.
Опять двадцать пять, по части передёргиваний.
Формулировать надо сперва модель угроз в условиях существующей среды. После этого переходить к выстраиванию процесса. Поскольку безопасность не является продуктом или производной какого-то средства.
Но непонятно, как это связано с Parchive. И как вы предствляете конвеер с parchive и 7z? Что поверх чего, как бы это выглядело?
Там, похоже, в другом идея: защита от произвольных повреждений. Здесь же речь идёт об обработке исключительно обрезанных архивов. У нас нет желения делать избыточное кодирование и прочие тонкости, достаточно расшифровывать/разархивировать то, что получается.
Достаточно десятков или сотен мегабайт, которые качаются со скоростью в 10kB/s.
Это было бы слишком. Если исходить из реальности, пока есть только 2 относительно надёжных сети: Tor и Freenet, всё остальное нанизывается на них.
комментариев: 9796 документов: 488 редакций: 5664
Никто вообще ничего толком не объяснил: некто хочет, чтобы была реализована какая-то опция, по принципу «чего изволите, любой каприз за ваши деньги», даже не потрудившись разъяснить в общем виде — зачем? Приходиться гадать телепатически. Ну, извините, не угадал, бывает.
Я иногда что-то качал с файлопомоек, и даже шифрованное, но с проблемой битых файлов не разу не сталкивался. Мне битые и недокачанные файлы не нужны в принципе. Мне важно чтобы было зашифровано так надёжно, чтобы не могли умышленно обрезать файл или подменить хоть один бит без знания ключа. Может кто-то видео качает, где это всё не так важно, надо опять гадать? Чтобы неугаданные предположения зачислили в передёргивания?
комментариев: 1060 документов: 16 редакций: 32
А когда это Евгений превратился в Александра?
Про winrar, кстати, ответ на вопрос по теме будет такой: неизвестно, проверить сложно. Основания утверждать, что схема шифрования надёжна, отсутствуют. Основания утверждать, что схема шифрования ненадёжна, также отсутствуют.
Здесь должна быть картинка "кто-то купил полную версию winrar". ;)
Чё за детский сад? Чел же изложил всё очень детально и подбробно.
Ему нужна возможность работы с шифрованными данными на нестабильных каналах связи. В условиях, когда передача сообщения обывается из-за проблем в протоколах транспортного уровня.
Это могут радиопомехи или потерян луч спутника — не важно что это.
В тоже время, важен результат, который должен быть достигнут. А именно возможность расшифровать ту часть сообщения, которая была получена. Будучи уверенным, что та часть, которую удалось получить не была повреждена.
Потому что проблемы в протоколе транспортного уровня не обязательно являются форс-мажором, а могут быть вызваны действиями атакующего.
Т.е. в описании модели угроз проставлено, что атакующий не может произвести подмену транслируемого сообщения. Может лишь повредить его до такой степени, что передача прервётся. А то что удалось принять потенциально может оказаться повреждено.
И на основании этого описания, чел проводит сравнение существующих ныне средств. Пригодных к использованию определённым образом, т.е. согласно некоторому сценарию действий из множества доступных принимающей стороне.
Это классический вариант практического применения криптографической защиты в условиях активного противодействия. Со стороны какой-то неодушевлённой силы или же лица наделённого умыслом.
Unknown, в самом же первом посте, чёрным по белому:
Если это не объяснение, то что есть объяснение?
Оговорился, в моей памяти нет системы исправления ошибок...Ан-нет, всё тоньше: не превратился, а создал клона от своей матери.Да, но есть один косвенный аргумент: unrar открыт и опунесорсен, для расшифрования он действительно использует AES. Конечно, это не страхует от специфических багов/бэкдоров в самом rar, которй архивирует и шифрует, а не распаковывает.
комментариев: 9796 документов: 488 редакций: 5664
Извиняюсь, пост был объёмный, я пропустил этот абзац. И пост — третий по счёту, не считая заголовочного.
Если вас интересует только эта задача, то всё примерно так:
Честно говоря, видео под руками не было. Была JPEG-картинка на 150 кб. Отрезал где-то первую треть — первые 50 кб. При расшифровке получился файл, в точности до байта совпадающий с исходным размером — 150 кб. Скорее всего, размер исходного сообщения сохраняется и при попытке насильственной расшифровки файл добивается каким-то псевдорэндомным мусором до исходного размера. При попытке его просмотра, увидел исходную картинку, у которой примерно нижние две трети закрашены жёлтым цветом. Думаю, если бы это было видео, то какой-нибудь mplayer справился бы с таким битым файлом.
Возможно ещё поэкспериментировать и отключить опции MDC (проверки целостности) при зашифровании или расшифровании.
Зная свойство tar, думаю, что из недокачанных битых таров, тоже можно будет что-то вытащить, если шифровать tar через gpg.
Именно первые, а не последние? Это обычно фатально. В начале jpg/mp4-файла хранятся заголовки, критичные для его просмотра вьюерами.
комментариев: 9796 документов: 488 редакций: 5664
Если бы отбрасовалось именно отрезанное в начале, то тогда бы вообще и не расшифровалось ничего.
В прыщах с документацией всегда проблемы. Есть сайт автора 7zip, где и документация и исходники. Уязвимостей в его реализации AES256 пока ещё никто не находил.
В мире прыщесорца в качестве средства шифрования архиваторы никогда не указываются. А в мире виндов — только если статья писана журналюгой для ламеров.
В целом, более десяти лет есть высокий спрос на взлом "забытых" паролей rar-архивов. Настолько серьёзный, что очень неплохо продаётся различный инструментарий. Производители которого некисло толкаются между собой в конкурентной борьбе. Ничего лучше, кроме как перебора по словарю, никто из них ещё не предлагал. И это при том, что нет проблемы обладая их ресурсами отсмотреть дизасемблированные бинарники rar/winrar в поисках бэкдора.
Что используют в прыщах и юнихах для выкладывания шифрованных архивов, которые должны открываться даже когда недокачены?
Обычный тарбол, пожатый и шифрованный в gpg через bzip2. Как бы gpg умеет сжимать данные перед тем как шифровать.
Реализация bzip2 в gpg без проблем работает с не до конца скаченными архивами. И само собой файлы вытащить из частично скаченного тарбола тоже не представляет сложностей.
В виндах можно юзать пакет gpg4win, который позволяет и создавать шифрованные тарболы, доступные прыщелюбам и расшифровывать файлы из таковых пришедшие от оных.
Спасибо за наводку, поэкспериментирую. Строго говоря, bzip считается не настолько кошерным, как 7z — якобы последний сжимает всё-таки лучше. Однако, преимущество первого в том, что его не надо применять руками — он уже встроен в gpg, достаточно указать опцию или статично прописать preferences в конфиге (тоже должно делаться).
Только как всё это согласуется с
Кому верить?
комментариев: 9796 документов: 488 редакций: 5664
Верить обоим. Там пишется куча ошибок, не стал их копипастить. Надо просто ENTER или Y нажимать и оно в итоге выплюнет результат недорасшифрования.
Кроме видео на файлопомойках с трудом можно представить, для каких форматов недокачанных файлов всё это нужно. А видео обычно уже само по себе сжатое. В gpg тогда логичнее сжатие вообще для такого применения отключить.