Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Раздел полезных советов: Перевод шифрованного раздела на LUKS2 и более надёжную функцию формирования ключа"	+/–
Сообщение от auto_tips (??), 19-Апр-23, 06:23
В шифрованных разделах 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.me/tips/info/3220.shtml
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

2. Сообщение от Kuromi (ok), 21-Апр-23, 17:51	+2 +/–
Для справки - GRUB его вроде как не поддерживает пока. Так во всяком случае тут говорят - https://lwn.net/Articles/929343/
Ответить | Правка | Наверх | Cообщить модератору

3. Сообщение от фф (?), 24-Апр-23, 16:37	+3 +/–
я правильно понимаю - если у меня на компе меньше гига оперативки, то я не смогу расшифровать раздел даже если знаю правильный пароль?
Ответить | Правка | Наверх | Cообщить модератору

4. Сообщение от ivan_erohin (?), 27-Апр-23, 12:05	+1 +/–
> PBKDF2, не обеспечивающая должную стойкость от подбора с использованием GPU. ого ! неужели я смогу расшифровать то, что зашифровал 10 лет назад (и благополучно забыл пассфразу) ?
Ответить | Правка | Наверх | Cообщить модератору

5. Сообщение от Ivan (??), 27-Апр-23, 12:16	–1 +/–
А не лучше ли использовать встроенную шифрацию диска nvme? Многие модели ее поддерживают. Проц вообще грузить не будет...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6, #7, #8, #10, #11, #14

6. Сообщение от ivan_erohin (?), 28-Апр-23, 06:03	+/–
1) потом переставляешь этот несчастный nvme со сдохшей мат платы на живою и опа. 2) vendor lock
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

7. Сообщение от Ivan (??), 28-Апр-23, 10:11	+/–
Почему? Шифрует ведь диск, а не мать
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

8. Сообщение от Neon (??), 04-Май-23, 12:53	+2 +/–
И у производителя диска лежит любовно спрятанный бэкдор для дешифрации.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #13

9. Сообщение от Аноним (9), 06-Май-23, 14:54	+1 +/–
> Перевод шифрованного раздела на LUKS2 и более надёжную функцию формирования ключа Чтобы кому положено могли более надёжно тырить данные: https://www.opennet.me/opennews/art.shtml?num=56513
Ответить | Правка | Наверх | Cообщить модератору

10. Сообщение от Аноним (10), 06-Май-23, 21:55	+1 +/–
Код прошивки накопителя открыт? Нет? Ну, тогда, извини, может там дыры эпических масштабов. Как было у Crucial, где данные были зашифрованы ключом, а ключ лежал ничем не защищенный. Обычно ключ шифруется паролем пользователя, чтобы, не зная пароля, невозможно было расшифровать ключ шифрования и данные. Но парни из Crucial решили сделать по-своему: пользователь вводил пароль, прошивка сравнивала хэш пароля с сохраненным хэшем. При совпадении прошивка брала незашифрованный ключ и им расшифровывала данные. Атакующий мог подцепиться физически, вычитать ключ из флеша и привет. Наслаждайтесь вашим проприетарным шифрованием.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #15

11. Сообщение от Qq (?), 10-Май-23, 18:22	+/–
Защита от разных моделей угроз. Есть накопители имеющие дефолтное шифрование, что бы ты туда не писал - хранится оно зашифрованным, но для доступа к данным никакой пароль не нужен, вернее его знает контроллер и по умолчанию даёт доступ (может даже не разрешать пользователю установить свой пароль для включения, это не всегда один и тот же что и для шифрования). Команды типа «secure erase» в этом случае просто убивают ключ превращая данные в труху мгновенно. Кстати, это так же используют как ещё один уровень wear leveling. Проблема в том, что реализация хардварного шифрования - вендорский блоб, что и как там индусы накосячили не знает даже бог. В тоже время, это может быть и не быть проблемой, как я и сказал - зависит от модели угроз.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #12

12. Сообщение от Аноним (12), 15-Май-23, 15:38	–1 +/–
> Защита от разных моделей угроз Если ваши угрозы - это кто-то хочет включить ваш компьютер без спроса, то можно диск и не шифровать вообще. Шифрование диска подразумевает, что 1) никто, кроме обладателя ключа, не может прочитать данные на диске (и тут можно пойти по пути шифрования всего диска, только раздела или заюзать ФС с шифрованием, но имхо первые два варианта проще); 2) никто не может поменять содержимое диска так, чтобы это было незамечено (хотя для полной защиты от этого нужно таскать метаданные и бутлоадер на отдельном носителе, но это неудобно в случае с системным диском, поэтому и так сойдёт). Так же желательно, чтобы данные не были намертво прибиты к носителю, на котором они находятся, а значит хардварное шифрование с ключом, который нужно выковыривать паяльником - это защита от самого себя, а не от того, кто ваш диск *уже* украл. Плюс доверие к любой компании в том, что она будет заботится о вашей приватности, равно нулю: либо так было дешевле, либо защита детей™. Ну и баги никто не отменял. Помните недавный прикол с андроидами (вроде только на пикселях определённой версии, но что-то мне подсказывает дело не в конкретном телефоне), когда чтобы расшифровать накопитель всё что понадобилось - это воткнуть в телефон симку с заранее известным PUK-кодом, ввести его и вуа-ля - телефон каким-то образом без вашего личного секрета всё сам расшифровал (скорее всего что-то похожее как и с Crucial, про который писал Аноним выше, только тут достаточно было чипу, хронящему ключ, сказать "ок" и он побежал расшифровывать раздел, без паролей, без ничего).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

13. Сообщение от Аноним (13), 20-Май-23, 09:34	+2 +/–
если даже так, то кому попало он его не даст, максимум тамошним спецслужбам с наличием ордера, так что нам здесь беспокоится не о чем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #17

14. Сообщение от px (??), 07-Июн-23, 15:22	+/–
Ключ в открытом виде пересылается через интерфейс и его, теоретически, можно физически сдампить
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

15. Сообщение от penetrator (?), 20-Июн-23, 10:32	+/–
это было не у Crucial, а у Samsung
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

16. Сообщение от penetrator (?), 20-Июн-23, 10:49	+/–
какая скорость перебора на одной 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 время расчета будет наверное больше, чем время жизни Вселенной ))) вопрос не стоит на сегодняшний день вообще
Ответить | Правка | Наверх | Cообщить модератору

17. Сообщение от Андрей (??), 11-Авг-23, 08:38	+1 +/–
Ох уж эти "тамошние спецслужбы" и "тамошние ордера"... Когда надо будет, любые спецслужбы закроют и посодют. И без всяких ваших шифраций и паролей. И примеров тому вагоны. А не сидите вы пока не потому, что вы такой умный, а потому что как в том анекдоте про неуловимого Джо. Пока вы на фиг никому не нужны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема