Отрицаемое шифрование
Какими методами можно обеспечить действительно сильное отрицаемое шифрование? Допустим власти/бандиты могут и будут применять силу, чтобы выбить ключи.
В трукрипте возможен только 1 скрытый контейнер, и это всем известно, поэтому ректотермальный криптоанализ будет применяться до тех пор, пока не раскроете оба ключа, даже если вы не создавали этот скрытый контейнер.
Как можно обеспечить неизвестное заранее число скрытых контейнеров?
Тут http://en.wikipedia.org/wiki/Deniable_encryption прочитал про rubberhose, который обеспечивает это и защиту от разных способов анализа зашифрованных данных, но проект не обновлялся с 2000 года, и не понятно, насколько он надежен на практике.
Еще прочитал про возможность создавать контейнеры с заданым смещением на диске, как тут
http://sourceforge.net/projects/stlth/files/
Но в этом случае, как я понимаю, данные не будут равномерно распределены на диске, то есть анализ часто используемых секторов позволит определить, например, что есть область диска которую вы не раскрыли, и ректотермальный криптоанализ продолжится. В документации rubberhose сказано, что он позволяет смешивать данные на диске, чтобы избежать такого анализа, но проект старый.
Какие способы вы посоветуете? Может есть относительно простые в использовании утилиты?
С таким людьми нет смысла разговаривать. Чудику дают ссылку на статью про то как реализовано и работает обсуждаемое, а в ответ от него лишь "растолкуйте".
Да и трукрипт этот чудик похоже никогда в живую не видел, с контейнерами не работал, раз не кидается такими заявлениями про файлы.
Забивает только тему объемными постами с пустопорожним бредом. Видать на обычных форумах его очень быстро банят, вот он сюда и прибился.
И рад тому. Здесь TC используют чудики иного толка, у всех остальных LUKS.
Пока что тут твои ветки закрывали и сносили, а не мои объёмные посты. В курнный мозг объёмный пост не влазит, из-за этого начинаются проблемы с осмыслением?
комментариев: 9796 документов: 488 редакций: 5664
Ещё раз, для понимания вопроса защиты скрытых дисков достаточно посмотреть раздел "Protection of Hidden Volumes Against Damage" в документации TrueCrypt.
Мнящие себя "недаунами", но при этом неспособные отыскать этот раздел в документации самостоятельно, могут проследовать по прямому линку.
Поэтому интересно, можно ли реализовать аналогичный функционал средствами линукса
По которому инструкция для чайников с окошечками и кнопками, объясняющая, куда тыкать. Неужели TC до такой степени кулхацкерский? Даже DC намного лучше задокументирован, хотя он менее популярен.Почитаем. Когда видишь инструкцию с окошками, и пару абзацев между ними, надежда найти там важную техническую деталь стремится к нулю. Те, для кого такие инструкции пишут, вникать в технические детали всё равно не будут.Можно об этом подумать, но TC'e заведомо проще: им не надо собирать функционал из штатных возможностей каждого дистрибутива Linux, а достаточно всего лишь внести его в собственную программу. Обратная сторона их подхода — возникновение вопроса, зачем эта программа установлена. Не за тем ли самым, чтобы скрывать?
Ну что ж, следуем:
Правда, в этой цитате всё равно нифига не понятно, за счёт чего отрицаемость во внешнем контейнере возникает. Даже если система знает, куда не надо писать, и начнёт это претворять в жизнь, это отразится на структуре файловой системы внешнего контейнера, то есть, вынеждна полететь лесом либо отрицаемость скрытого контейнера, либо его защита от повреждений. Это то, что любой здравомыслящий подумает, почитав цитируемую документацию. Вопрос, однако ж, интересен, да и Гость (31/05/2013 13:51) настаивает, поэтому делаем официальный запрос
неземномуискуственному интеллекту и получаем ответ:Считайте мнение истиной в последней инстанции. Если хочется сделать что-то лучшее, чем TC, на основе DM, то скопировать идею с TC не получится — просто потому, что никакой особой идеи в TC нет. Смайлики в конце добавьте по вкусу.
Зачем делалась дефрагментация с перемещением всех файлов в начало (стандартная виндовая утилита так не делает) и почему после дефрагментации не было записи?
После дефрагметрации фрагменты файлов остаются на старых местах, почему вместо них там случайный мусор? Напомню, состояние диска когда все файлы находятся строго в начале не могло быть получено само собой. Что вы будете делать если внезапно в середине тома окажется неперемещаемый объект (в ntfs такие объекты есть)?
Извратиться по всякому можно, но это будет лишь размен одного трюка на другой. ИМХО отрицаемость это фикция и излишнее усложнение не несущее особой пользы.
Я бы не был столь категоричен, но разумное зерно в этом есть. Отрицаемость, даже при её идеальной реализации, требует аккуратной легенды, продуманных пропорций между объёмом обманки и в всего контейнера, соответствие содержимого обманки легенде и так далее.
Чисто технически всё решается и без сверхусложнённых трюков. TC растворяет скрытый контейнер в открытом, пользуясь тем, что шифрованные данные неотличимы от случайных. В методе же DM скрытый контейнер растворяется в случайных данных неиспользуемого места диска. Суть (методика) в обоих методах одна и та же.
Что касается модели отрицаемости TC, там, по всей видимости, была идея создать юридически приемлемую неоднозначность. Грубо говоря, авторам не столько важно, какие TC вызывает подозрения, сколько то, что отрицаемость TC будет достаточной для непредвзятого суда, опирающегося на юридические формальности и требующего серьёзные обоснования каждого подозрения. Может, в РФ эта модель совсем неприменима, но ведь и TC — продукт не очечественный.
Любая нормальная утилита для дефрагментации стремится не только собрать несколько кусков файлов в один, но и убрать на диске пустое пространство между файлами. Тогда новые файлы, добавляемые на этот раздел, не будут дробиться на множество фрагментов. Из-за того, что файловая система распихивает данные по пустующим секторам.
Любая дефрагментация тома в fat сводится к тому, чтобы сдвинуть данные всех файлов во младшие сектора.
Да и за двадцать лет использования дисков на fat'ах уже не одну сотню раз убеждался, что на свеже отформатированном томе файлы попадают именно в начало, в первые сектора. Потому, если до этого данные на диске подлежали уничтожению, то во всех его секторах, кроме занятых файлами, и будет случайный мусор. Такое же наблюдается и в контейнерах созданных TrueCrypt'ом.
Этот самый Гость (01/06/2013 02:59) типичный образчик тупого, неквалифицированного, но жутко самовлюбленного человека. Таких лучше сразу посылать на три буквы. Это паразиты, ничего нового в общество не привносящие, поскольку им лениво изучать что-либо самостоятельно. Познают мир через вбросы провокационных и априори ложных заявлений. Такие находят себя в том, чтобы в комиссарах ходить, да заград отрядами командовать. Свое желание жить не думая где-то в глубине души приравнивают к "наеб@ть систему".