Да, такой вопрос мною уже поднимался, но у меня нет готового ответа, а у вас есть. Остался только один вопрос — можно ли вам верить. ☺


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

На самом деле, клятый udev можно выпилить, если это принципиальный вопрос жизни и смерти, но не хотелось бы так глубоко вмешиваться в автоматику того же Debian. Иногда udev даже служит добрую службу, когда диск на новом железе определеяется как sdY, а не sdX, и всё взлетает автоматически благодаря ему, но у всего есть обратная медаль.

P.S. Вспомнилось к слову. Делал копию системы, и сделал там VG с тем же именем, что и на основной. А потом вдруг понадобилось её подключить. И вот коллизия VG-имён, ничего не получается сделать. Теоретически должно разруливаться по uuid'ам, но я как ни пытался, у меня не взлетело (вбивать uuid'ы вручную в аскетичной консоли загрузчика, где нет ни мыши, ни screen — ещё то удовольствие). В итоге взял, загрузился с LiveCD, переименовал, всё прошло успешно. Позже потом надо было загрузиться с диска с переименованным VG. Он грузит корень с того, что указано в настройках, и в итоге дропается в initramfs/initrd на стадии загрузки (нужная VG не найдена). К счастью, там есть консоль и нужные тулзы, так же запустил lvm и в открывшейся среде через vgrename восстановил исходное имя. Udev как бы был призван решить множество подобных половых проблем...

Пока шифрпанки всякие энтузиасты насилуют мучают наследие TrueCrypt и пытаются перевопроизвести его костыльными подручными средствами Linux, исследователи уже формализовали модель HIVE (HIdden Volume Encryption) и реализовали в средствах работы с блочными устройствами Linux, что описано в работе Toward Robust Hidden Volumes using Write-Only Oblivious RAM.

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

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

Именно в /etc/lvm. Курочить изкоробочные конфиги для заметания следов этого безобразия не предлагать. ☺

Спасибо за ссылку, не знал про такое. Как раз собираю библиографию по TC-техникам, и упомянуть это будет очень в тему.


...то работать оно не будет, будь оно хоть трижды безопасно теоретически. Одни из первых требований к таким механизмам — встроенность в ОС по умолчанию и распространённость. К счастью, ни у dmsetup, ни у LUKS сейчас с этим проблем нет. А самопальный или редкий софт будет палевным просто по факту своего инсталла в системе.

Тем временем начинается второй этап аудита truecrypt
http://blog.cryptographyengine.....truecrypt-audit.html

Спец темы по truecrypt как бы нет. Задам вопрос здесь.
Зашифрован системный раздел. Произошел сбой загрузки ОС из-за одного из драйверов (происходит останов загрузки). Можно ли открыть снаружи раздел, чтобы достать информацию? Пробовал с флешки загрузится (Линукс) и с установленного ТС подмонтировать, но ничего не получилось.
Кто даст дельный совет, может опыт подобный был?

Ничего себе. А это что?

Касаемо существа вопроса, Вы же при зашифровании диска должны были создать Recovery CD.

"Ничего не получилось" — крайне неинформативный способ описания проблемы. Что не получилось? Программа вернула какую-то ошибку или сами ниасилили?

Помимо использования TC, в Линуксе зашифрованный Трукриптом диск можно открыть с помощью свежей версии cryptsetup, читайте его документацию.

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

Конечно должен и создавался, но где он.. ищу. Система ставилась в 2012.

1. Запускаю ТС
2. Выбираю раздел с установленной системой для монтирования.
3. Предлагается ввести пароль. Вылетает ошибка о невозможности.
Процетировать в настоящее время не представляется возможным, т.к. линукс запущен на другой машине.
Сейчас перезагружусь на "проблемной" машине и отпишусь.

))) Здесь как раз обсуждалась попытка обновить cryptsetup до последней версии. В репозиториях (у меня wheezy 7.9x32) 1.4.3, а актуальная вроде 1.6. Закончилось переустановкой системы.

Как мне кажется, допущены мною ошибки:
1. ТС нужно было запускать от root
2. Не было учтено следующее, т.е. не поставлена галочка:
Note: If you are attempting to mount a partition located on an encrypted system drive without pre-boot authentication or to mount the encrypted system partition of an operating system that is not running, you can do so by selecting 'Options >' > 'Mount partition using system encryption'

---

Указал путь монтирования. Вылетает ошибка – "mount: вы должны указать тип файловой системы".
В строке параметров монтирования указал – t ntfs. Не помогло.
Если ставить галочку на "Do not mount", то раздел появляется в слоте ТС.
Далее в терминале:
# mount -t ntfs /dev/mapper/truecrypt1 /media/111
Результат – куча текста об ошибках монтирования.
Что-то не так делаю.

крайне неинформативный способ описания проблемы.