Регистрация25.10 // Аудит сборки TrueCrypt 7.1a не выявил расхождения с исходными текстами
Опубликованы результаты результаты сравнения официальной бинарной сборки TrueCrypt 7.1a для Windows и сборки, сформированной собственными силами из исходных текстов. Анализ различий показал, что в официальная бинарная сборка не содержит скрытых функций и тождественна поставляемым исходным текстам. Разница наблюдается только в элементах, связанных со сборочным окружением и используемыми на этапе компиляции опциями.
Исследование показало, что правильный подбор используемых при сборке инструментов, воссоздающий оригинальные условия сборки, позволяет сформировать тождественный исполняемый файл и подтвердить, что в распространяемые производителем бинарные сборки не были внесены скрытые изменения. Таким образом удалось подтвердить отсутствие скрытых модификаций без необходимости выполнения трудоёмких операций по обратному инженерингу исполняемых файлов. В настоящее время, усилия по аудиту проекта TrueCrypt могут сосредоточится на изучении исходных текстов и методов шифрования, .
Кроме того, представителям проекта IsTrueCryptAuditedYet удалось связаться с авторами TrueCrypt, которые приветствовали идею проведения независимого аудита безопасности их продукта. Напомним, что в рамках проекта IsTrueCryptAuditedYet создана инициатива для подтверждения отсутствия в TrueCrypt проблем безопасности и скрытых бэкдоров. Одним из подозрений было отсутствие гарантии, что бинарные сборки, которые составляют основную массу загрузок, не содержат закладок и собраны на основании публично доступного исходного кода без внесения скрытых изменений.
Источник: http://www.opennet.ru/opennews/art.shtml?num=38259
Честно говоря, я считаю ваш пример натянутым. В вашем случае, когда вы/мы/остальные лезем во внутренности TBB, это на чём-то неминуемо сказывается. Знаете, можно было бы сильно упростить мою инструкцию, если написать драйвер, позволяющий работать на запись с обоими разделами одновременно (и скрытым и нескрытым), но я ведь не зря отказался от этой затеи. Возможно, от теоретических предпосылок до практической эксплуатации там как до Луны пешком, но мне заранее понятно, что это нельзя сделать идеально, и я решил проблему с перхотью проще: отрубил голову.
Загрузка с внешнего носителя, который нужно каждый раз затирать, запрет на изменение данных во внешнем обманном разделе, необходимость время от времени вручную пересоздавать разделы и данные на них, неудобство — это та цена, которая платится за универсальность и идеальность. Т.е. решение всех спорных вопросов я решил за счёт потери удобства. Для Tor Project'а такой подход немыслим, там неминумо будут компромиссы, и то, что вы делаете — это заранее какой-то компромисс, вы сами же в этом сознавались. И я полностью с вами согласен, что в вашей схеме быть идеально уверенным трудно, хотя что-то гарантировать всё же можно (к примеру, запрет файерволлом соединений в обход Tor).
Может быть, не все ещё до конца поняли, но никаких свободных разделов нет. Есть разделы, но все они отформатированы и «заняты». На файловых системах этих разделов хранятся, пардон, файлы. Да, файловые системы забиты не битком, на них есть свободное место. Это значит, что свободное место есть на разделе. Вот в это свободное место мы и пишем скрытые данные. Наличие не до конца заполненных файловых систем тут ещё не предлагали крминализовать? Кстати, даже без всякой отрицаемости естественным образом скапливаются архивы, которые годами некогда посмотреть и разгрести. Свободное место в разделах, на которых эти архивы хранятся — неплохой кандидат для использования в качестве скрытого.
Вообще-то каждый проход записи на многогигабайтный диск — это время, время и ещё раз время. Минимум — один раз пройтись чем-то (надёжней рандомом, чем нулями). IMHO, это объяснение получается совершенно естественным.
Своп, шифрованный статическим ключом? Вот этот статический ключ и заставят предъявить. Или вы хотите сказать, что ключ там статический, а вы будете говорить, что он генерировался динамически, и вы его, естественно, не знаете? По-моему, это явно менее отрицаемо, чем то, что я предложил. :) Это не сильно отличается от случаев типа «забыл пароль» или «никогда его не знал, потому что <подставить нужное>».
Я принципиально не использую выделенные разделы. Я предлагаю использовать свободное место на файловой системе, превращая его в логический раздел через dmsetup. Пустые разделы, IMHO — куда большее паливо, и объяснение их существованию вида «создал, но не стал использовать», тоже не очень правдоподобно.
Вот! Цель достигнута. :-) Анонимность невозможна без массовости, так и тут: правдоподобное отрицание невозможно без массовости присутствия «косвенных улик» у всех и каждого. Кстати, объяснение может быть и другим: да, использовал шифование, был полный диск данных, потом оно мне стало ненужным, я заново переформатировал диск и установил новую ОС. Случайные данные в неиспользуемых местах остались от ранее использовавшего шифрования. Пароль вот он: <xxx>. Не подходит? А к чему он, по-вашему, должен подойти, если при инсталляции новой ОС заголовкок старого контейнера мог затереться новыми данными, что делает знание старого пароля полностью бессмысленным?
P.S. По-моему, есть одна важная мысль, которая до людей здесь не доходит. Ценность в схеме в том, что она абсолютно универсальна. Правда, здесь нет моих заслуг, это тривиальный факт, а по сути — основное назначение dmestup. Если у вас есть прямая адресация дискового пространства, которая не имеет сигнатур и ни от чего не зависит, то вы можете делать всё, что угодно:
Да, получается, в каком-то смысле, безопасность через
неясностьусложнение и запутывание, но и Tor ведь идёт с обфускацией по точно тому же пути. Наша цель — поднять затраты на анализ диска. Даже одно то, что эксперту придётся вручную месяцами сидеть и разбирать этот мусор, будет означать то, что в 999 из тысячи случаев никто не захочет этим заниматься. А когда появится конкретный тул для анализа, можно устроить гонку вооружений. Раз нет у задачи абсолютного решения, достаточно быть не идеальным, а просто на шаг впереди: использовать такую схему, анализ которой себя не окупает. Как было неоднократно замечено в других тредах форума, даже тупое наивное отсечение стандартизированных средств анализа в подавляющем большинстве случаев решает проблему, а если там будет ещё и что-то оригинальное и хоть как-то обоснованное (то, что предлагается здесь), то ещё лучше.комментариев: 9796 документов: 488 редакций: 5664
Я дал кривые ссылки, по которым неудобно читать всю дискуссию. Прочитайте всю тему здесь. Обратите внимание на это сообщение. Сравните его с вашей схемой, хотя у вас она конечно более навороченная. Обратите внимание на аргументы, выдвинутые против подобных схем разработчиком Арно Вагнером в дискуссии далее.
По мне — этих аргументов против достаточно, по вам — нет. Вот и вся разница, а так все всё понимают и идея витала в воздухе лет десять, в общем виде известна.
комментариев: 9796 документов: 488 редакций: 5664
Будет вам GUI сразу для всех трёх. В Гноме и ещё где-то для LUKS можно монтировать, просто щёлкая по иконкам. Хотя для красноглазиков GUI — это сразу -100 к безопасности.
HISTIGNORE забейте по шаблону. Хотя, зачем? С историей же наоборот набирать быстрее. Или вы думаете, что отключив историю, вы скроете факт обращения к дискам? Он всё равно оседает в куче логов, даже если вы открывали эти диски через GUI.
Не к дискам, а пути к ключевым файлам и их названия будут.
комментариев: 9796 документов: 488 редакций: 5664
Взаимодополняющие параграфы :)
По-моему, оно там уже полностью есть, или нет?
Я считаю, что это существенно сужает область применимости TC mode, раз всё равно придётся ставить TC для того, чтобы воспользоваться TC-специфичным функционалом.
Для отрицаемости я бы обратил внимание не на TrueCrypt mode, а на plain mode. Последний man cryptsetup есть, например, здесь. Наверное, plain mode — это и есть то, о чём сказано в /comment45000:
Судя по man cryptsetup, при использовании plain mode никаких заголовков нет (хотя можно использовать внешний ключевой файл, если кто пожелает, или иметь LUKS-заголовок во внешнем файле). Кроме того, есть следующие полезные опции:
Складывается впечатление, что цирк с openssl magic не нужен, а всё необходимое уже есть в cryptsetup: берём любое блочное устройство с нарезанной на нём файловой системой и данными; находим свободное место; вычисляем размер этого места и его оффсет относительно начала блочного устройства; передаём эти данные cryptsetup, указывая всё блочное устройство целиком, как target device; и, собственно, всё. Было бы лучше, если б заголовок был, но он шифровался чем-то стандартным (как в TrueCrypt), но и plain mode уже номинально достаточна для отрицаемости.
По ссылке unknown'а:
А что, если опечатаюсь? Поидее проблем быть не должно — просто при попытке монтирования будет ругань на неопознанную файловую систему, но на сам раздел ничего записано не будет, информация в контейнере не исказится. Так ведь?
А почему AES128-XTS, а не AES256-XTS?
Почитал параграф в man под названием
Мне кажется, что в plain mode при машинной генерации паролей (мастер-ключей) нет смысла использовать нетривиальный --hash (разве что для защиты от атакующего, наблюдающего за вводом пароля — вдруг не все символы запомнит?) — лучше подобрать правильную длину и всегда указывать --hash plain.
комментариев: 9796 документов: 488 редакций: 5664
Почти везде так, даже в OpenSSL.
комментариев: 9796 документов: 488 редакций: 5664
На компах конца 90-х шифрование на десктопе отнимало процентов 20, параметры ключа были важны: избыточно большой ключ старались не выбирать. Сейчас это может быть актуально на каких-нибудь тормозных гаджетах.
Прочитали. Ниже представляю полный разбор этой, этой, этой и других дискуссий попорядку.
Это, как и ваш комментарий
заставляют задуматься. Серьёзные люди говорили:
Это ставит вопрос о том, должно ли правдоподобное отрицание реализовываться общеизвестными способами или всё-таки самопальными костылями? Уменьшит ли отрицаемость её добавка в cryptsetup? Если схема известна и растиражирована, будет ли она давать меньшую отрицаемость? Цитата
тоже немкает на принцип медведя, т.е., что есть разница между «openly advertized» и «advanced
knowledgefeature/misuse».Как бы да, но есть минусы, если это приводит к массовому костылестроению, или если нельзя получить требуемую функциональность из этого простого тула даже с помощью костылей.
В предложенной схеме нет этих проблем. Авторы держат в голове устаревшую схему TrueCrypt, содержащую множество изъянов, и мысленно критикуют именно её, а не весь набор всевозможных конструкций отрицаемости. Автор пишет, что обманная ФС (или контейнер) либо должна быть малозаполненной, либо не использоваться, чтобы не затереть скрытые данные. С первым всё очевидно: предлагаемая схема не вносит никаких ограничений на тот процент, который должна занимать обманная ФС. Со вторым тоньше, но ответ тоже на поверхности: если придерживаться предложенного регламента, то всё, что увидит атакующий — это то, что обманная ФС не менялась последние сколько-то дней/недель/месяцев. Никаких других отличительных признаков на ней нет: даты создания файлов разные, создавалось всё самым естественным образом, потом могло многократно меняться и т.д. Да, после того, как создали скрытый раздел, изменения в обманке возможны, только если параллельно производится полное пересоздание скрытого раздела и полная перезапись файлов в него. Каждый может подумать сам, какой срок отсутствия изменений в данных вызывает подозрения, а какой нет, стоит ли заблаговременно сделать изменения, если предстоит пересечь границу неблагоприятного государства и т.п. Даже без всякого отрицания естественным образом почти у каждого накапливаются архивы не особо чувствительных данных, которые меняются очень редко.
Именно поэтому отсутствие специфичного софта было взято как основное требование, а равно и отказ от работы со скрытыми и обманными разделами из-под одной и той же ОС. Обманка должна работать исключительно с внешнего LiveCD/LiveUSB-носителя, который не сохраняет никаких следов своей работы где-либо помимо скрытого раздела.
Я не понял, что они предлагают. Они хотят сказать, что есть такие относительно традиционные разбиения дисков, при которых всё равно остаётся несколько мегабайт свободного места, и вот его-то и можно будет использовать?
Как уже было сказано выше в этой ветке, есть множество вполне разумных объяснений того, зачем был сделан предварительный «crypto-blanking», поэтому hint неубедителен.
Это неправда. У стороны обвинения должны быть убедительные доказательства того, что подозреваемый
- Имеет скрытые разделы.
- Обладает возможностью их открыть.
То, что ему «разрешено забыть», ничего не меняет: фича остаётся полезной, если забывчивость будет считаться судом менее убедительной, чем отсутствие скрытых данных. Т.е. забытие пароля и отрицаемость — почти ортогональные понятия, незачем их смешивать.Следуя такой логике, можно вообще отказаться от шифрования. Если противник применит бандитский криптоанализ, то уже ничего не поможет, поэтому зачем шифровать диски?
То же самое можно сказать и про обычное шифрование. Вместо того, чтобы искать пути решения проблемы (чай мы тут не защиту от копирования изобретаем; пока ещё никто не доказал, что отрицаемое шифрование невозможно), автор предпочитает позицию страуса — отрицать возможность её решения или приводить аргументы ad absurdum. А вы думали, в рассылках не бывает троллей?
Computer is for access control, not for safe data encryption. Ad absurdum — такой, с ним не поспоришь (side channels attacks в свидетелях).
Люди палятся на незнании того, как работает TC, в случае которого высказанная претензия действительно справедлива.
Разве у хидера переменный размер? Или переменный размер бывает только у внешнего файла, куда экспортируют хидер?
Любая хорошая идея находит сначала военное, а только потом гражданское применение. Это нормальное положение вещей. Военное применение используется для решения самых важных вопросов — свободы, независимости, собственного существования.
Каждый городит огород из тех инструментов, с которыми он лучше знаком, но предложенный метод всё равно бред, потому что тщательно заархивированный (сжатый) видеопоток данных не есть их рандомизация, а, следовательно, присутствие рандомизированных вставок в видеофайл можно будет распознать (битость скачиваемого файла не настолько его портит, чтобы он начал годиться под контейнер). Кстати, это одна из причин неидеальности обсуждавшейся здесь схемы запутывания, которая пишет данные в высокоэнтропийные места на разделе (в отличие от исходной схемы, её бы я не стал рекомендовать, как панацею — это только эксперименты на свой страх и риск).
Наверно, ссылка померла окончательно. У меня при заходе браузер пытается скачать Apple Quick Time файл на несколько байт. Что было по ссылке на самом деле, теперь можно судить только по архиву. Вроде ничего интересного.
Детский сад, что у вас, что в рассылке. Следов в системе — полные штаны. Кто вам запрещает создать /tmp как tmpfs в памяти и указать в конфиге шелла писать историю в файл на /tmp?
Очень показательная ссылка. :-)
По ссылке:
Звучит так, как будто у TC есть бэкап хидера, и этот бэкап хранится в конце раздела, а у LUKS бэкапа нет, и его хидер — только в начале. Unknown, не поторопились ли вы с заявлением «в новом формате LUKS заголовок имеет копию в конце тома, поэтому смысла затирать его через urandom нет»?
На тему будущего поддержки TC в LUKS единого мнения среди разработчиков нет. Вот, например, один смотрит на это достаточно позитивно и не исключает добавления прочих TC-возможностей:
Но другой (разработчик?) пишет:
Люди пишут о том же:
и
Его метод:
Это не моя схема (или если и моя, то явно не из последних). То, что предлагает автор, на уровне абстракций идентично тому, как это делает TC, а у меня к отрицаемости в TC есть вполне конкретные претензии (помимо собственно того, что ранее требовалось устанавливать сам TC, что ещё один минус к отрицаемости).
Получается, что при вылезании за пределы отведённого объёма теряется как защита от повреждений, так и отрицаемость (ошибки попадут в системные логи)?
Я умею троллить не хуже троллей в рассылках. Нули на диске ещё ничего не означают, потому что есть остаточное намагничивание. И нет никакой гарантии, что пользователь не использует надёжную схему коррекции ошибок для записи на диск данных скрытым образом через остаточную намагниченность. Вот пересекает он границу с занулённым диском, а как доказать, что остаточная намагниченность на диске случайна, а не шифрованные данные?
Предлагаю потроллить рассылку перлами:
- You are only safe if you do not have a computer.
- You are only safe if you do not have an edication in IT.
- You are only safe if you do not have a <подставить нужное>.
Чем мой троллинг толще их троллинга?То, что они предлагают (пересекать границу без шифрованных данных, а потом выкачивать их из интернета), как минимум, не отвечает на вопрос, как безопасно хранить эти данные дома. Всё держать в облаках? Очень смешно, ага. То, что «скачать на новом месте из интернета» можно только ограниченный объём (ну не терабайты же качать), эти советчики тоже не учитывают. А если граница пересекается не так редко? Каждый раз по терабайту качать?
Проще тогда этой методике следовать: данные в два этапа провозить и шифровать их одноразовым блокнотом. Первый раз везём два диска: на одном гамма, на другом шифртекст, соответствующий обманным данным. Если к гамме претензий не возникло, следующий раз везём шифртекст с настоящими данными и подставной ключ к ним, который бы их расшифровывал во что-то нейтральное.
И, да, я согласен с троллями, что ездить без шифрованных данных (а лучше вообще без компьютера и носителей информации) со всех сторон безопасней и даёт лучшую отрицаемость, но это не решение поставленной задачи, а уход от неё. Есть такой поучительный анекдот на тему логики:
Советы троллей, как сделать отрицаемость лучше, до боли напоминают этот пример.
В этом и состоит отрицаемость. Раз они сами всё знают, то зачем троллят? Отрицаемость в том и заключается, что нельзя ни доказать, ни опровергнуть (косвенных улик мало, они неспцифичны, и поэтому они недостаточны даже для юридически веского доказательства).
Эту позицию — да, можно понять.
Да, в предлагаемой схеме есть «risk of destroying them», поэтому неаккуратное обращение с обманкой испортит скрытый раздел, а аккуратное всё сохранит, не давая никаких «hint to an attacker», потому что информация о местоположении скрытого раздела не хранится в обманной ОС никаким образом. Критика автора была направлена против TC-подобной схемы, и тут я с ним согласен, что
Also keep in mind that in many situations (US border inspection, e.g.) the mere suspicion of a computer being present will be enough. Если нет ссылок на реальную юридическую практику, можно троллить, как душе угодно, особенно расширяя понятие «suspicion» до полного абсурда вплоть до «виновен вообще во всём, за исключением того, в чём свою невиновность можешь убедительно доказать».
Всем известная ссылка на вики остаётся сравнительно актуальной:
Вообще, если посмотреть на википедию, как некий срез общеизвестных методов, то там пишут:
Т.е. критикуется отрицаемость именно в рамках TC. И эту TC-отрицаемость ошибочно отождествляют с общим случаем отрицаемости в дисковом шифровании. Там же про распознавание скрытых разделов:
«Non-random encrypted data» — это, наверно, что-то новое в криптографии. :-) «Predictable cryptographic items» в бессигнатурном шифровании — это тоже весело, можно сразу статью в IACR писать. «Vulnerability to chi-squared randomness test» — отличие рандома от шифрованных данных? Я ж говорю, сразу статью в J. of Crypt. можно накатать. «Possession of deniable encryption tools» — вот поэтому и нужно для отрицаемости использовать только стандартный софт, который есть у всех. «Rubber-hose cryptanalysis» и «could lead attackers to continue an investigation even after» — очередной троллинг, где бандитам приписывают либо отсутствие логики, либо ту логику, которая нравится критикователям («забьют до смерти на всякий случай» и т.д.), игнорируя не только требование иметь хоть сколь-нибудь приближённую к реальности ситуацию, но и издержки, риски бандитов и т.п. вопросы.
В /comment58759 уже упоминалась ссылка на вики-статью «Key disclosure law». Рекомендую разработчикам cryptsetup поменьше заниматься спекуляциями и побольше заглядывать в
эту ссылкузаконодательство, больше конструктива будет.Кажется, в связи с новостью-предшественником здесь ещё не упоминалась замечательная ссылка от 2010-2011-го, в которой автор привёл 8 пунктов против использования TC (запрет на упоминание чего-то иного TC-совместимого на официальном форуме поддержки TC веселит; TC-team уже исправлили это в правилах?). Кстати, там же:
Значит, не я один так думаю.
Виновность/невиновность в чём? Есть подозрение в X. Решили, что подозреваемый сознательно что-то скрывает и не идёт на сотрудничество. Осудили за X. Теперь, если шифрования нет, выглядит так: подозревали в X, поглядели в компьютер, получили доказательства вины в X, Y, Z... Что выгоднее, шифровать или не шифровать? Вопрос риторический.
Мне не трудно показать вам ссылки на обсуждения этой проблемы, которые здесь велись лет 10 назад, а также на ваши посты в этих обсуждениях, чтобы спросить, где же та самая идея витала, а то десятки обсуждений, и ноль продуктива, всё ломается, всё неидеально, всё оставляет следы. В общем-то виде оно как бы понятно, чего хочется, но что толку от этого, если нет способа реализации? Давайте начнём с простого:
Ага, он знатно потроллил, но его можно понять: ему не хочется поддерживать те фичи и сложности, которые лично ему и на данном этапе его жизни неинтересны.
Это не аргумент. Вот пусть те, у кого исключительный случай слабых систем, меняют дефолты под себя, задавая иные опции, а у других людей, на нормальных компьютерах, пусть используется самый сильный вариант по умолчанию.
Не согласен. Во-первых, никаких новых аргументов я там не увидел. Все эти вопросы, опасения и пр. уже обсуждались, обдумывались, решались здесь. Ничего существенно нового и интересного, что я бы узнал из этих ссылок, нет. Единственное исключение — вот этот не очень внятный пост, но об этом ниже.
Если подвести итог под всеми этими дискуссиями в рассылках, складывается примерно следующая картина:
Теперь по поводу предложения: в принципе, идея интересная, и сводится, как я понял, примерно к следующему. Когда мы создаём LUKS, мы задаём не только пассфразу, но и процент от объёма, который мы хотим использовать. Из этих двух параметров выводится информация об аллоцированных блоках под раздел. Её можно писать в хидере в шифрованном виде. Извлечь её можно только по пассфразе. И таких скрытых разделов может быть много, доступ к каждому из которых открывает своя пассфраза (естественно, чтобы создать новый раздел так, чтобы не испортить существующие, нужно дать пассфразы на все ранее созданные разделы). Каждый раздел можно проассоциировать со своим слотом, и проверить, используется ли слот, можно будет только зная правильную пассфразу к нему. Если слот не используется, то никакая пассфраза не будет валидной. Т.е. вместо того, чтобы, как TC, делать обманные разделы и скрытые, автор предложил, в некотором смысле, сделать все разделы скрытыми по умолчанию. Чтобы открыть нужный скрытый раздел, нужно будет указать номер слота и пассфразу. Без этих двух параметров не будет известно ничего: используется ли слот, сколько в нём места и т.д.
Казалось бы, то, что предлагает автор, уже и так можно сделать с помощью LVM, но это неправда. С LVM возникают все те же проблемы, какие были при попытках использовать обычные дисковые разделы вместо dmsetup:
- Если раздел создан, но якобы не используется, то это подозрительно.
- Если раздел создан, а потом удалён, то как с ним работать? Не повиснет ли система? Где хранить заголовок LVM, содержащий информацию об этом дополнительном разделе? Можно ли дать гарантию, что встроенные средства LVM не перемещают extent'ы, не пишут ничего в выделенное свободное место?
Т.е. не вижу, как это сделать без низкоуровневого функционала dmsetup.Наконец, уже обсуждавшаяся выше политика: а надо ли вообще что-то делать? Должно ли существование механизмов отрицаемости тоже быть отрицаемым? Если в LUKS официально добавят даже хороший функционал типа вышеописанного, он перекочует во всевозможные инструкции; каждая собака будет знать, что в LUKS есть отрицаемость, а каждого, кто использует LUKS, надо подозревать в использовании этих разрекламированных фич. И совсем другое дело — когда создание отрицаемости требует городить костыли, нет единых стандартных решений, и потому кажется логичным, что без особых на то оснований подозревать случайно попавшегося LUKS-юзера в использовании отрицаемости не будут. Всё-таки одно дело — вести стандартные параметры в командную строку, и другое дело — нагородить кучу костылей и подпорок, иметь для этого нужную мотивацию и квалификацию. Интуитивно мне кажется, что юридически обосновать, что юзер целенаправленно произвёл сотни непростых манипуляций с диском, ОСями и настройками, чтобы получить определённый вид отрицаемости, сложнее, чем обосновать возможность использования стандартной фичи, задаваемой парой опций в командной строке. Это ставит вопрос, нужна ли нам отрицаемость в LUKS вообще. Может, по старинке оно и лучше?
Unknown, теперь ваш ход.
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 9796 документов: 488 редакций: 5664
Сил разбирать ваш пост нет. Для начала пара общих соображений, чтобы не было недопонимания.
Теперь чуть подробнее, но всё равно в общем. Я набираю массу команд и вроде сложных и пр. И вроде редко что-то путаю или порчу, но уверен, что скрытый контейнер при ручном костылестроении с требованием скрытности запорю обязательно. Оффсет перепутаю, не тот раздел открою и т.д. И чисто эстетически считаю, что схема должна быть обоснованной и из коробки или никакой. Ещё раз — да, мне хочется что-то нехорошое по аналогии сказать в адрес разрабов Tor'а. за то что TBB по умолчанию настроен не на системный Tor. И несмотря на то, что с отвязкой вроде как разобрались и поправить надо каждый раз всего пару строчек и опций, но каждое обновление TBB — это выбешивающий гемор вместо дежурного update/upgrade или конфигов вида «один раз настроил и всё работает». Здесь чем-то похоже.
Затем, многие судят всех по себе. Отсюда непонимание. Разработчики не понимают сложных фантазий пользователей, пользователи не понимают разработчиков, я не понимаю, как вы привыкли работать со своей системой, кому какой и в чём уровень красноглазия приемлем и т.д.
Вот вы смеётесь над HISTIGNORE — типа полные штаны следов. А мне может просто пофиг, а на самом деле, всё даже естественнее. Возможно, у вас в голове не укладывается мысль, что не все столь аккуратны как вы. У меня в HISTIGNORE честно забит cryptsetup и все потенциально опасные команды. После того как по ошибке забил в строке вместо имени раздела пароль к нему. Станет больше нужно удобства, то впервую очередь скорее ещё придёться жертвовать отрицаемостью. С другой стороны — у меня такое вот объяснение наличия cryptsetup в HISTIGNORE, я его даже не придумывал специально ни для какой отрицаемости, оно само так сложилось.
Над свободным местом вам там было очень весело. А я часто забиваю весь физический том рэндомом, а внутри создаю логические с запасом на вырост и оставляю кучу свободного места. Потому что расширение томов с ФС менее глючно, чем сжатие.
Со сценариями использования свопа и гибернейта у меня свои замороки — он в трёх разных состояния бывает в зависимости от того, как использовался гибернейт: и через /dev/urandom инициализируется, и через keyscript_derived, и может быть с поменянным ключом, который туда пишется рэндомом для затирания и при всём желании мне будет потом нечего выдать для расшифровки.
Это только то, что я ещё могу вспомнить.
Ну т.е. кто активно использует шифрование и экспериментирует с этим, не скрывая сам факт этого, у него и так появится достаточно поводов для отрицаемости. У меня валяются какие-то винты или флэшки, я даже не могу вспомнить ни под каким давлением: я там реально что-то когда-то шифровал или просто забивал рэндомом для каких-то экспериментов и забросил.
При пересечении границы с таможней это может не сработать, да там ничего доказывать не надо, слабообоснованных подозрений достаточно, чтобы просто развернули. Типа: отказ во въезде негражданам — это же не наказание, пускаем только кого хотим, как в гости.
Отрицаемость мне была бы интересна, если бы действительно был разработан какой-то протокол из коробки. Например, в будущем исчезнут все диски HDD, будут только SSD или ещё какие с произвольным доступом. Так чтобы можно было задать функцию: раскидывать шифртекст псевдослучайным образом по всему объёму диска без потери производительности, а при коллизии блоков разных контейнеров, они бы разносились по другим адресам, но чтобы без знания пароля всё выглядело как некое непрозрачное облако с данными. Из которого знание одного из паролей вытягивает часть информации, но расположение секторов ничего не говорит о наличии других разделов. Т.е. когда будет какой-то качественный скачок в технологиях может оно и появится. А сейчас неохота ни городить костыли, ни требовать от разработчиков LUKS ломать и усложнять свой стандарт ради подобного рода фич.