☰

密码哈希太多？

tag-icon • tag-icon encryption luks manjaro
密码哈希太多？

我使用的是带有全盘加密的manjaro，但是，启动解密的等待时间很长（我认为是因为难度设置很高）。如何在安装过程中更改加密设置的加密难度/等待时间？

答案1

密码哈希太多？

如果它只是因为您正在等待大量密码哈希迭代而变慢，您可以添加一个具有更快的新密码--iter-time，但这可能会降低安全性并允许更快地猜测密码。如果您想等待 1 秒（1000 毫秒），请使用如下命令：

cryptsetup -v luksAddKey --iter-time 1000 <device>

然后，您可能必须删除旧的慢速密码（带有luksKillSlot），除非它的密钥插槽位于新的快速密码之后（它们显然是按顺序测试的，因此可能必须等待第一个慢速插槽在后面的快速密码之前进行测试一）。或者更改您的初始打开命令以指定新的更快的--key-slot数字。

该luksChangeKey命令可以结合这两个步骤，添加一个新密钥，然后删除旧密钥（尽管 v1.7 手册页没有明确说明它可以使用--iter-time，显然它可以）：

cryptsetup -v luksChangeKey --iter-time 1000 <device>

现在有多慢？

测试解密/打开您的设备需要多长时间：

cryptsetup -v luksOpen --test-passphrase <device>

或者使用以下选项测试特定的键槽--key-slot：

cryptsetup -v luksOpen --test-passphrase --key-slot N <device>

使用该time命令可能会有所帮助，但也会计算您的打字速度。

您可以使用该luksDump命令查看当前的关键插槽Iterations:是什么，这是非常慢的插槽 0 和非常快的插槽 1 的示例：

Key Slot 0: ENABLED
    Iterations:             4663017
    Salt:                   ......
    Key material offset:    8
    AF stripes:             4000
Key Slot 1: ENABLED
    Iterations:             1000
    Salt:                   ......
    Key material offset:    264
    AF stripes:             4000

从man cryptsetup：

  • --iter-time,-i

    PBKDF2 密码处理所花费的毫秒数。此选项仅与设置或更改密码的 LUKS 操作相关，例如 luksFormat 或 luksAddKey。指定 0 作为参数将选择编译时的默认值。

  • luksChangeKey <device> [<new key file>]

    更改现有密码。要更改的密码必须以交互方式或通过 --key-file 提供。新密码可以以交互方式提供，也可以在作为位置参数给出的文件中提供。

    如果指定了密钥槽（通过 --key-slot），则必须给出该密钥槽的密码，新密码将覆盖指定的密钥槽。如果未指定密钥槽且仍有空闲密钥槽，则在清除包含旧密码的密钥槽之前，将把新密码放入空闲密钥槽中。如果没有空闲的密钥槽，则直接覆盖旧密码的密钥槽。

    警告： 如果密钥槽被覆盖，则此操作期间的介质故障可能会导致在旧密码被擦除后覆盖失败，并使 LUKS 容器无法访问。

这不是密码哈希吗？

  • 启动速度慢的原因有很多，也许与加密无关。

或者，如果实际的加密/解密本身太慢，则可能需要更改算法或密钥大小，这将需要解密并重新加密所有内容。有一些程序（或较新版本中的命令）可以就地执行此操作，希望不会丢失任何内容，但拥有备份不仅仅是一个好主意。

但在这种情况下，这不仅是一个漫长的初始等待，而且所有读取和写入都会慢一些。

您可以使用该cryptsetup -v benchmark命令查看一些速度测试，但是“注意：此基准测试仅使用内存，并且仅提供信息。您无法从中直接预测真实的存储加密速度。”

相关内容