LINUX.ORG.RU

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


0

1

собрался себе оформить субж, но дли лунукса, похоже нечем переконвертить раздел в шифрованный, не фигача данные на нем при этом... так вот вопрос: почему так?? есть какие-то реальные сложности или всех *crypt*-девелоперов тупо ломает? %)

Ответ на: комментарий от metawishmaster

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

GotF ★★★★★ ()
Ответ на: комментарий от true_admin

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

GotF ★★★★★ ()
Ответ на: комментарий от GotF

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

metawishmaster ★★★★ ()
Ответ на: комментарий от metawishmaster

> какой плюс?

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

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

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

anonymous ()
Ответ на: комментарий от GotF

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

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

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

$ 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.
но, в любом случае, желательнее block-level encryption...

metawishmaster ★★★★ ()
Ответ на: комментарий от GotF

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

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

true_admin ★★★★★ ()
Ответ на: комментарий от metawishmaster

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

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

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

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

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


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

anonymous ()
Ответ на: комментарий от true_admin

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

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

anonymous ()
Ответ на: комментарий от true_admin

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

true_admin ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

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

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

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


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

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


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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

true_admin ★★★★★ ()

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

Готово.

AITap ★★★★★ ()
Ответ на: комментарий от AITap

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

AITap ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

GotF ★★★★★ ()
Ответ на: комментарий от AITap

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

check

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

GotF ★★★★★ ()
Ответ на: комментарий от GotF

Опция в 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.

AITap ★★★★★ ()
Ответ на: комментарий от AITap

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

GotF ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.