Можно ли открыть криптоконтейнеры FreeOTFE под Linux?
Во времена, когда я был заядлым виндузятником я юзал FreeOTFE http://www.pgpru.com/soft/freeotf
Сейчас задаюсь вопросом, можно ли открыть криптоконтейнеры FreeOTFE под Линукс?!
|
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
Нормы пользования. Некоторые права на материалы сайта защищены по условиям лицензии CreativeCommons. Движок
openSpace 0.8.25a и дизайн сайта © 2006-2007 Vlad "SATtva" Miller.
|
||||||||||||||||||||||||||
комментариев: 9796 документов: 488 редакций: 5664
По умолчанию загрузочный скрипт настроен так, что после трёх неправильных попыток ввода пароля и соотвествующих пауз, загрузка продолжается с монтированием других доступных файловых систем по порядку.
Если вас это раздражает, можете вообще удалить строку из crypttab и монтировать вручную через две команды
Или можете поставить утилиту pmount, она позволяет монтировать в том числе и LUKS-шифрованные устройства в одну команду и даже без рутовых прав (можно создать список прав доступа пользователям на монтирование).
Что это за устройство такое и насколько безопасно такое монтирование критоустройства? (При том, что LUKS-партиция открывалась родным cryptsetup)
Кстати сказать, когда также руками монтируется криптованный раздел с HDD, hal не может его автосмонтировать, появляется окошко наутилуса где сказано, что смонитровать не удалось (mount ессно монтирует).
2)
В man'е pmount написано, что утилита только для съемных устройств. При этом не хочет даже монтировать флешки из файлов LUKS-девайсов:
В соответствии с требованиями man'а pmount'а, юзер включен в группу plugdev.
комментариев: 9796 документов: 488 редакций: 5664
Попробуйте исключить из fstab и включить в белый список.
Про hal, монтирование с GUI и наутилус может кто-то другой подскажет, могу только посоветовать попробовать всё это отключить и попробовать решить проблему без них — возможно эти лишние для шифрования навороты вносят свои собственные глюки.
Что за муйня и как лечить?!
При монтировании криптораздела получаю такой вывод об ошибках:
То есть опять, помимо устройств в /dev/mapper, еще и устройство /dev/dm-X. Что это за устройство?
комментариев: 9796 документов: 488 редакций: 5664
У вас Intel-процессор без встроенного криптоускорителя.
Купить новый Intel-процессор, если хотите снизить наугрузку на процессор при шифровании скорее всего с 1% (на одно ядро) до 0.001%, если вы не обрабатываете гигабитные потоки шифрованных данных.
Всё нормально открылось без использования криптоускорителя.
Это так называемый прямой путь к устройствам логических томов. В некоторых коммандах (например по удалению томов или изменению их размера) нужно указывать именно этот путь. А в /dev вообще много интересного. Есть пути для устройства по UID и по заводским серийным номерам (для монтирования флэшек удобно)
А где можно по устройствам /dev почитать что-нибудь интересное и достаточно полное?
комментариев: 9796 документов: 488 редакций: 5664
Делает AES более стойким что-ли? ;-))) Ну может против каких-то аппаратных или тайминг-атак, но не заморачивайтесь — шифрование винчестера на ноуте — это не тот случай. Как-то люди десятилетиями обходились без криптоускорителей и ничего. Их внедрили только в самые недавние версии процов.
В исходниках ядра, по-любому ;-)
SatTVA тут помниться не раз высказывался вообще против свопа (учитывая что в настоящее время обычно достаточно RAM).
В связи с этим такой вопрос, если я закриптую своп, смогу ли я безопасно гибернироваться на этот криптованный своп? Или не получиться корректно загрузить систему с образа системы на таком свопе?
комментариев: 9796 документов: 488 редакций: 5664
Если использовать шифрование поверх LVM, то если шифровать персонально логический том swap одноразовым ключём из /dev/urandom, то гибернация невозможна.
Если шифровать физический том, на котором находятся нешифрованные нужные логические тома для системы, включая отдельный раздел swap, то тогда будет работать нормально.
Какой флаг должен указывать на его наличие в /proc/cpuinfo?
У меня там такие:
комментариев: 9796 документов: 488 редакций: 5664
Или если ядро сами компилите — посмотрите в config, можно ли включить сборку этого модуля.
И просто тупое копирование такого файла приводит ли к созданию точной копии содержимого криптоконтейнера (если эту копию файла открывать через cryptsetup) или же нет? Т.е. достаточно для бэкапа просто такой файл скопировать или забэкапить с другими файлами в ФС, или надо обязательно его инициализировать, подмонтировать и делать бэкап уже со смонтированной на его основе ФС?
комментариев: 9796 документов: 488 редакций: 5664
FAQ: Криптоконтейнеры и защита диска: Очень удобно создавать криптоконтейнер в виде файла, ведь это даёт возможность легко делать резервные копии на различных носителях, просто скопировав этот файл. Также его легко отправить на сервер для пересылки или хранения. Почему однако не рекомендуется делать копии контейнеров таким образом?