Определяется ли самое быстрое открытие по предыдущим ключевым слотам?

После установки устройств LUKS (v1) с openSUSE LEap 15.2 выяснилось, что счетчик итераций был установлен настолько большим, что для успешного дешифрования главного ключа требуется более 10 секунд (для этого существуют отчеты об ошибках).

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

Однако мне интересно: AFAIK после ввода парольной фразы luksOpen попытается расшифровать ключевые слоты последовательно, а не параллельно, что означает, что первый ключевой слот определяет минимальное время ожидания до успешного завершения дешифрования. Это верно?

Примечание. При загрузке я не могу указать параметры для выбора определенного слота для ключа. Так что наиболее вероятным решением будет замена ключевых слотов, не так ли?

1 ответ
1

Испытательная установка

  1. Создайте файл на ramdisk для хранения контейнера LUKS:

    $ cd /dev/shm
    $ truncate -s 1G luksfile
    
  2. Подготовьте ключевые файлы одинакового размера для тестирования:

    $ dd if=/dev/urandom of=key1 bs=1M count=1
    1+0 records in
    1+0 records out
    1048576 bytes (1,0 MB, 1,0 MiB) copied, 0,00897814 s, 117 MB/s
    $ dd if=/dev/urandom of=key2 bs=1M count=1
    1+0 records in
    1+0 records out
    1048576 bytes (1,0 MB, 1,0 MiB) copied, 0,00792946 s, 132 MB/s
    
  3. Отформатируйте файл:

    $ cryptsetup luksFormat --key-file key1 luksfile
    
    WARNING!
    ========
    This will overwrite data on luksfile irrevocably.
    
    Are you sure? (Type uppercase yes): YES
    
  4. Добавьте второй ключ:

    $ cryptsetup luksAddKey --key-file key1 luksfile key2
    

Тест

for x in 1 2 3 4 5; do  
time sudo cryptsetup open --key-file key1 luksfile test
sudo cryptsetup close test
done

Я отбрасываю результаты первых 5 прогонов для каждого ключа, чтобы устранить расхождения в кешировании.

Результаты для key1:

2,30s user 0,02s system 97% cpu 2,369 total
2,39s user 0,01s system 97% cpu 2,454 total
2,41s user 0,02s system 97% cpu 2,509 total
2,25s user 0,02s system 97% cpu 2,336 total
2,21s user 0,02s system 97% cpu 2,291 total

Результаты для key2:

4,08s user 0,02s system 98% cpu 4,146 total
4,20s user 0,02s system 98% cpu 4,267 total
4,19s user 0,01s system 98% cpu 4,255 total
4,15s user 0,01s system 98% cpu 4,209 total
4,43s user 0,02s system 98% cpu 4,520 total

Да, ключи проверяются по очереди. На 2-ю клавишу влияет медлительность 1-й клавиши.

Решение

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

На самом деле можно. Использовать keyslot вариант в /etc/crypttab, 4-й столбец. Видеть man crypttab.

  • Последний вопрос по поводу «Используйте параметр слота ключей в / etc / crypttab»: есть ли запасной вариант? То есть: если я укажу ключевой слот 1 и через некоторое время очищу этот слот, смогу ли я тогда загрузиться?

    — У. Виндл
    8 часов назад

  • 1

    @ U.Windl Вы действительно недооцениваете полезность мануала;) man crypttab направит вас к cryptsetup -S а также man cryptsetup говорит «Если данная кодовая фраза будет соответствовать только другому ключевому слоту, операция завершится ошибкой».

    — горностай
    8 часов назад

  • Так что использование этой опции опасно, и этот слот не предпочтительный один, но обязательный один. Это («Если данная кодовая фраза будет соответствовать только другому ключевому слоту, операция завершится ошибкой.») Может считаться даже ошибкой.

    — У. Виндл
    7 часов назад

  • Может также увидеть gitlab.com/cryptsetup/cryptsetup/-/issues/643

    — У. Виндл
    7 часов назад

  • @ U.Windl Что ж, выполнение подобных административных задач по своей сути опасно. Так что просто дважды проверьте все, составьте план восстановления и убедитесь, что ваши резервные копии работают.

    — горностай
    7 часов назад

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *