"PGP Disk под Linux" / системы шифрования

Команда cat /proc/crypto в моей системе дает следующий вывод:

name : stdrng driver : krng module : kernel priority : 200 refcnt : 1 selftest : passed type : rng seedsize : 0 name : md5 driver : md5-generic module : kernel priority : 0 refcnt : 1 selftest : passed type : digest blocksize : 64 digestsize : 16

система Ubuntu 9.04 (jaunty)

В папке /usr/scr/ лежат следующие папки:
linux-headers-2.6.28-11 размером 33,7 Мб
linux-headers-2.6.28-11-generic размером 1,7 Мб

Команда uname -r дает вывод:
2.6.28-11-generic

Насколько я понимаю в моем ядре то же включена поддержка только хешей и от ключена поддержка шифров? Могу ли я использовать какой-либо способ шифрования средствами файловой системы без перекомпиляции ядра?

Поддержка скорее всего включена, просто модули незагружены, т.к. не используются:

ls /lib/modules/2.6.XX-XXX/kernel/crypto/ ls -l /lib/modules/2.6.XX-XXX/kernel/drivers/md/dm-crypt.ko

Установите пакеты, связанные с dm-crypt и LUKS и всё практически само настроится.

Добрый день.
У меня вопрос по алгоритмам шифрования cryptsetup/LUKS.
По умолчанию LUKS шифрует aes-cbc-essiv:sha256, и рекомендует именно такую связку.
Достаточно ли надежен такой вариант?
Возможен ли вариант twofish-xts-essiv:sha256 или twofish-xts-essiv:sha512?
Предпочтительнее ли режим шифрования XTS перед CBC для шифрования всего диска?
Какие Best practices и рекомендации в этой области?

peergynt, то, что Вам нужно, называется twofish-xts-benbi. XTS и ESSIV — два различных режима. Использование голого CBC для дискового шифрования опасно; подробности — в /faq/защитадиска. XTS более предпочтителен перед другими режимами, как с точки зрения теоретической базы, так и скорости и универсальности.

Спасибо.
Внятных описаний допустимых комбинаций алгоритмов и режимов шифрования я не нашел, кроме разве что вот этого:
http://hightechsorcery.com/200.....24-and-later-kernels
Встречал варианты с экзотическими длинами ключей "-s 384", "-s 512":
http://www.linuxposts.com/linu.....thod-best-speed.html
, это лажа?

Нет, это значит, что используется 256-битовый ключ и 128- или 256-битовый твик.

Для начала я попытался зашифровать swap-раздел.

Содержимое файла /etc/crypttab:
cryptoswap /host/ubuntu/disks/swap.disk /dev/random swap,cipher=twofish-xts-benbi,size=512,hash=sha512

При загрузке в лог /var/log/dmesg пишет:
alg: No test for xts(twofish) (xts(twofish-generic))

Если вместо twofish взять aes:
cryptoswap /host/ubuntu/disks/swap.disk /dev/random swap,cipher=aes-xts-benbi,size=512,hash=sha512

, то в логе:
padlock: VIA PadLock not detected.

swap-раздел подключается нормально.
Насколько критичны эти сообщения?

ОС Ubuntu 9.04, поставленная через wubi поверх винды.

Первое, если не ошибаюсь, означает, что в ядре нет тестового набора для проверки корректности алгоритма. Для работы это некритично... если модуль алгоритма реализован корректно (а это так, если Canonical там ничего не допиливала).

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

Кстати, использовать в качестве источника ключевого материала /dev/random не обязательно, подойдёт и /dev/urandom, к тому же он не будет расходовать ценную чистую энтропию, собранную системой.

Кстати-2, помимо свопа желательно шифровать эфемерным ключом и раздел /tmp, там тоже за время работы скапливается немало интересного мусора.

...и при этом не пользоваться такой модной, но небезопасной штукой, как гибернация системы.

Итак, я зашифровал swap и поместил /tmp и /var/tmp в tmpfs.
Теперь задача максимум – шифрование корневого раздела.
Напомню, что я использую wubi-инсталляцию Ubuntu 9.04, т.е. корневой раздел лежит в файле C:\ubuntu\disks\root.disk на ntfs-разделе под виндой.
После загрузки виндовый раздел монтируется в каталог /host, т.е. корневой раздел виден как /host/ubuntu/disks/root.disk

Я использовал следующие источники:
http://blog.uptimebox.ru/2007/05/debian-gnulinux-4.html
http://wiki.eeeuser.com/ru:get.....ие_корневого_раздела
http://www.c3l.de/linux/howto-.....u-6.10-edgy-eft.html

Вопрос: что писать в /etc/crypttab, чтобы после сборки update-initramfs initramfs увидел файл /host/ubuntu/disks/root.disk как loopback-устройство на этапе загрузки?

Я пробовал писать

# <target name> <source device> <key file> <options> cryptoroot /host/ubuntu/disks/root.disk none luks

, а также

# <target name> <source device> <key file> <options> cryptoroot /ubuntu/disks/root.disk none luks

, но при загрузке пишет, что устройство не найдено.

Для незашифрованной системы синтаксис grub в menu.lst такой:

title Ubuntu 9.04, kernel 2.6.28-13-generic (unencrypted) root ()/ubuntu/disks kernel /boot/vmlinuz-2.6.28-13-generic root=UUID=7278D9A678D968FD loop=/ubuntu/disks/root.disk ro vga=795 initrd /boot/initrd.img-2.6.28-13-generic.cryptoback

Возможны ли в принципе такие выкрутасы?
Я понимаю, что достаточно зашифровать только раздел /home, и я скорее всего так и сделаю, просто интересна принципиальная возможность.

Я в своё время кое-что писал о шифровании корневого раздела действующей системы, но это инструкция для менее мутировавших систем, чем wubi. В принципе, в initrd реализовать можно любой функционал. Ваша ситуация отличается от чаще рассматриваемых лишь тем, что до того как подмонтировать зашифрованный корневой раздел, Вам необходимо монтировать виндовой ntfs-раздел, где лежит образ.

Посмотрите это монстроподобное руководство. Там есть инструкции для создания достаточно универсального образа initramfs именно для системы с зашифрованным корнем. Возможно, с некоторыми адаптациями найдёте её для себя полезной.

2 вопроса.


1. В системе Ubuntu 9.10, при установке, предусмотрен режим шифрования домашней папки. Данный режим устанавливается на стадии установки системы, включением опции шифрования паролем входа в систему.
Однако при дальнейшем создании дополнительных пользователей, в уже установленной системе, их домашние папки оказываются не защищенными. В меню создания пользователей опции шифрования просто нет. Есть ли способ решить данную проблему – сделать домашние папки других пользователей зашифрованными таким же образом?

2. Для Ubuntu есть пакет ecryptfs-utils, создающий шифрованную папку Private в домашнем каталоге. Но не могу понять, можно ли сделать управление шифровкой/расшифрокой этого каталога независимо от пароля пользователя. Пока добился только работы автоматической расшифровки при входе в систему и соответственно зашифровки при выходе. А вот как сделать независимо, по моей отдельной команде?

1. Разве шифруется только /home/user, а не весь /home? Смею предположить, что всё-таки второе.

В том и дело, что /home/user. Это проверено. Для проверки была создана отдельная учетная запись (пусть она будет /home/user2). После при загрузке компьютера с live дистрибутива /home/user2 созданного пользователя была доступна для просмотра, домашняя папка первого пользователя /home/user была не доступна.
С другой же стороны другие пользователи имеют свои уникальные пароли на вход в свои учетные записи, поэтому если бы шифровался весь /home с помощью пароля первой учетной записи, то другие пользователи просто не могли бы пользоваться машиной.
Вот такое наблюдение. Как быть, что нужно сделать, что бы паролем вторичного пользователя можно было шифровать свою /home/user2?

Как быть, что нужно сделать, что бы паролем вторичного пользователя можно было шифровать свою /home/user2?

Как сделать это кошерно с точки зрения дистрибутива, Вам только другие пользователи Ubuntu подскажут. Я бы покопался в стартовых скриптах и поспрашивал гугл.

Как более универсальное решение, можно сделать файл-контейнер (или LVM slice, если он используется для управления разделами) под /home/user2, а в самой /home/user2 создать .bashrc, который будет монтировать зашифрованный контейнер/раздел в этот каталог при каждом логине пользователя.