Мне любопытно, как работает полное шифрование диска в Ubuntu. Вот пример:
Рассматривая следующую строку как все содержимое диска:
hello world
После применения какого-либо метода шифрования это будет выглядеть примерно так:
(я использовал шифр Цезаря со смещением +1 для этого примера, например, A → B; B → C ...)
ifmmp xpsme
Как я понимаю, когда компьютер выключен, содержимое диска будет строкой выше. Но когда он снова включен, Ubuntu требуется его содержимое, чтобы вернуться снова hello world
, чтобы успешно загрузиться.
Чего я не понимаю, так это того, что в реальном мире содержимое диска намного больше, а алгоритм шифрования - более сложный, и мне трудно для компьютера полностью зашифровать / расшифруйте все это всего за несколько секунд (для загрузки или выключения не требуется больше времени).
Как это возможно?
Эта страница имеет забаву Руководство Рисунка линиями по Усовершенствованному стандарту шифрования (AES), который выглядит легким понять, хотя это надеется быть 50 + изображения, например, эти два:
и
Это слишком много для дублирования всего этого здесь, но если у Вас должно быть единое изображение, это - этот:
Или, существует более компактное объяснение по http://www.password-depot.com/know-how/blowfish_and_rijndael.htm
Метод шифрования Rijndael основан на замене, изменении и выполнении xor операции на байтах. Метод похож на это:
- От 128-разрядного ключа Rijndael генерирует 10 ключей 128 битов каждый.
- Эти ключи помещаются в 4x4 массивы.
- Простой текст также разделен на 4x4 массивы (128 битов каждый).
- Каждый из 128-разрядных объектов простого текста обрабатывается в 10 раундах (10 раундов для 128 разрядных ключей, 12 для 192, 14 для 256).
- После 10-го раунда сгенерирован код.
- Каждым единственным байтом заменяет в поле S и заменяет обратная величина на GF (2 8).
- Затем поразрядные 2 матрицы по модулю применяются, сопровождаются операцией "исключающее ИЛИ" с 63.
- Строки матриц отсортированы циклически.
- Столбцами умножения матриц обмениваются на GF (2 8).
- Подразделы каждого раунда подвергаются операции "исключающее ИЛИ".
Уровень безопасности этого метода шифрования увеличивается, если Rijndael несколько раз выполняется с различными подразделами.
Я полагаю, что это работает путем шифрования раздела с LUKS (настройки по умолчанию с AES) и затем помещает некоторые объемы на него с LVM (как /
, подкачка), и дешифрует и монтирует их при начальной загрузке после ввода пароля. И существует постоянный клиент (не зашифрован) раздел начальной загрузки, который загружается достаточно для просьбы пароль.
в Руководстве the_simple_computer по Полному шифрованию диска с Ubuntu (Обновленный 28 июня 2015) говорится, что это о том, как шифрование установщика по умолчанию работает и упоминает, что двойная загрузка не работала бы (по крайней мере, не out-of-the-box), диск должен использовать MBR так, "если Ваш компьютер будет иметь UEFI, то дистрибутив будет установлен в режиме BIOS прежней версии, таким образом, Вы не сможете использовать Защищенную загрузку", и "также дает Вам размер подкачки, равный той из Вашей системной RAM (часто ненужный), и у Вас нет выбора, какое шифрование используется".
Если Вы работаете cryptsetup benchmark
это запустит тесты и скажет Вам о том, как быстро одно только шифрование берет, наблюдайте за (в настоящее время) строками aes-xts по умолчанию:
# Algorithm | Key | Encryption | Decryption
aes-xts 256b 150.0 MiB/s 145.0 MiB/s
Средний жесткий диск читал, скорость могла составить 80-160 МБ/с, таким образом, Вы не будете намного длиннее, чем регулярное чтение, и возможно, что просто считанные секторы были уже дешифрованы, в то время как Вы все еще ожидать жесткого диска для чтения больше.
SSD мог возможно быть быстрее, возможно, 200-550MB/s, таким образом, Вы могли бы заметить его. Но, случайные чтения могли быть медленнее, и я считал тот SSD, который скорости могут замедлить после использования (возможно, когда диск заполняется полностью и это должно начать "стирать" секторы?)
Это не должно дешифровать все сначала. Шифрование (LUKS) работы над блоками данных, может случайным образом дешифровать любой блок и действия как слой между зашифрованными данными диска и что видит файловая система.
Когда файловая система хочет видеть любой блок данных, LUKS дешифрует тот блок сначала и затем дает дешифрованные данные файловой системе. Вы сначала ожидаете диска считать блок данных (точно так же, как, не используя шифрование) и только иметь дополнительную задержку дешифрования того единственного блока (или немногих блоков) данных - и если дешифрование быстрее, чем диск может читать, дешифрование могло бы быть закончено, прежде чем диск читает следующий блок данных.
Таким образом точно так же, как регулярная файловая система не должна читать целый диск считать файл, когда шифрование добавляется, это не должно читать целый диск также, и это не делает вещи намного медленнее.
Данные по жесткому диску всегда шифруются, таким образом, там не имеет отношения на завершении работы кроме, забывают ключ.
Современные компьютеры могут сделать миллиарды операций в секунду, таким образом, меня не удивляет, что шифрование и дешифрование быстры.
Это - то, как я интуитивно занял бы место, как быстрые компьютеры при выполнении вещей:
другой ключевой бит для понимания - то, что работа не должна дешифровать весь жесткий диск для начальной загрузки системы. Скорее операционная система знает, как дешифровать только части жесткого диска, в котором она нуждается на лету, и то же идет для записи.
Так интуитивно, я не удивлен, что полное шифрование диска не оказывает большую часть влияния на производительность, так как я предполагаю, что узкое место диск.
, Конечно, эти интуиции не всегда соответствуют действительности. Например, в действительности, были случаи, где полное шифрование диска вызвало значимый хит производительности. Но обычно они решены после того, как разработчики проходят несколько раундов разработки оптимизаций.
Процессор использует выделенную систему команд. Это возможно из-за этого, AES-NI . Это включает быстрое шифрование и дешифрование, или можно сказать, что это сокращает издержки. Это быстро, потому что это - аппаратная реализация, как объяснено здесь .
можно проверить о влиянии производительности здесь , и они стоят того для дополнительной защиты.
Это будет определенным упрощением, но я попытаюсь пройти процесс доступа к файлу в зашифрованной файловой системе.
, Например, скажем, начало зашифрованной файловой системы там является таблицей файлов; скажем, мы хотим читать /foo.bar
. Так, первая вещь, которую мы делаем, читается начало раздела, дешифруйте его и просмотрите его для файла, который мы хотим; скажем, это говорит, что файл запускается в 0x10000000 байтах. Таким образом для чтения мы начинаем читать из диска в том местоположении и дешифровать его; точно так же для записи мы можем зашифровать новое содержание и записать им в том новом местоположении.
, Надо надеяться, это помогает разрешить любой беспорядок на процессе.