Шифрование, сжатие, проприетарное ПО и прочие вопросы безопасности (Вынесено из яндекс диск или маил облако))

[Yamah]

Начало тут

Торренты закрывают.

Закрывают трекеры пока что. Сам протокол пока еще не блокируют.
Есть возможность распространять по магент-ссылками.

К тому же, технологии не стоят на месте и велика вероятность, что в один прекрасный день всё это взломают.
И тогда мои «суперсекретные данные» продолжат храниться на том же торренте, но уже в открытом виде.

4-хкилобитный ключ предется долго взламывать даже задействовав все сервера Гугла.
Подобрать пароль к почте и архиву на диске времени потребуется куда меньше.

Плюс еще нужно будет найти начало шифрованного раздела.

Исходники открыты, изучены, и используемый подход признан достаточно надёжным.

Пока Winrar числится проприетарным ПО.
Программы, позволяющие "взломать" архив WinRar найти в сети не проблема. В том числе и на торрент-трекерах.
Если не ошибаюсь, пароль из 12-символов цифро-буквенной части кодировки CP1251 подбирается за пару часов.

Он так и делает. .

В смысле? Создает файловый контейнер CryptoLoop, DM-Crypt или стандартно средствами ОС на файле?

Код: Выделить всё

BLOCKSIZE="1M"
COUNTSIZE="1024"
dd if=/dev/zero of=myFile.img bs=$BLOCSIZE count=$COUNTSIZE
mkfs.ext4 -m 0.01 myFile.img
mount -t ext4 -o loop myFile.img /mnt/myFS

хотя я плохо себе представляю, как зашифровать ассиметрикой гигабайты данных, а не ключ для симметричного алгоритма.

Но ведь SSL это как-то делает

[Алзим]

Программы, позволяющие "взломать" архив WinRar найти в сети не проблема. В том числе и на торрент-трекерах.
Если не ошибаюсь, пароль из 12-символов цифро-буквенной части кодировки CP1251 подбирается за пару часов.

Вы сами-то статью читали? Он там подобрал пароль: 777
А в остальном:

«…Единственный способ взлома архива RAR – брутфорс. Если кто то предлагает другой способ – не верти, это развод.»

Соглашусь с автором, только бутфорс. Помнится ещё в институте на занятиях криптологии, я зауважал winRAR с точки зрения безопасности.

[trs]

В смысле? Создает файловый контейнер CryptoLoop, DM-Crypt или стандартно средствами ОС на файле?

Упомянутые наименования суть деталь реализации. Под абстракцией "контейнер" понимают объект для хранения других объектов, этим признакам RAR-архив, храня в себе объекты типа "файл", удовлетворяет вполне.

хотя я плохо себе представляю, как зашифровать ассиметрикой гигабайты данных, а не ключ для симметричного алгоритма.

Но ведь SSL это как-то делает

Наверное так, как у меня написано после союза "а"?

[Yamah]

Вы сами-то статью читали? Он там подобрал пароль: 777

Естественно читал.

Пароль стоял простой, и ограниченная по символам выборка. Результат в несколько секунд.

Естественно пароль брутфорсом подбирается.
Но когда пользователь ограничен в использовании только печатных символов (88-штуки), запрет на использование символов, определяемых как служебные (8-штук минимум), в частности для CMD-версии, да и кодировка однобайтная, все это упрощает подбор.
А если пользователь не активировал шифрование информации о файлах, то еще проще. Но даже, если он включил шифрование информации о файле, сам заголовок не шифруется (до версии 3.5 точно, дальше я не пользовался), из полей можно достать шифрованные значения и проводить дешифровку только по ним.

[trs]

Если грубо: 64 символа кодируются 6ю битами, взяв пароль в 8 символов, получим 48 бита. Для варианта "можно использовать 256 символов", эти же 48 бит ключа получаются из 6ти символьного пароля.
Далее, по ссылке есть то, что можно было найти в исходниках: «при вводе пароля, из него 262144 раз вычисляется хеш по алгоритму SHA1, и полученным ключом WinRAR пытается расшифровать (по AES) и разархировать файлы». Это должно несколько замедлить брутфорс.

Хотя, к чему вообще эта "мега-секретность"? Есть способы получить пароль и без его перебора. То, что выложено в торрент, может быть проанализировано кем угодно, наличие зашифрованных данных определить проблем нет, адрес (IP) сами же предоставляете... Тут возникает вопрос, а кто вообще придумал такую схему, и с какой целью распространяет поведенческий шаблон?

[Yamah]

Если грубо: 64 символа кодируются 6ю битами, взяв пароль в 8 символов, получим 48 бита. Для варианта "можно использовать 256 символов", эти же 48 бит ключа получаются из 6ти символьного пароля.
Далее, по ссылке есть то, что можно было найти в исходниках: «при вводе пароля, из него 262144 раз вычисляется хеш по алгоритму SHA1, и полученным ключом WinRAR пытается расшифровать (по AES) и разархировать файлы». Это должно несколько замедлить брутфорс.

Если не шифрованна информация о файлах внутри - да. Но это уже не настолько критично на современных процессорах.
Если еще зашифрована информация о файлах, то дешифровать нужно только сами значения полей.

Хотя, к чему вообще эта "мега-секретность"? Есть способы получить пароль и без его перебора.

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

Начнем с того, что я предлагаю выкладывать в торрентах информацию. Я только предложил хранить шифрованную информацию внутри (если быть точнее в хвосте) безобидного и большинству людей бесполезного файла с неприватной информацией, а сам файл вы можете хранить в любом удобном вам сервисе.
Продолжим тем, что наличие в любой IT-компании нечестных людей (в том числе и по внутренним распоряжениям), исключать нельзя. Найти шифрованный архив среди тысяч файлов не большая проблема, особенное если можно на сервере запустить свою программу. А дальше, человек получивший, ваш запоролленый файл изнутри сервиса, вероятнее всего сможет получить о вас всю остальную информацию, включая ваше имя и почтовый адрес. (В случае с торрентами и IP будет даже сложнее, если вы не единственный сид. Да и помимо логина и IP ничего не будет. Но это просто к слову.) А вот поиск шифрованной информации спрятанной где-то внутри файлов - задача не тривиальная, даже в случае если это просто рар-архив.
И закончим тем, что не каждому криптоанализатору придет в голову сравнивать размер файла с скажем с суммарным битрейтом видео и аудио дорожек в нем. Да и опять таки найти начало хвоста, не относящегося к основному файлу достаточно тяжело. Да и после дешифровки у вас будет только файловый контейнер, для которого нужно знать еще и ФС. А если при его создании использовать не /dev/zero, а /dev/random, так вообще можно начало и/или конец файлов не заметить.

[trs]

А вот поиск шифрованной информации спрятанной где-то внутри файлов - задача не тривиальная, даже в случае если это просто рар-архив.

Возьмём частотный анализ. Если он возможен, значит ключ не нужен, расшифровали. Если, благодаря шифрованию, он не возможен, значит что происходит с частотами? А битрейт и т.п. могут иметь смысл, как дополнительные проверки. Вообще, предложение "прицепить туда то" похоже на безопасность через неясность.

[Yamah]

Возьмём частотный анализ. Если он возможен, значит ключ не нужен, расшифровали. Если, благодаря шифрованию, он не возможен, значит что происходит с частотами? А битрейт и т.п. могут иметь смысл, как дополнительные проверки. Вообще, предложение "прицепить туда то" похоже на безопасность через неясность.

Что-то мы в какую-то не ту степь начинаем углубляться.

Давайте немного пофантазируем (просто представим ситуацию).
Вы имеете доступ ко всем файлам, которые я залил в приватный хостинг (20 ГБ), который предоставляет мне ваша компания. Вы понятия не имеете о том какую информацию и как я могу (и буду ли) выкладывать.
На хостинг я выкладываю какие-то документы в форматах docx и pdf, несколько архивов в различных форматах, включая rar, фотки, музыку (предположительно варезную)., и несколько видеофайлов с домашним видео (вечеринки с друзьями, как ребенок учится ходить и т.п.). Где вы будите искать документы любого типа, которые могут их публикацией представлять кому-то интерес или ухудшить мое положение? И какими средствами?
Напомню, вы про меня ничего не знаете.

[trs]

Это как раз "та степь" и была, намёки, как определить, что произвольная последовательность байт содержит зашифрованные данные. Вопрос про частоты ключевой.

[Алзим]

Напомню, вы про меня ничего не знаете.

А что если я свой архив arx.rar переименую в arx.avi ? Вы будете каждое видео просматривать?

[Delles]

А что если я свой архив arx.rar переименую в arx.avi ? Вы будете каждое видео просматривать?

Код: Выделить всё

$ >file
$ 7z a arx.7z file

7-Zip 9.38 beta  Copyright (c) 1999-2014 Igor Pavlov  2015-01-03
p7zip Version 9.38.1 (locale=ru_RU.UTF-8,Utf16=on,HugeFiles=on,2 CPUs,ASM)
Scanning

Creating archive arx.7z

      
Everything is Ok
$ rename 7z avi *z
$ file arx.avi
arx.avi: 7-zip archive data, version 0.4
$

[Алзим]

Ну, вот и пусть тратит время, чтобы перелопатить террабайты информации, чтобы архивы найти. А потом ещё годы брутит, чтобы всё это открыть.

[Yamah]

Это как раз "та степь" и была, намёки, как определить, что произвольная последовательность байт содержит зашифрованные данные. Вопрос про частоты ключевой.

Этот метод предполагает просмотр всего объема данных.
И тут ключевым условием является время.

Напомню, вы про меня ничего не знаете.

А что если я свой архив arx.rar переименую в arx.avi ? Вы будете каждое видео просматривать?

Зачем? В Unix-Like системах, проще по заголовку фала (MIME-типу) проверить.
Делается это простым скриптом на BASH даже. А более серьезные тулкиты предлагают уже готовые функции.

Шифрованный рар по заголовку найти тоже не проблема. А дальше дело готовых решений.

Если же вам попадется "мой" avi-файл, он будет по MIME-типу определятся как avi, открываться плеерами, проигрываться до конца видео. Возможно некоторые плееры и будут ругаться на его окончание, но не все. Вам ведь придется в ручном режиме проверять соответствие битрейта контента размеру файла.

Можно еще долго извращаться, чтобы усложнить криптоанализ. Здесь пределом будет уровень паранои и уровень ощущением себя Неуловимым Джо.

PS: Еще один способ обдурить автоматические дешифраторы. Rar-файл в 1ГБ размером. Не шифрованный. Но при распаковке данных в нем всего не 100 МБ. Спрашивается, почему файл весит так много?

[trs]

Этот метод предполагает просмотр всего объема данных.
И тут ключевым условием является время.

Даже такая тривиальная задача, как загрузка файла на сервер требует "просмотра всего объёма данных", во многих токах пути. Время? А какое там время? О1?

[notauser]

https://mega.nz/
https://mega.nz/#!eI0GjbqA
Ключ !wPquXV4mMR4yXeBsdMtadtojJ4d0f8pFsRzEwovZtcE

[Yamah]

Даже такая тривиальная задача, как загрузка файла на сервер требует "просмотра всего объёма данных", во многих токах пути. Время? А какое там время? О1?

Про момент загрузки я сразу не подумал.

Хорошо. А как проверить, что файл MKV валидный совсем, а не добавленным контейнером.

PS. Все что я предлагал, делал до меня TrueCrypt

[trs]

Антивирусом. Они разве не пишут уже который год: «файл зашифрован, проверить не возможно»?

А раз уж упомянули TrueCrypt… подумайте, какие причины могли быть у закрытия проекта.

[Delles]

https://mega.nz/

Как знать, что декларация на сайте — это правда, и что она останется правдой и дальше?

Позвольте спросить: что вы думаете по поводу шифрования посредством

Код: Выделить всё

gpg -c файл

Насколько сложно его вскрыть?

[trs]

Теория
Критерий истины

[Delles]

Ни по gpg, ни по gnu поиск там ничего не выдал, а читать всё подряд… есть занятия поинтереснее.

[trs]

Первую ссылку и не надо читать, она для контраста. Соль во второй, точнее, даже в картинке и названии сайта.

[Delles]

Первую ссылку и не надо читать, она для контраста. Соль во второй, точнее, даже в картинке и названии сайта.

Против лома нет приёма. Но, помня про принцип ортогональности удобства и надежности, интересуюсь, так ли уж ортогонально удобство шифрования gpg -c file.tar его надежности.

[trs]

С какой-то целью шифровать? Это решает какую-то насущную проблему?

Или же некий условный специалист (могут ли неспециалисты определить степень его компетенции?) сообщил во всеуслышание: вам следует шифровать свои данные. Может быть, тогда следует задать себе вопрос: а не решает ли он какие-то свои проблемы таким образом?

[Delles]

С какой-то целью шифровать? Это решает какую-то насущную проблему?

Или же некий условный специалист (могут ли неспециалисты определить степень его компетенции?) сообщил во всеуслышание: вам следует шифровать свои данные. Может быть, тогда следует задать себе вопрос: а не решает ли он какие-то свои проблемы таким образом?

Я шифрую конфиденциальные файлы, например, сканы документов, как своих, так и доверивших мне лиц, подвести которых не имею права. Делаю это на случай несанкционированного доступа любого рода.

[trs]

Если ключа нет, то принято считать*, что "не хватит ресурсов во всей Вселенной". Потому будут добывать ключ. В связи с чем, прошу обратить внимание на мой вопрос, где написано "какой-то", а не "какой". Вопрос был о наличии цели, так что можно было не сообщать лишнюю информацию. Ключ - частный случай "лишней информации".

*) имеется ввиду надёжный шифр. Что использует gpg:

Код: Выделить всё

 -c     Encrypt with a symmetric cipher using a passphrase. The default symmetric cipher used is CAST5, but may be chosen with the --cipher-algo option.

CAST5 - это CAST128, то есть использует ключ 128 бит.
CAST256 принимал в своё время участие в конкурсе AES, но проиграл Rijndael (и в число пяти финалистов не вошел).

[Delles]

Если ключа нет, то принято считать*, что "не хватит ресурсов во всей Вселенной"

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

[trs]

Да, именно, профессионал с полным перебором возиться не будет, если есть менее затратные варианты.

[Yamah]

Антивирусом. Они разве не пишут уже который год: «файл зашифрован, проверить не возможно»?

Антивирусы проверяют мультимедийные файл на соответствие MIME-типу. Некоторые еще проверяют ID3-теги, но не медиа-контент.
Тем более, что медиаконтет достаточно труднен для анализа сам по себе, ибо это кодированный определенным алгоритмом (в том числе и ключом). А при использовании контейнера может вообще показаться всем чем угодно, так как контент в треке разбивается и поочередно смешивается с частями других треков.

Некоторые антивирусы, в том числе и тот, что тут регулярно рекламирует один пользователь даже в rar-файле не могут найти лишние мегабайты информации.

А раз уж упомянули TrueCrypt… подумайте, какие причины могли быть у закрытия проекта.

Официальной причины нет. Гадать бессмысленно.
Могу предположить:
- развитие штатных системных инструментов в большинстве ОС.
- наезды от правообладателей/правоохранительных органов, которым надоело, что с помощью этой программы пираты прячут варез.
- пропало финансирование.

[Yamah]

Да, именно, профессионал с полным перебором возиться не будет, если есть менее затратные варианты.

И опять пришли к условию степень_заинтересованности/средства/время.

Если вы - Неуловимый Джо, а время затраченное даже на анализ тех ваших файлов, что пред изучающим ваши данные человеком лежат, не говоря уже о получении доступа к контенту в них, не окажется больше, чем нужно для удовлетворения простого любопытства, ваши файлы просто никто не будет вскрывать. (О чем я говорил раньше.)

[trs]

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

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

[Yamah]

Это верно для несжатого контента. Как только вы применяете сжатие (как с потерей данных, так и без оной) вы не увидите уже никакого спектра. Особенно это касаемо алгоритмов, восстанавливающих текущий фрагмент контента исходя из фрагментов предыдущего, с некоторыми модификациями (видео кодеки с поддержкой разностных и двунаправленных кадров), то есть блоков (макроблоки, семплы). Большая часть информации в таком контенте будет не столько содержать пользовательские данные, сколько служебную информацию о блоках, их кодировании и ссылках, причем даже количество бит затрачиваемое на каждый блок, ссылки на него, и на каждый фрагмент в целом может быть разным. И тут без работы декодера не обойтись. Однако, еще нужен адекватный декодер, который запаникует, когда дойдет до конца контента/контейнера, на не до конца файла. (Стандартные rar и urar не считают нужным паниковать, если архив уже кончился, а файл нет.) Тем более важно, чтобы декодер смог определить невалидный контент, а не просто вывел то, что есть без анализа (чем грешит mp3 декодер).
Декодеры обычно нагружают процессор, хотя и не так как энкодеры.

А если от декодера требуются нестандартные функции. тот тут нужно будет его переписывать. При том количестве форматов сжатия данных и контейнеры для них, учесть все варианты - задача сравнима с написанием ОС с нуля.

При любом раскладе все упрется во время. В процессорное или человеческое. И тут опять все будет зависеть от желания получить/изучить ваши данные.
Идеальных вариантов, когда ресурсы и время безграничны, нет.

[trs]

Как только вы применяете сжатие (как с потерей данных, так и без оной) вы не увидите уже никакого спектра.

Почитайте определение, что есть спектр. Тогда, может быть, увидите.