шифрование неразмеченного дискового пространства

Где-то (здесь?) у нас высказывалось предложение по выполнению такого трюка с помощью TrueCrypt. Деталей, к сожалению, не помню. Поищите сами или ждите, чтобы кто-нибудь напомнил, в какой теме это обсуждалось.

С помощью TrueCrypt 4.3 можно такое сделать, если есть отдельный (не системный) полностью пустой диск (без mbr, без разделов) – только что так отформатировал флэшку.

Еще можно сделать сделать скрытый контейнер на обычном fat32 разделе – те система будет видеть партицию как обычный раздел (там могут быть какие-то файлы и с ними можно работать как обычно), а при монтировании раздела в TrueCrypt будет открываться доступ к скрытому разделу. При этом явных следов скрытого контейнера в разделе не будет – обычный раздел с файлами и все.
Делается так:
1. создается на диске раздел нужного размера, не форматируется
2. в TrueCrypt создается обычный зашифрованый раздел с fat32
3. в обычном зашифрованом разделе создается скрытый раздел, на 20-30% меньшего объема, можно fat32, можно NTFS
4. теперь из под виндового менеджера дисков форматируем весь раздел в fat32 обязательно использую БЫСТРОЕ форматирование!
5. получаем раздел, который система видит как обычный раздел, на который можно записать в начало файлы (15-25%, чтобы с запасом).

ИМХО этот вариант имеет определенные плюсы, тк наличие в системе неразмеченного раздела или диска вызывет ненужные подозрения даже у простого человека.

PS этот метод придумал не я, оригинал смотреть здесь https://www.pgpru.com/Comment11193

Я не знаю как там во всяких виндах (это другая такая ОС что ли?) но обычно программа
не может лезть в обход ОС по самой конструкции последней, по самой идеологии.
Чтобы ОС обратилась к какому-то месту на диске, это место на диске должно принадлежать
ОС, то есть должно быть помечечно как таковое с точки зрения самой ОС – обычно это
реализуется посредством прописывания заголовка в разделе диска где должна быть указана
как минимум геометрия раздела (а пожеланию можно ещё указать какой ОС принадлежит и какая
ФС там если имеется таковая). Основная проблема состоит в том, что эту информацию
о геометрии нельзя загрузить сразу в память ядра в BSD не записывая её предварительно на
диск в указанное место. Скорей всего, такое же положение дел и с линуксом и с "виндой"(?).
В данном случае проблема сводится не к принципиальной невозможности а ктому что пока
не реализовали этот функционал. С другой стороны, если оппонент не дурак, он всегда
может произвести экспертизу свободного дискового пространства и заявить что с такой-то
(довольно большой) вероятностью данное место на диске есть криптораздел или криптотом.
Если речь идёт о мизерных объёмах то можно списать на то что там был записан фильм,
но если никаких стандартных сигнатур диска не найдётся на разделе в 40 гигабайт, то
говорить уже будет не о чем. Умные люди потому изобрели стратегию трукрипт с "двойным дном",
но, как подсказывает мне интуиция, получи широкое распространение эта технология –
проблема останется той же – нет стегоОС, стегоОС in mind. А пока само наличие трукрипта
на диске может быть легко расценено как средство использования его двойного дна.
Я здесь не касаюсь правового поля (налчие шифрованной информации само по себе не является
обвинением, но может поспособствовать подозрениям суда). Итак, чтобы решать проблему
основательно нужно создавать стегоОС, которая будет комплексно стегонаграфической
во всех смыслах: распространена, её налчиие не вызывает подозрений, по умолчанию
логи, которые потенциально могли бы в некоторых случаях дискредитировать
анонимность не пишутся и т. п. А поскольку большинство не понимает зачем вообще
что-либо шифровать, то огромной птребности в стегоОС нет. Для тех же, кому она
нужна, единственный способ жить есть изобретать костыли под вид "шифровать свободное
место на диске" или что-то в этом роде.

Чтобы ОС обратилась к какому-то месту на диске, это место на диске должно принадлежать
ОС, то есть должно быть помечечно как таковое с точки зрения самой ОС – обычно это
реализуется посредством прописывания заголовка в разделе диска где должна быть указана

Разве нельзя обращаться к блочному стройству, как к raw-data с параметром offset?

Когда то с гуру обсуждал этот вопрос и сошлись на том что нельзя. Задача состояла в использовании ФС на свободном месте на диске. Её там можно каким-то раком нарезать и использовать? Не трогая disklabel, имеется в виду.

ЭЭЭ? Да это стандартная возможность losetup. Там только криво реализовано, больше 4 гигов оффсет не делает.

spinore
Не понял о какой геометрии идет речь. Из ОС можно обратиться к любому произвольному сектору диска (физическому сектору), и не имеет значения размечен диск на разделы или нет, отформатированы разделы или нет. Не вижу в этом ничего особенного.

Её там можно каким-то раком нарезать и использовать? Не трогая disklabel, имеется в виду.

Здесь https://www.pgpru.com/Comment11193 по сути получается обратный порядок действия – сначала создаем криптоконтейнер на разделе с некоторым смещением от начала, а потом прописываем разделу заголовок так, чтобы он был виден как отформатированный в fat32.
И почему бы этому не быть? Или я не улових ход мысли?

ent, вохможно вы правы. Я в этом не специалист и мне пока надо обсудить этот
топик с тем кто утверждал обратное – не более того.

(налчие шифрованной информации само по себе не является обвинением, но может поспособствовать подозрениям суда). Итак, чтобы решать проблему основательно нужно создавать стегоОС, которая будет комплексно стегонаграфической во всех смыслах: распространена, её налчиие не вызывает подозрений

Поглядел "сабж" в user-friendly-дистрах Linux. В Ubuntu умолчальный инсталляционный диск не позволяет включить шифрование диска, и даже не упоминает про такую возможность. Чтобы включить шифрование во время инсталла, нужно воспользоваться диском для "альтернативно одарённых" (alternate install CD), про существование которого знают только те, кто итак уже в теме. Т.о., типичному пользователю даже такой альтернативы не предложат (да и многие ли вчерашние пользователи win знают, что можно шифровать диск целиком, а не пофайлово?). В Linux MINT всё ещё лучше: шифрование при инсталляции включить вообще нельзя. На форумах предлагают установить убунту с альтернативного CD, а потом отMINTить её. Ужас. А так, если подумать, сколько пользователей Ubuntu по всему миру... Если б было шифрование дефолтом, меньше бы выделялись те, кто "мануально шифрует". На десктопе нет критичности с скорости работы с диском как на файлопомойке – почему бы не включить шифрование диска паролем администратора по дефолту? Если от фичи нет вреда, а лишь польза... Заговор? Или недальновидность девов? В качестве аргументации пишут "среднему пользователю это не нужно, потому и нет такой фичи" – действительно, зачем среднему пользователю защищаться и замок на двери вешать :-( Сайты с авторизацией без https, видимо, аргументируются аналогично.

[Ubuntoсрач] А что еще можно ожидать от Шатлворта, который единолично занят утверждением перестановок кнопок в Убунтогноме на левую сторону, переманиванием пользователей с MacOS и прочими "вау!-фичами"?

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

Интересно, там хотя бы gpg-подписи пакетов при инсталле проверяются или "среднему пользователю это не нужно"?
[/Ubuntoсрач]

На десктопе нет критичности с скорости работы с диском как на файлопомойке – почему бы не включить шифрование диска паролем администратора по дефолту?

Может быть потому, что разработчики не хотят удовлетворять потребности меньшинства ценой значительного ухудшения для большинства? Даже на очень мощном десктопе бенчмарки видят разницу между незашифрованными и зашифрованными дисками, а на каких-нибудь нетбуках эта разница может достигать 4-5 раз. Для большинства, которому не нужно шифрование, это принесет кучу геморроя с потерями данных после забывания пароля, это вызовет несовместимость с другими линуксами и виндой, это вызовет катастрофическое замедление работы на нетбуках и резкое уменьшение времени автономной работы ноутбуков, это вызовет проблемы при смене пароля (я сменил пароль, старый забыл, потом достал с полки диск который юзал год назад и обнаружил сюрприз...). Причин достаточно или продолжать?
Если разработчики будут включать полное дисковое шифрование по-умолчанию, то пользователи их без соли съедят, и будут правы.

Даже на очень мощном десктопе бенчмарки видят разницу между незашифрованными и зашифрованными дисками, а на каких-нибудь нетбуках эта разница может достигать 4-5 раз.

это вызовет катастрофическое замедление работы на нетбуках и резкое уменьшение времени автономной работы ноутбуков

На многоядерниках — десятые доли процента нагрузки на одно ядро процессора (и это даже без аппаратной поддержки AES в новых процах), скорость работы с диском соответственно тоже практически не меняется. Судя по экспериментам с полным шифрованием ещё на старых 300 MHz компах (где-то 20% проца) не может быть в 4-5 раз.

несовместимость с другими линуксами и виндой

CryptoAPI находятся в дефолтном ядре Linux. Уже давно. Набор утилит для работы с ними также. С версиями cryptsetup-LUKS/CryptoAPI теоретически могут быть проблемы совместимости, если кто-то вручную залезет в самые продвинутые опции и выберет самый последний недефолтный режим шифрования.

Чтение разделов Lin из Win? Можно завести отдельный раздел для перекидывания данных, а вообще такая совместимость нужна?

И вообще о какой совместимости речь? Зачем другим Linuxам физически подцепляться к винчестеру? Если надо восстановить шифрованные данные, то можно взять LiveCD с последними версиями CryptoAPI и утилит. Расшаривают и передают файлы на другие системы по сетевым протоколам, на которые дисковое шифрование никак не влияет. Флэшки и съёмные накопители — хотите шифруйте, хотите нет.

Про проблемы с обращением с шифрованием вообще и пофигизмом пользователей понятно, поэтому:

Если разработчики будут включать полное дисковое шифрование по-умолчанию

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

Интересно, там хотя бы gpg-подписи пакетов при инсталле проверяются или "среднему пользователю это не нужно"?

Точно срач :)

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

Вообще да, apt у них общий :) Им бы пришлось специально выпиливать эту возможность. Про подписи конечно совсем не в тему.