Регистрация"Критический пароль"
Конечно, это все останется просто болтологией, хотя, может быть стоит и написать письмо нынешним разработчикам.
Мы сейчас разбираем ситуации по декриптованию информации, перехваченной в пути, т.е. лицо, закодировавшее данные недоступно, но как бы поступила я, если бы мне срочно нужно было добыть закодированные данные? Я бы добыла лицо, которое знает пароль и мордовала бы его до полного признания "у во всем"... Старый эпиграф на сайте был такой, может кто то еще помнит: "... Мы не требуем от Вас невозможного, мы хотим, чтобы Вы поняли, что при современных методах ведения допроса у Вас нет ни малейшего шанса сохранить тайну..."
При "современных методах ведения допроса" и приминении алгоритма расшифровки "кирзовым сапогом" сломается примерно 99,9 % контингента. Следовательно, стоило бы ввести так называемый "критический пароль", после ввода которого, информация, закодированная в сообщении бы "похерилась" и вместо нее была подставлена какая-нить, совершенно безобидная... Например мы пересылаем поэтажные планы Пентагона, а после ввода "критического пароля" видим например пейзажи Соловецкого острова. Равноценно это хотелось бы видеть и в PGPdisk... Причем, после воода критического пароля желательно, чтобы ценная информация была уже никогда недоступна, раз "критический пароль" введен, значит эта информация, примерно в 100% лично Вам уже не потребуется... (злобный, сатанический хохот)
:twisted:
После этого программа будет совершенна....
комментариев: 9796 документов: 488 редакций: 5664
Все немного (скорее намного) сложнее. Наименьший значащий бит в файлах выглядит случайным, но коррелирует со старшими битами. Большинство первоначально созданных стегоалгоритмов (и программ на их основе) этого не учитывало. Иногда, достаточно вывести картинку из одних (якобы незначащих) младших битов и увидеть, что она даже сама по себе не случайна. Поэтому, внесение "белого шума" в какие-угодно "незначащие" биты с вероятностью 9x.xx% определяется статистически даже без знания исходного изображения на основе учета корреляций и построения статистических моделей изображения.
В реальных оцифрованных звуках (картинках), то что кажется "белым шумом" на самом деле им не является и встроить "белый шум" в файл можно незаметно для глаза (уха), но не для общей статистики. (Или придется встраивать ничтожно малый объем данных, намного меньший, чем это позволяется в существующих программах).
После публикации множества работ на эту тему стеганография оказалась в некотором временном кризисе. Большинство (если не все) стегопрограммы были признаны ненадежными. Были разработаны более сложные стегоалгоритмы, но пока публикации на эту тему менее доступны, чем "простая криптография".
А простое встраивание информации в "наименее значащий бит", без учета общих корреляционных зависимостей – это самый примитивный алгоритм, который должен уйти в прошлое.
Мой личный вывод из этого – пока стеганография еще не достигла той степени совершенства, как криптография и рассчитывать на нее, как на альтернативу "критическому паролю" не стоит. (Против серьезного противника по крайней мере).
В действительности это лучше, чем "Критический пароль".
Идея состоит в том, что криптографический контейнер отзывается на два разных пароля – и при их вводе соответственно показывает разное содержимое. Естественно, одно из них – это специально подготовленная фальшивка. Смысл всего этого в том, что не зная пароля к "скрытой части" – нельзя определить факт её наличия внутри контейнера. В то же время, после добавления "скрытой части" к оригинальному контейнеру любая запись во "внешний", фальшивый контейнер – приводит к необратимому разрушению секретной части, так как происходит перезапись заголовка. Таким образом, пароль ко внешнему контейнеру можно использовать аналогично "критическому паролю", о котором говорилось в начале топика. Конечно, после его ввода и монтирования тома потребуется всё-таки внести в него изменения. Но для быстрого и скрытного уничножения секретной части в угрожаемой ситуации – это вполне подойдёт.
Для поклонников анализа статистики, сообщу что разработчики учитывают факт статистического анализа контейнера. Доказательство факта наличия скрытого контейнера таким способом кажется весьма затруднительным. Изначально, при создании контейнера, его байты заполняется случайными данными. Впоследствии, шифрование данных происходит в режиме Сipher Block Chaining (CBC). Т.е. статистическое отклонение от случайного шума у зашифрованных данных – представляется минимальным. (Недостоверным? :))
комментариев: 9796 документов: 488 редакций: 5664
В свое время эта идея (на чисто теоретическом хотя бы уровне) была проработана в проекте "rubberhose", который к сожалению, прекратил свое существование.
Слишком велика вероятность сделать это в обычной ситуации по ошибке.
А если враги застанут вас совсем врасплох, то они сделают копии исходного контейнера, так чтобы неверный пароль никак не повредил данным. Против юридического принуждения такой способ может еще и сгодится, но вот в случае физического принуждения пользователь может оказаться в довольно двусмысленной и незавидной ситуации.
Почему же? Это же специальный пароль для выдачи под давлением или для стирания данных в критической ситуации. Для нормальной работы со скрытой частью контейнера используется другой пароль.
Что же касается случая физического принуждения – то в этой ситуации многое зависит от качества подготовленной фальшивки и актёрских данных жертвы. :)
комментариев: 73 документов: 1 редакций: 0
Из мозгов будут извлекать *настоящий* пароль. Причём, вне зависимости от его существования. Этим и опасны для тушки держателя криптоконтейнера наличие фич типа критического пароля в используемом софте и наличие фальшивок.
Гы. Недостатки прямо вытекают из достоинств. Если тушка сможет продержаться – то он победит. А наличие указаной программной фичи создаёт для этого солидную предпосылку. У тех, кто будет из него выбивать пароль – зачастую не может быть никакого представления о взыскуемых данных. Поэтому фальшивка вкупе с актёркими данными может прокатить. Разумеется, тут многое зависит от конкретной ситуации. Но "скрытый контейнер" – фича безусловно нужная и полезная.
комментариев: 11558 документов: 1036 редакций: 4118
Дело в том, что любой контейнер TrueCrypt формируется так, что его файл (или зашифрованная ФС) представляет собой псевдо-случайную последовательность. Этим достигается свойство "правдоподобного отрицания", когда оппонент не может на основании только наличия файла доказать, что этот файл несёт зашифрованные данные и, тем более, что это криптоконтейнер TrueCrypt.
Скрытый контейнер проявляет те же свойства. Он представляет собой новый контейнер TC, созданный внутри существующего, а поскольку всё свободное пространство любого контейнера TC заполняется при форматировании случайными данными (файл контейнера весь выглядит псевдо-случайной последовательностью), определить наличие в нём скрытого контейнера становится невозможно.
Чтобы добиться нужного результата, пользователь создаёт обычный контейнер ТС, в который помещает дезинформирующие данные или подлинные ценные данные, компрометация которых не несёт критичный характер. Затем опцией Create a hidden TrueCrypt volume создаётся скрытый контейнер с отличным от контейнера-носителя паролем: в него помещается наиболее ценные сведения.
Когда пользователь открывает контейнер TC, он вводит пароль. Вначале TC пытается расшифровать введённым паролем хидер контейнера-носителя и в случае успеха открывает его. Если же пароль не подходит, TC проверяет его на третьем с конца секторе контейнера-носителя, где должен храниться хидер скрытого контейнера. Если пароль подходит, из расшифрованного хидера извлекается информация о размере и расположении скрытого контейнера внутри контейнера носителя, после чего пользователь получает доступ к первому.
У схемы существуют некоторые ограничения и тонкости эксплуатации, подробно описанные в документации TC. Но если следовать всем инструкциям и предостережениям, система получается весьма неплохой, прежде всего из-за простоты устройства, не вызывающего никакого недопонимания — всё предельно ясно.
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 9796 документов: 488 редакций: 5664
Концептуально эти системы именно так и проектировались. Принуждаемый выдает пароль к основному контейнеру под давлением противника. Затем он может выдать пароли к одному или нескольким скрытым вложенным контейнерам. Но противник не может дать заключение о том, остались ли в этой системе еще нераскрытые вложенные контейнеры или оставшееся пространство свободно от шифрованной информации и заполнено псевдослучайными числами.
По замыслу создателей этого протокола это должно доказать несостоятельность юридического принуждения по выдаче паролей и ключей.
Реализации точно имеются (правда сложно сказать в какой стадии они находятся), это и тот же "rubberhose" (кстати это название пытки) и кажется bestcrypt (про него точно не знаю, также и как он сейчас называется).
Так тоже можно, но такая система будет уязвима к вскрытию садовой лопатой. Логично предположить, что находить скрытые улики этим инструментом противник умеет.
Ходят слухи, что секретные правительственные организации с большим бюджетом используют для этих целей экскаваторы, оснащенные дисколокаторами, а затраты на создание таких квазигипотетических устройств падают с каждым годом по закону Мура. Неудивительно если крупные корпорации и преступные группы тоже могут втайне создать такие устройства уже сейчас.
Поэтому метод садового закапывания должен быть пересмотрен. Для создания нового метода садового сокрытия, устойчивого ко всем атакам необходимо подать заявку в Институт Стандартов И Технологий с требованием созвать международный конкурс независимых специалистов по этой тематике.
А до тех пор этой методикой лучше не пользоваться или временно применять тройное закапывание (оно увеличивает стоимость атаки, но работает слишком медленно).
И что это даст? Эта фича легко парируется атакующим путем предварительного снятия копии.
комментариев: 9796 документов: 488 редакций: 5664
Да, именно так он скорее всего и поступит, я тоже не понимаю, какой в этом смысл?
Пароли, уничтожающие и стирающие информацию были популярны раньше, когда не все еще массово знали как обращаться с компьютерами. Сейчас это кажется несерьезным.
Хотя на серверах бывает зашифрованной информации на сотни гигабайт, принуждающая сторона хочет срочно получить результат, а ни времени, ни возможности снять копию у нее нет.
комментариев: 11558 документов: 1036 редакций: 4118