Пытаясь понять шифрование LUKS


8

Я решил зашифровать мой корневой раздел с помощью LUKS + LVM.

Моя настройка ThinkPad:

  • Samsung 830 128GB SSD
  • 750 ГБ HDD
  • Core 2 Duo 2,5 ГГц P9500
  • 8 ГБ ОЗУ

Но чем больше я читаю, тем меньше понимаю о двух следующих предметах:

1a. Шифр

Я собирался использовать SHA1 вместо 2/512 (как некоторые предполагают) из-за этой цитаты из cryptsetupFAQ:

5.20 ЛУКС сломан! Он использует SHA-1!

Нет это не так. SHA-1 (академически) сломан для нахождения коллизий, но не для использования его в функции выведения ключей. И эта уязвимость коллизий предназначена только для не повторного использования. И вам нужно хэш-значение дословно.

Это в основном означает, что если у вас уже есть ключ слота, и вы установили счетчик итераций PBKDF2 равным 1 (обычно> 10 000), вы можете (возможно) получить другую фразу-пароль, которая дает вам тот же слот- ключ. Но если у вас есть слот-ключ, вы уже можете разблокировать слот-ключ и получить мастер-ключ, ломая все. По сути, эта уязвимость SHA-1 позволяет открывать контейнер LUKS с большими усилиями, когда он уже открыт.

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

Который я читаю как "нет смысла использовать что-либо, кроме SHA-1". Но потом некоторые люди говорят мне, что это не совсем так. Поэтому я больше не знаю, что и думать.

1б.

Кроме того, я не смог найти никакой информации, влияет ли шифр на производительность чтения / записи / поиска на диске после разблокировки диска и входа в систему.

Так влияет ли сложность шифра только на «производительность» на этапе ввода пароля или также при обычном использовании системы?

2. Алгоритм

Я читаю об этом с нескольких дней, но чем больше я читаю, тем больше путаюсь. Все, что я читаю, говорит, что AES самый быстрый, а Serpent самый медленный. Но не в соответствии с моим ноутбуком:

$ cryptsetup benchmark
Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       344926 iterations per second
PBKDF2-sha256     198593 iterations per second
PBKDF2-sha512     129007 iterations per second
PBKDF2-ripemd160  271933 iterations per second
PBKDF2-whirlpool  134295 iterations per second
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   149.8 MiB/s   147.9 MiB/s
 serpent-cbc   128b    51.0 MiB/s   196.4 MiB/s
 twofish-cbc   128b   127.6 MiB/s   152.5 MiB/s
     aes-cbc   256b   114.3 MiB/s   113.8 MiB/s
 serpent-cbc   256b    51.2 MiB/s   198.9 MiB/s
 twofish-cbc   256b   129.8 MiB/s   167.5 MiB/s
     aes-xts   256b   153.3 MiB/s   150.6 MiB/s
 serpent-xts   256b   176.4 MiB/s   184.1 MiB/s
 twofish-xts   256b   160.8 MiB/s   159.8 MiB/s
     aes-xts   512b   115.4 MiB/s   112.1 MiB/s
 serpent-xts   512b   178.6 MiB/s   184.2 MiB/s
 twofish-xts   512b   160.7 MiB/s   158.9 MiB/s

Получается, что Змей не только самый быстрый, но и самый быстрый с самым сложным ключом.

Не должно ли быть наоборот? Я читаю это неправильно, или что-то?


Так почему бы не использовать SHA512 для большей безопасности, если он все равно хэширует до 1 секунды в реальном времени.
user284148

Ответы:


5

1а - это действительно не имеет большого значения. какой хеш вы используете для функции вывода ключей, LUKS гарантирует, что это будет дорого в вычислительном отношении. Он будет просто зацикливаться, пока не пройдет 1 секунда реального времени.

1б - метод получения ключа не влияет на производительность. сам шифр делает. cryptsetup benchmarkпоказывает вам столько же.

2 - AES является самым быстрым, если ваш процессор достаточно современный, чтобы поддерживать инструкции AES-NI (аппаратное ускорение для AES). Если вы идете со змеем сейчас, вы не сможете использовать AES-NI вашего следующего ноутбука.

# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1      1165084 iterations per second
PBKDF2-sha256     781353 iterations per second
PBKDF2-sha512     588426 iterations per second
PBKDF2-ripemd160  726160 iterations per second
PBKDF2-whirlpool  261882 iterations per second
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   692.9 MiB/s  3091.3 MiB/s
 serpent-cbc   128b    94.6 MiB/s   308.6 MiB/s
 twofish-cbc   128b   195.2 MiB/s   378.7 MiB/s
     aes-cbc   256b   519.5 MiB/s  2374.0 MiB/s
 serpent-cbc   256b    96.5 MiB/s   311.3 MiB/s
 twofish-cbc   256b   197.9 MiB/s   378.0 MiB/s
     aes-xts   256b  2630.6 MiB/s  2714.8 MiB/s
 serpent-xts   256b   310.4 MiB/s   303.8 MiB/s
 twofish-xts   256b   367.4 MiB/s   376.6 MiB/s
     aes-xts   512b  2048.6 MiB/s  2076.1 MiB/s
 serpent-xts   512b   317.0 MiB/s   304.2 MiB/s
 twofish-xts   512b   368.7 MiB/s   377.0 MiB/s

Имейте в виду, что этот тест не использует хранилище, поэтому вы должны проверить эти результаты с любым хранилищем и файловой системой, которые вы собираетесь использовать.


1
1. Спасибо за разъяснения. Так что я могу пойти дальше и использовать SHA512 без какого-либо негативного влияния на производительность диска. 2. Мне кажется странным, что, согласно веб-сайту Intel ( ark.intel.com/search/advanced/?s=t&AESTech=true ), старые Pentiums имели такую ​​оптимизацию, а C2D - нет. «Если ты пойдешь со змеем сейчас, ты не сможешь использовать AES-NI своего следующего ноутбука». Под этим я понимаю, что вы имели в виду, что мне придется перезаписать диск в AES. Правильно? Тест говорит мне о производительности процессора. Мой SSD работает на SataII 3.0 Гбит / с (200–280 МБ / с), поэтому я полагаю, что ничего лучше не получится, чем у serpent-xts 512b
lockheed
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.