The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Перевод шифрованного раздела на LUKS2 и более надёжную функцию формирования ключа
В шифрованных разделах LUKS1 в качестве функции формирования ключа (KDF, Key
Derivation Function) на основе заданного пользователем пароля применяется
функция PBKDF2, не обеспечивающая должную стойкость от подбора с использованием
GPU. В LUKS2 в качестве KDF появилась возможность использования гибридной хэш-функции
argon2id, которая помимо потребления
вычислительных ресурсов, затрудняет распараллеливание и требует значительного
объёма памяти.

Например, подбор KDF-функции PBKDF2, рассчитанной на потребление CPU,  может
эффективно распараллеливаться на GPU Geforce 4090 c 16384 вычислительными
блоками, но в случае применения argon2id подбор упирается в размер видеопамяти
(при потреблении 1 ГБ на каждую операцию подбора, на GPU с 24 ГБ памяти можно
обеспечить лишь подбор в 24 параллельных потока).

Переключение с LUKS1 на LUKS2 с  argon2id.

Определяем на каком устройстве находится шифрованный раздел:

   lsblk

   ...
   └─nvme0n1p3    259:3    0 474,8G  0 part  
     └─nvme0n1p3_crypt
                  253:0    0 474,8G  0 crypt 
       ├─vgubuntu--mate-root
       │          253:1    0 473,8G  0 lvm   /var/snap/firefox/common/host-hunspell
       │                                     /
       └─vgubuntu--mate-swap_1
                  253:2    0   980M  0 lvm   [SWAP]

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

   sudo cryptsetup luksHeaderBackup /dev/nvme0n1p3 --header-backup-file /tmp/luksheader


Проверяем версию LUKS:

   sudo cryptsetup luksDump /dev/nvme0n1p3

   ...
   Version:    1
   ...
   PBKDF:      pbkdf2

Если версия 1, то необходимо обновить заголовок до LUKS2.

   sudo cryptsetup convert /dev/nvme0n1p3 --type luks2

Проверяем, что с новым заголовком система по-прежнему грузится и если возникли
проблемы восстанавливаем старый заголовок командой

   sudo cryptsetup luksHeaderRestore /dev/nvme0n1p3 --header-backup-file путь_к_скопированному_luksheader

Ещё раз выполняем cryptsetup luksDump и проверяем алгоритм в секции Keyslots,
если указано "pbkdf2" или "argon2i" следует обновить его до
"argon2id":

   sudo cryptsetup luksConvertKey /dev/nvme0n1p3 --pbkdf argon2id

Проверяем результат:

   sudo cryptsetup luksDump /dev/nvme0n1p3

   ...
   Version:       	2
   ...
   Keyslots:
     0: luks2
        ...
        PBKDF:      argon2id
        ...

    0: luks2
        ...
        PBKDF:      argon2id
        ...
 
18.04.2023 , Источник: https://mjg59.dreamwidth.org/66429....
Ключи: luks, crypt, pbkdf2, argon2, bruteforce, gpu / Лицензия: CC-BY
Раздел:    Корень / Безопасность / Шифрование, PGP

Обсуждение [ Линейный режим | Показать все | RSS ]
  • 1.2, Kuromi (ok), 17:51, 21/04/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Для справки - GRUB его вроде как не поддерживает пока.
    Так во всяком случае тут говорят - https://lwn.net/Articles/929343/
     
  • 1.3, фф (?), 16:37, 24/04/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    я правильно понимаю - если у меня на компе меньше гига оперативки, то я не смогу расшифровать раздел даже если знаю правильный пароль?
     
  • 1.4, ivan_erohin (?), 12:05, 27/04/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > PBKDF2, не обеспечивающая должную стойкость от подбора с использованием

    GPU.

    ого ! неужели я смогу расшифровать то, что зашифровал 10 лет назад (и благополучно забыл пассфразу) ?

     
  • 1.5, Ivan (??), 12:16, 27/04/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А не лучше ли использовать встроенную шифрацию диска nvme? Многие модели ее поддерживают.
    Проц вообще грузить не будет...
     
     
  • 2.6, ivan_erohin (?), 06:03, 28/04/2023 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 2.7, Ivan (??), 10:11, 28/04/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Почему? Шифрует ведь диск, а не мать
     
  • 2.8, Neon (??), 12:53, 04/05/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    И у производителя диска лежит любовно спрятанный бэкдор для дешифрации.
     
     
  • 3.13, Аноним (13), 09:34, 20/05/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    если даже так, то кому попало он его не даст, максимум тамошним спецслужбам с наличием ордера, так что нам здесь беспокоится не о чем.
     
     
  • 4.17, Андрей (??), 08:38, 11/08/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ох уж эти "тамошние спецслужбы" и "тамошние ордера"...

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

    А не сидите вы пока не потому, что вы такой умный, а потому что как в том анекдоте про неуловимого Джо. Пока вы на фиг никому не нужны.

     
  • 2.10, Аноним (10), 21:55, 06/05/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Код прошивки накопителя открыт? Нет? Ну, тогда, извини, может там дыры эпических масштабов. Как было у Crucial, где данные были зашифрованы ключом, а ключ лежал ничем не защищенный. Обычно ключ шифруется паролем пользователя, чтобы, не зная пароля, невозможно было расшифровать ключ шифрования и данные. Но парни из Crucial решили сделать по-своему: пользователь вводил пароль, прошивка сравнивала хэш пароля с сохраненным хэшем. При совпадении прошивка брала незашифрованный ключ и им расшифровывала данные.

    Атакующий мог подцепиться физически, вычитать ключ из флеша и привет.

    Наслаждайтесь вашим проприетарным шифрованием.

     
     
  • 3.15, penetrator (?), 10:32, 20/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    это было не у Crucial, а у Samsung
     
  • 2.11, Qq (?), 18:22, 10/05/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Защита от разных моделей угроз. Есть накопители имеющие дефолтное шифрование, что бы ты туда не писал - хранится оно зашифрованным, но для доступа к данным никакой пароль не нужен, вернее его знает контроллер и по умолчанию даёт доступ (может даже не разрешать пользователю установить свой пароль для включения, это не всегда один и тот же что и для шифрования). Команды типа «secure erase» в этом случае просто убивают ключ превращая данные в труху мгновенно. Кстати, это так же используют как ещё один уровень wear leveling.

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

     
     
  • 3.12, Аноним (12), 15:38, 15/05/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Защита от разных моделей угроз

    Если ваши угрозы - это кто-то хочет включить ваш компьютер без спроса, то можно диск и не шифровать вообще. Шифрование диска подразумевает, что 1) никто, кроме обладателя ключа, не может прочитать данные на диске (и тут можно пойти по пути шифрования всего диска, только раздела или заюзать ФС с шифрованием, но имхо первые два варианта проще); 2) никто не может поменять содержимое диска так, чтобы это было незамечено (хотя для полной защиты от этого нужно таскать метаданные и бутлоадер на отдельном носителе, но это неудобно в случае с системным диском, поэтому и так сойдёт).
    Так же желательно, чтобы данные не были намертво прибиты к носителю, на котором они находятся, а значит хардварное шифрование с ключом, который нужно выковыривать паяльником - это защита от самого себя, а не от того, кто ваш диск *уже* украл. Плюс доверие к любой компании в том, что она будет заботится о вашей приватности, равно нулю: либо так было дешевле, либо защита детей™. Ну и баги никто не отменял. Помните недавный прикол с андроидами (вроде только на пикселях определённой версии, но что-то мне подсказывает дело не в конкретном телефоне), когда чтобы расшифровать накопитель всё что понадобилось - это воткнуть в телефон симку с заранее известным PUK-кодом, ввести его и вуа-ля - телефон каким-то образом без вашего личного секрета всё сам расшифровал (скорее всего что-то похожее как и с Crucial, про который писал Аноним выше, только тут достаточно было чипу, хронящему ключ, сказать "ок" и он побежал расшифровывать раздел, без паролей, без ничего).

     
  • 2.14, px (??), 15:22, 07/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ключ в открытом виде пересылается через интерфейс и его, теоретически, можно физически сдампить
     

  • 1.9, Аноним (9), 14:54, 06/05/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > Перевод шифрованного раздела на LUKS2 и более надёжную функцию формирования ключа

    Чтобы кому положено могли более надёжно тырить данные: https://www.opennet.me/opennews/art.shtml?num=56513

     
  • 1.16, penetrator (?), 10:49, 20/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    какая скорость перебора на одной 4090?

    -------------------------------------------------------------
    * Hash-Mode 10000 (Django (PBKDF2-SHA256)) [Iterations: 9999]
    -------------------------------------------------------------

    Speed.#1.........:   858.5 kH/s (60.66ms) @ Accel:16 Loops:512 Thr:512 Vec:1


    и какая длина ключа используется в LUKS2?

    SHA256, 1774240 итераций

    ты знаешь сколько будет 2 в степени 256?

    даже если ты скупишь все выпущенные 4090 время расчета будет наверное больше, чем время жизни Вселенной )))

    вопрос не стоит на сегодняшний день вообще

     


     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру