В шифрованных разделах LUKS1 в качестве функции формирования ключа (KDF, Key Derivation Function) на основе заданного пользователем пароля применяется функция PBKDF2, не обеспечивающая должную стойкость от подбора с использованием GPU. В LUKS2 в качестве KDF появилась возможность использования гибридной хэш-функции [[https://en.wikipedia.org/wiki/Argon2 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
...
URL: https://mjg59.dreamwidth.org/66429.html
Обсуждается: http://www.opennet.dev/tips/info/3220.shtml
Для справки - GRUB его вроде как не поддерживает пока.
Так во всяком случае тут говорят - https://lwn.net/Articles/929343/
я правильно понимаю - если у меня на компе меньше гига оперативки, то я не смогу расшифровать раздел даже если знаю правильный пароль?
> PBKDF2, не обеспечивающая должную стойкость от подбора с использованиемGPU.
ого ! неужели я смогу расшифровать то, что зашифровал 10 лет назад (и благополучно забыл пассфразу) ?
А не лучше ли использовать встроенную шифрацию диска nvme? Многие модели ее поддерживают.
Проц вообще грузить не будет...
1) потом переставляешь этот несчастный nvme со сдохшей мат платы на живою и опа.
2) vendor lock
Почему? Шифрует ведь диск, а не мать
И у производителя диска лежит любовно спрятанный бэкдор для дешифрации.
если даже так, то кому попало он его не даст, максимум тамошним спецслужбам с наличием ордера, так что нам здесь беспокоится не о чем.
Ох уж эти "тамошние спецслужбы" и "тамошние ордера"...Когда надо будет, любые спецслужбы закроют и посодют. И без всяких ваших шифраций и паролей.
И примеров тому вагоны.А не сидите вы пока не потому, что вы такой умный, а потому что как в том анекдоте про неуловимого Джо. Пока вы на фиг никому не нужны.
Код прошивки накопителя открыт? Нет? Ну, тогда, извини, может там дыры эпических масштабов. Как было у Crucial, где данные были зашифрованы ключом, а ключ лежал ничем не защищенный. Обычно ключ шифруется паролем пользователя, чтобы, не зная пароля, невозможно было расшифровать ключ шифрования и данные. Но парни из Crucial решили сделать по-своему: пользователь вводил пароль, прошивка сравнивала хэш пароля с сохраненным хэшем. При совпадении прошивка брала незашифрованный ключ и им расшифровывала данные.Атакующий мог подцепиться физически, вычитать ключ из флеша и привет.
Наслаждайтесь вашим проприетарным шифрованием.
это было не у Crucial, а у Samsung
Защита от разных моделей угроз. Есть накопители имеющие дефолтное шифрование, что бы ты туда не писал - хранится оно зашифрованным, но для доступа к данным никакой пароль не нужен, вернее его знает контроллер и по умолчанию даёт доступ (может даже не разрешать пользователю установить свой пароль для включения, это не всегда один и тот же что и для шифрования). Команды типа «secure erase» в этом случае просто убивают ключ превращая данные в труху мгновенно. Кстати, это так же используют как ещё один уровень wear leveling.Проблема в том, что реализация хардварного шифрования - вендорский блоб, что и как там индусы накосячили не знает даже бог. В тоже время, это может быть и не быть проблемой, как я и сказал - зависит от модели угроз.
> Защита от разных моделей угрозЕсли ваши угрозы - это кто-то хочет включить ваш компьютер без спроса, то можно диск и не шифровать вообще. Шифрование диска подразумевает, что 1) никто, кроме обладателя ключа, не может прочитать данные на диске (и тут можно пойти по пути шифрования всего диска, только раздела или заюзать ФС с шифрованием, но имхо первые два варианта проще); 2) никто не может поменять содержимое диска так, чтобы это было незамечено (хотя для полной защиты от этого нужно таскать метаданные и бутлоадер на отдельном носителе, но это неудобно в случае с системным диском, поэтому и так сойдёт).
Так же желательно, чтобы данные не были намертво прибиты к носителю, на котором они находятся, а значит хардварное шифрование с ключом, который нужно выковыривать паяльником - это защита от самого себя, а не от того, кто ваш диск *уже* украл. Плюс доверие к любой компании в том, что она будет заботится о вашей приватности, равно нулю: либо так было дешевле, либо защита детей™. Ну и баги никто не отменял. Помните недавный прикол с андроидами (вроде только на пикселях определённой версии, но что-то мне подсказывает дело не в конкретном телефоне), когда чтобы расшифровать накопитель всё что понадобилось - это воткнуть в телефон симку с заранее известным PUK-кодом, ввести его и вуа-ля - телефон каким-то образом без вашего личного секрета всё сам расшифровал (скорее всего что-то похожее как и с Crucial, про который писал Аноним выше, только тут достаточно было чипу, хронящему ключ, сказать "ок" и он побежал расшифровывать раздел, без паролей, без ничего).
Ключ в открытом виде пересылается через интерфейс и его, теоретически, можно физически сдампить
> Перевод шифрованного раздела на LUKS2 и более надёжную функцию формирования ключаЧтобы кому положено могли более надёжно тырить данные: https://www.opennet.dev/opennews/art.shtml?num=56513
какая скорость перебора на одной 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 время расчета будет наверное больше, чем время жизни Вселенной )))
вопрос не стоит на сегодняшний день вообще