Я не могу открыть один из разделов LUKS на Raspberry PI из-за ограничения памяти. Я уже выяснил, что предложение в этом случае заключается в следующем:пересоздайте раздел на самом медленном устройстве, которое будет иметь к нему доступ(в данном случае Raspberry PI).
Однако меня беспокоит возможное снижение уровня безопасности (вероятно, при меньшей вычислительной мощности будет использоваться более слабый ключ).
Вот что говорится в документации cryptsetup по поводу этой проблемы:
Примечание: итерация парольной фразы определяется cryptsetup в зависимости от мощности ЦП. На медленном устройстве это может быть ниже, чем вам нужно. Недавно я провел сравнительный анализ на Raspberry Pi, и он составил около 1/15 от количества итераций для типичного ПК. Если безопасность имеет первостепенное значение, вы можете увеличить время, затрачиваемое на итерацию, ценой более медленной разблокировки в дальнейшем. Для Raspberry Pi, используя
cryptsetup luksFormat -i 15000 <target device>дает вам количество итераций и уровень безопасности, равный среднему ПК для итерации парольной фразы и итерации мастер-ключа. Если вы сомневаетесь, проверьте количество итераций с помощью
cryptsetup luksDump <target device>и соответствующим образом скорректируйте количество итераций, заново создав контейнер с другим временем итерации (число после «-i» — это время итерации в миллисекундах), пока ваши требования не будут выполнены.
Теперь я не уверен, что произойдет, если я последую совету выше?
- Будет ли раздел таким же безопасным, как на ПК?(если количество итераций верно), просто медленнее?
- Если он медленнее, то медленнее только разблокировка или последующие чтения/записи такие же быстрые, как и без дополнительной итерации? (Если да, то почему? Потому что при разблокировке мы расшифровываем только ключ, который позже будет использоваться для расшифровки содержимого раздела?)
- Будет ли он по-прежнему потреблять меньше памяти, чем раздел, созданный на быстром ПК? (Другими словами: я хочу пересоздать раздел, чтобы иметь возможность использовать его с Raspberry PI. Со значениями по умолчанию он будет пригоден для использования, но менее безопасен. Будет ли он по-прежнему пригоден для использования с увеличенным числом итераций или он снова будет потреблять слишком много памяти?)
решение1
Во-первых, обратите внимание, что документация LUKS, которую вы читали, была написана для LUKS1 и сейчас несколько устарела. Все, что вы цитировали (например, количество итераций), относится к алгоритму PBKDF2, который ваш разделна самом деле не использует.
LUKS2 поддерживает два алгоритма для преобразования вашей парольной фразы в ключ: традиционный PBKDF2, а также более новый Argon2. Последний — это то, что LUKS теперь использует по умолчанию, и это единственный алгоритм, который имеет (регулируемый) минимальный требуемый объем памяти. Это не то же самое, что «количество итераций».
Однако меня беспокоит возможное снижение уровня безопасности (вероятно, при меньшей вычислительной мощности будет использоваться более слабый ключ).
Вы не регулируете силу нажатия клавиши, вы регулируете еезащита.
Параметры, которые вы настраиваете, предназначены для защиты от попыток взлома вводимой вами парольной фразы — они предотвращают атаки методом подбора (то есть попытки перебора нескольких парольных фраз подряд), делая процесс получения ключа невыносимо медленным.
Однако созданный ключ всегда одинаково надежен сам по себе (он так же хорош, как любой другой ключ AES), и никто не станет пытаться атаковать его напрямую.
Если он медленнее, то медленнее только разблокировка или последующие чтения/записи такие же быстрые, как и без дополнительной итерации? (Если да, то почему? Потому что при разблокировке мы расшифровываем только ключ, который позже будет использоваться для расшифровки содержимого раздела?)
Каждый раз, когда вы разблокируете том, LUKS преобразует вашу парольную фразу в ключ шифрования, используя «функцию вывода ключа» (KDF), чтобы процесс был более устойчив к атакам методом подбора — LUKS1 всегда использовал «PBKDF2», который устойчив за счет медленного вычисления (но не предъявляет никаких требований к памяти), в то время как LUKS2 дополнительно поддерживает «Argon2», который вместо этого требует определенного объема оперативной памяти.
Вывод ключа происходит только один раз во время разблокировки; остальная часть (фактическое шифрование данных) вообще не требует использования парольных фраз.
(Другими словами: я хочу пересоздать раздел, чтобы иметь возможность использовать его с Raspberry PI. Со значениями по умолчанию он будет пригоден для использования, но менее безопасен. Будет ли он по-прежнему пригоден для использования с увеличенным числом итераций или он снова будет потреблять слишком много памяти?)
Вам вообще не нужно заново создавать раздел, поскольку даже ключ, полученный с помощью парольной фразы, не используется для шифрования ваших данных напрямую: он шифрует тольковладелецключ хранится в заголовке тома LUKS.
Вот почему можно быстро изменить парольную фразу без необходимости перешифровывать весь диск (или даже иметь несколько паролей), и точно так же LUKS позволяет вам легко изменять параметры KDF.
Если параметры Argon2 по умолчанию используют слишком много памяти, просто сообщите об этом LUKS:
cryptsetup luksConvertKey --pbkdf "argon2i" --pbkdf-memory <num_kilobytes> <device>Если вы вообще не можете использовать Argon2, вы все равно можете указать LUKS использовать вместо него PBKDF2:
cryptsetup luksConvertKey --pbkdf "pbkdf2" --iter-time <milliseconds> <device>Вместо миллисекунд (которые зависят от устройства) вы можете напрямую указать число PBKDF2итерациикоторое вы хотите (что всегда дает один и тот же результат, независимо от того, на каком устройстве вы это делаете) — на ПК значение по умолчанию составляет около миллиона:
cryptsetup luksConvertKey --pbkdf "pbkdf2" --pbkdf-force-iterations <count> <target>
Те же самые параметры принимаются luksChangeKey(при изменении парольной фразы), на самом деле, кажется, онинуждатьсянеобходимо указывать каждый раз при изменении парольной фразы.