шифрование раздела

Можно: http://wiki.debian.org/ru/Crypt

Но я бы рекомендовал использовать LUKS, хоть и придётся создавать раздел заново.

спасибо! :))

> Но я бы рекомендовал использовать LUKS, хоть и придётся создавать раздел заново.

а почему?.. какой плюс?

посмотри на ecryptfs

1) Стандарт. 2) Умеет несколько паролей.

У неё есть неисправленные баги (с ext4, например), а ещё она не всегда хорошо работает с XFS (переполнение стека). Если уж на уровне ФС, то EncFS, хоть она и на FUSE со всеми вытекающими.

> посмотри на ecryptfs она backup делает... а не куда, разве что в /dev/null %)

да не... там fat32+ext2, к тому же не нужны несколько паролей - простой cryptsetup вполне подходит :)
про завязывание с FUSE совсем молчу, не хочется %)

в смысле?

У неё есть неисправленные баги

можно ссылочку на проблемы с ext4?

https://bugs.launchpad.net/ecryptfs/+bug/509180

С прошлого раза тред пополнился, возможно, это не только на ext4.

> какой плюс?

Абсолютно никакого. Лишний мусор в начале диска.

http://www.linux.org.ru/jump-message.jsp?msgid=6127442&cid=6129882

Можно воспользоваться LiveUSB дистром и внешним накопителем хоть какого-то размера, чтобы перекодировать блоками. Оригинальный блок копируется на временный носитель, затем обратно уже в зашифрованном виде. Для автоматизации можно написать скрипт. Потом останется только отредачить конфиги и initramfs.

ммм, понятно. У меня полёт был нормальный пол года пока вчера комп не повис. После этого такая фигня стала происходить.

слегка проглючило: ворнинг в

$ ecryptfs-migrate-home --help

Usage:

/usr/bin/ecryptfs-migrate-home -u USER

-u,--user Migrate USER's home directory to an encrypted home directory

WARNING: Make a complete backup copy of the non-encrypted data to
another system or external media. This script is dangerous and, in
case of an error, could result in data lost, or lock you out of your
system!

This program must be executed by root.

Удалил один повреждённый файл, посмотрим что будет.

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

Если ты используешь шифрование то у тебя полюбому или ненужные данные или есть бэкапы и UPS. Можешь посмотреть что будет если свет моргнёт во время записи на раздел :)

> Впрочем, из своего опыта скажу что, например, dm_crypt разносил фс в щепки если вырубить комп во время записи на диск(вплоть до невозможности монтирования, если не путаю).

Используйте правильные режимы шифрования.

http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation

есть UPS и батарейки %)

anonymous> ...

тоже спасибо за ценные информацию/указания =)

Используйте правильные режимы шифрования.

По ссылке простыня текста. Что конкретно надо поменять в настройках ядра?

Ты уверен что ты правильно понимаешь проблему? Она в документации чётко сформулирована, если контрольная сумма не сходится то инвалидируется блок в 4кб. Этого достаточно чтобы разнести раздел если этот блок приходился на мета-данные фс.

> По ссылке простыня текста.

Я перечитывал. Брат жив.

Что конкретно надо поменять в настройках ядра?

s/aes-cbc-essiv:sha256/aes-ctr-plain/ Это например. Настоящий параноик думает в первую очередь своим параноидным мозгом.

> Она в документации чётко сформулирована, если контрольная сумма не сходится то инвалидируется блок в 4кб.

Это уже половые проблемы файловой системы. Используйте надёжный драйвер, ИБП и RAID с большим номером.

> Что конкретно надо поменять в настройках ядра?

# cd исходники/ведра
# make menuconfig
Cryptographic API ---> нужные модули здесь.

Прочитал, информация интересная. Но у меня есть сомнения добавит ли это надёжности. Это должно добавить скорости? А на скорость я не жалуюсь.

Что касается их криптостойкости то, с моей точки зрения, cbc даже предпочтительнее.

Спасибо, у меня debian и все модули уже собраны

Используйте надёжный драйвер, ИБП и RAID с большим номером.

рейд тут не поможет абсолютно. Про ups я сам выше писал.

> Но у меня есть сомнения добавит ли это надёжности.

В режимах типа Counter биты просто ксорятся, поэтому повреждения не усугубляются шифрованием. Где бит флипнулся не зашифрованный, там же и зашифрованный.

Это должно добавить скорости?

Теоретически - да, в частности, с тем же CTR, поскольку параллелится. Как это на практике реализовано - не исследовал, не знаю.

Что касается их криптостойкости то, с моей точки зрения, cbc даже предпочтительнее.

Это замечательная точка зрения, но поддержка её была бы не искренней с моей стороны. :)

повреждения не усугубляются шифрованием.

Ммм, хочешь сказать что если повредить блок посередине то все остальные не прочитаются? По-моему, это не так. Хотя, вполне возможно что для успешного чтения следующего блока предыдущий должен читаться.

Т.е. в теории у ctr повреждения слегка меньше должны быть. Но всё это не более чем догадки, надо проверять. Поэтому у меня стоит ламерский cbc-essiv:sha256 и я не парюсь.

> похоже нечем переконвертить раздел в шифрованный
1) umount /dev/sdXY
2) cryptsetup ...
3) cat /dev/sdXY > /dev/mapper/ZZZ
4) Поправить /etc/crypttab
5) Поправить /etc/fstab

Готово.

Я бы не стал так делать. На собственной шкуре испытал: ведро при создании /dev/mapper/ZZZ думало, что /dev/sdXY - это как раз /dev/mapper/ZZZ. К счастью, всего лишь испытывал методы быстрого перезапрятывания, важных данных там не было.

Сейчас, возможно, уже исправили, поэтому стоит проверить. Всегда надо в первую очередь проводить эксперименты перед реальной работой с ценной информацией.

> едро при создании /dev/mapper/ZZZ думало, что /dev/sdXY - это как раз /dev/mapper/ZZZ
Ого.

Впрочем, я от этого тоже в своё время отказался в пользу LUKS, не осилив check. Расшифровать данные, правда, мне удалось вполне успешно, именно при помощи cat /dev/mapper/ZZZ > /dev/sdXY.

>> ведро при создании /dev/mapper/ZZZ думало, что /dev/sdXY - это как раз /dev/mapper/ZZZ

Крайне странное поведение. Такого в принципе не должно быть. Проверил сейчас — всё нормально.

>> Впрочем, я от этого тоже в своё время отказался в пользу LUKS, не осилив check.

check

Не совсем понял, это о чём речь?

Опция в crypttab, позволяющая проверить, в т.ч., правильность ввода пароля. Меня несколько раздражало, что когда я при загрузке вводил неправильный пароль, всё принималось, как должное, а на этапе монтирования начинались ошибки.

check=<check>
Check the content of the target device by a suitable program; if the check fails, the device is removed. If a program is provided as an argument, it is run, giving
the decrypted volume (target device) as first argument, and the value of the checkargs option as second argument. Cryptdisks/cryptroot searches for the given
program in /lib/cryptsetup/checks/ first, but full path to program is supported as well.

Ну так в /lib/cryptsetup/checks/ как раз лежат скрипты для проверки «правильности». Из коробки там проверка типа ФС. Вроде бы рекомендуется использовать скрипт blkid как аргумент check.