Я могу использовать сценарий для хеширования для LUKS?

Конфигурация не должна быть слишком сложной. Я изменился root= туда, где корень в конечном счете прибудет из (Ваш зашифрованный диск). Так как начальная загрузка находится на отдельном разделе, часть проблемы здесь.

Так позволяет помещенным вещам вместе с тем, как они должны закончить. Во-первых, реальный корень будет смонтирован как /dev/sda2 после того как можно дешифровать его. /dev/sda2/boot будет пустой каталог, где Вы смонтировали бы свой раздел начальной загрузки, /dev/sda1.

С тех пор /dev/sda1 будет Вашим разделом начальной загрузки, он не должен иметь самого каталога начальной загрузки, иначе после того как он смонтирован, Вы будете иметь /boot/boot/[grub/, 3.8.13, initrd.img, etc].

Таблица монтирования выглядела бы примерно так:

  • /dev/sda2 /
  • /dev/sda1 /boot

Переместите свое ядро в /dev/sda1/3.8.13, переместите свой initrd.img в /dev/sda1/initrd.img, переместите свой каталог личинки в /dev/sda1/grub.

Затем, мы хотим установить личинку на mbr /dev/sda, и никогда раздел /dev/sda1, таким образом, наша установка посмотрела бы что-то как grub-install /dev/sda. Мы должны сказать это, где найти, что файлы конфигурации для записи в личинку конфигурируют таблицы, который является где --boot-directory должен войти.

Позволяет предполагают что, в то время как Вы находитесь в своем живом CD, чиня эту вещь, что Вы имеете /dev/sda1 смонтированный как /boot, и Ваши конфигурации личинки находятся в /boot/grub. Установка была бы grub-install --boot-directory=/boot /dev/sda.

Если Вы имели /dev/sda1 смонтированный как /mnt/fixboot в то время как в livecd, затем конфигурация не изменилась бы, и команда установки изменится на grub-install --boot-directory=/mnt/fixboot.

Конфигурация:

default 0
timeout 5

root (hd0,0)
kernel /3.8.13 root=/dev/sda2
initrd /initrd.img

Конфигурация может измениться, после того как Вы выясняете, как на самом деле дешифровать /dev/sda2; это, вероятно, закончит тем, что имело необходимость быть a /dev/mapper устройство.

4
26.07.2014, 00:13
4 ответа

Нет, LUKS поддерживает только PBKDF2 в качестве функции получения ключа. PBKDF2 построен на основе криптографической хеш-функции, и вы можете выбрать хеш-функцию с помощью - hash , а также счетчик итераций с помощью - iter-time . Все поддерживаемые хэш-функции одинаково безопасны для этого варианта использования; большее количество итераций пропорционально усложняет задачу злоумышленнику, но также соответственно замедляет нормальный монтаж.

Зарегистрирована проблема для LUKS с поддержкой scrypt. Это существенное изменение, потому что в формате на диске нет поля, указывающего, какое растяжение ключа используется. Это кратко обсуждалось в списке рассылки dm-crypt.

4
27.01.2020, 20:49

Можно использовать любой алгоритм хэширования, имеющийся в наличии в ядре, поэтому ответ в принципе да (если кто-то захочет реализовать его в ядре), но на практике нет

.
1
27.01.2020, 20:49

Взлом хэшей Scrypt примерно на 18,000X дороже, чем взлом хэшей LUKS при выполнении в течение 200 мс, когда злоумышленник использует пользовательские ASIC. Чтобы получить такую же защиту, просто увеличивая итерации, вы должны позволить LUKS хэш ваш пароль в течение часа. Развлекайтесь с этим: -)

LUKS должен переключиться на Scrypt по умолчанию, простой и простой. Не позволяйте приведенным выше комментариям сбить вас с толку.

4
27.01.2020, 20:49

Краткий ответ - да, для шифрования LUKS можно использовать скрипт (см. Википедию) из Tarsnap . Кроме того, scrypt был реализован в Android 4.4+. Ссылка Revisiting-android-disk-encryption . Однако это не дает ответа на более важный вопрос: как? Здесь очень ценится руководство по LUKS с scrypt на Linux Mint или Fedora.

0
27.01.2020, 20:49

Теги

Похожие вопросы