静态数据加密
本文讨论 静态数据 加密 软件，该软件可在写入/读取 块设备、磁盘分区 或目录时，对数据进行即时加密/解密。块设备的例子包括硬盘、闪存驱动器和 DVD。
静态数据加密应仅被视为操作系统现有安全机制的补充——侧重于保护物理访问，同时依赖于系统的*其他*部分提供网络安全和用户访问控制等功能。
为何使用加密？
静态数据加密可确保文件始终以加密形式存储在磁盘上。只有在系统运行并由受信任的用户解锁时（数据*使用中*或*传输中*），文件才会以可读形式提供给操作系统和应用程序。直接查看磁盘内容的未经授权人员只会找到杂乱的随机数据，而不是实际文件。
例如，这可以防止在计算机或硬盘
- 放置在非受信任人员可能在您离开时访问的地方
- 丢失或被盗，如笔记本电脑、上网本或外部存储设备
- 送修
- 报废
此外，静态数据加密还可以用于增加一些安全性，以防止未经授权的对操作系统进行篡改的尝试——例如，攻击者在您离开时通过物理访问系统来安装键盘记录器或木马。
您仍然容易受到以下攻击：
需要一个非常强大的磁盘加密设置（例如，带有完整性检查的全系统加密，没有明文启动分区）才能有机会对抗能够*在您使用系统之前*篡改您系统的专业攻击者。即使这样，也无法防止所有类型的篡改（例如，硬件键盘记录器）。最好的补救措施可能是 基于硬件的全盘加密 和 可信计算。
系统数据加密
虽然仅加密用户数据本身（通常位于主目录内，或位于可移动媒体如数据 DVD 上）是最简单且侵入性最小的方法，但它也有一些显著的缺点。在现代计算机系统中，有许多后台进程可能会在硬盘的非加密区域缓存和存储有关用户数据或数据本身部分的信息，例如：
解决方案是同时加密系统和用户数据，防止未经授权的物理访问系统可能缓存的私人数据。然而，这带来的缺点是磁盘的加密部分必须在启动时解锁。系统数据加密的另一个好处是，它会使安装恶意软件（如键盘记录器或 rootkit）变得复杂，以防止拥有物理访问权限的人进行安装。
准备工作
选择设置
哪种加密设置适合您将取决于您的目标（请阅读上面的 #为何使用加密？）和系统参数。
除其他事项外，您还需要回答以下问题：
- 您想防止哪种类型的“攻击者”？
- 在系统关闭、被盗等情况下，随意翻看您磁盘的普通计算机用户。
- 在您使用系统之前和之后，能够反复读写您系统的专业密码分析师。
- 介于两者之间的任何人。
- 您想加密什么？
- 仅用户数据
- 用户数据和系统数据
- 仅保密数据，即您数据的子集
- 如何处理交换、
/tmp等？
- 禁用或挂载为内存盘
- 加密交换
- 作为全盘加密一部分的交换文件
- 单独加密交换分区
- 如何解锁磁盘的加密部分？
- 密码
- 与登录密码相同
- 与登录密码不同
- 密钥文件（例如，存储在 U 盘上，您将其存放在安全地方或随身携带）
- 两者兼有
- 何时应解锁磁盘的加密部分？
- 启动前
- 启动期间
- 登录时
- 按需手动*（登录后）*
- 如何容纳多个用户？
- 完全不容纳
- 使用所有用户都知道的共享密码短语（或密钥文件）
- 为同一加密磁盘部分独立发行和撤销的密码短语（或密钥文件）
- 为不同用户提供单独的加密磁盘部分
然后，您可以根据 #可用方法 和 #加密如何工作 进行必要的技术选择，例如：
- 堆叠文件系统加密与块设备加密
- 密钥管理
- 密码和操作模式
- 元数据存储
- “下层目录”的位置（对于堆叠文件系统加密）
准备磁盘
在对磁盘（或其一部分）设置加密之前，请考虑先将其安全擦除。这包括用零字节或随机字节流覆盖整个驱动器或分区，其原因如下（一个或两个）：
- 防止恢复先前存储的数据
磁盘加密并不能改变这样一个事实：单独的扇区仅在文件系统创建或修改这些扇区所保存的数据时才会被覆盖（参见下面的 #加密如何工作）。文件系统认为“当前未使用”的扇区不会被触及，并且可能仍然包含来自先前文件系统的旧数据残留。要确保您先前存储在驱动器上的所有数据都无法被 恢复 的唯一方法是手动擦除它。为此，使用零字节或随机字节并不重要（尽管使用零字节擦除会快得多）。
- 防止泄露加密驱动器上的使用模式
理想情况下，整个加密磁盘部分应与均匀随机数据无法区分。这样，任何未经授权的人都无法知道哪些扇区以及有多少个扇区实际上包含加密数据——这本身可能就是一个可取的目标（作为真正保密的一部分），并且还可以作为阻止攻击者尝试破解加密的额外屏障。为了满足此目标，使用高质量随机字节擦除磁盘至关重要。
第二个目标仅与块设备加密结合才有意义，因为在堆叠文件系统加密的情况下，加密数据可以很容易地被定位（以主机文件系统中不同的加密文件的形式）。另请注意，即使您只想加密某个特定文件夹，如果您想摆脱以前以明文形式存储在该文件夹中的文件，您也必须擦除整个分区（由于 磁盘碎片）。如果同一分区上有其他文件夹，您需要先备份它们，然后再将它们移回。
一旦您决定要执行哪种类型的磁盘擦除，请参阅 安全擦除磁盘 文章以获取技术说明。
可用方法
所有静态数据加密方法都以这样的方式运行：即使磁盘实际包含加密数据，只要加密容器（即包含加密数据的磁盘逻辑部分）被“解锁”并挂载，操作系统和应用程序就“看到”它为相应的正常可读数据。
为此，用户需要提供一些“秘密信息”（通常以密钥文件和/或密码短语的形式），从中可以派生出实际的加密密钥（并将其存储在会话期间的内核密钥环中）。
如果您对这类操作完全不熟悉，请也阅读下面的 #加密如何工作 部分。
可用的静态数据加密方法可以根据其操作层分为两类：
堆叠文件系统加密
堆叠文件系统加密解决方案被实现为堆叠在现有文件系统之上的一个层，它使得写入加密启用文件夹的所有文件在底层文件系统将其写入磁盘之前被即时加密，并在文件系统从磁盘读取它们时被解密。这样，文件就以加密形式存储在宿主文件系统中（意味着它们的内容，以及通常的文件/文件夹名称，都被替换为长度大致相同的随机数据），但除此之外，它们仍然像没有加密一样，作为普通文件/符号链接/硬链接/等存在于该文件系统中。
其实现方式是，要解锁存储原始加密文件（在宿主文件系统中，“下层目录”）的文件夹，它（使用特殊的堆叠伪文件系统）会被挂载到其自身或可选的其他位置（“上层目录”），在那里相同的文件会以可读形式出现——直到它被再次卸载，或系统关闭。
此类别中的可用解决方案包括 eCryptfs 和 EncFS，或下面的云就绪选项之一。
优化云存储
如果您正在部署堆叠文件系统加密以实现与第三方控制的位置（如云存储服务）的零知识同步，您可能需要考虑 eCryptfs 和 EncFS 的替代方案，因为它们并未针对通过互联网传输文件进行优化。有一些为此目的而设计的解决方案：
- gocryptfs
- cryptomatorAUR 或 cryptomator-binAUR (跨平台)
- cryfs
请注意，一些云存储服务通过其自己的 客户端应用程序 直接提供零知识加密。
块设备加密
另一方面，块设备加密方法在文件系统层*之下*运行，并确保写入特定块设备（即整个磁盘、分区或充当 loop 设备 的文件）的所有内容都已加密。这意味着，当块设备处于离线状态时，其全部内容看起来就像一大块随机数据，无法确定它包含什么类型的文件系统和数据。访问数据的方式，同样是通过以特殊方式将受保护的容器（在本例中为块设备）挂载到任意位置。
Arch Linux 中提供的“块设备加密”解决方案如下：
- loop-AES
- loop-AES 是 cryptoloop 的后代，是一种安全快速的系统加密解决方案。然而，loop-AES 被认为比其他选项的用户友好性稍差，因为它需要非标准的内核支持。
- dm-crypt
- dm-crypt 是 Linux 内核提供的标准设备映射器加密功能。喜欢完全控制分区和密钥管理所有方面的用户可以直接使用它。dm-crypt 的管理是通过 cryptsetup 用户空间实用程序完成的。它可以用于以下类型的块设备加密：*LUKS*（默认）、*plain*，并对 *loopAES* 和 *Truecrypt* 设备具有有限的功能。
- LUKS，默认使用，是一个额外的便利层，它将 dm-crypt 所需的所有设置信息存储在磁盘本身上，并抽象了分区和密钥管理，以尝试提高易用性和加密安全性。
- plain dm-crypt 模式，作为原始内核功能，不使用便利层。用它来实现相同的加密强度会更困难。这样做会产生更长的密钥（密码短语或密钥文件）。然而，它在非常特定的情况下也有其他优势。例如，单个块设备可以被分割并相应地加密。
- TrueCrypt/VeraCrypt
- 一种便携式格式，支持对整个磁盘/分区或文件容器进行加密，并与所有主要操作系统兼容。TrueCrypt 于 2014 年 5 月停止由其开发者维护。 VeraCrypt 分支于 2016 年进行了审计。
有关所选操作层的实际影响，请参阅下面的 #块设备与堆叠文件系统加密，以及 eCryptfs 的一般性说明。请参阅 Category:Encryption 以获取下面比较的方法以及表中未包含的其他工具的可用内容。
块设备与堆叠文件系统加密
| 块设备加密 | 原生/堆叠文件系统加密 | |
|---|---|---|
| 加密 | 块设备 | 文件 |
| 加密数据的容器可以是... | 磁盘或磁盘分区/充当 loop 设备的文件 | 现有文件系统中的目录 |
| 与文件系统的关系 | 在文件系统层以下操作：不关心加密块设备的内容是文件系统、分区表、LVM 设置还是其他任何内容。 | 通过文件系统原生功能，或为现有文件系统添加额外的/堆叠的加密层来实现加密。两者都会在文件被写入/读取时自动加密/解密文件。 |
| 加密文件元数据（文件数量、目录结构、文件大小、权限、修改时间等） | 是 （使用 'discard' 可能会泄露文件大小） |
部分 （文件名被加密，其他元数据可能可见，具体取决于功能） |
| 可用于自定义加密整个硬盘（包括分区表） | 是 | 否 |
| 可用于加密交换空间 | 是 | 否 |
| 可用于在不预先分配固定空间给加密数据容器的情况下使用 | 否 （使用 'discard' 可能允许稀疏分配的容器，但代价是泄露文件大小） |
是 |
| 可用于保护现有文件系统，而无需块设备访问，例如 NFS 或 Samba 共享、云存储等。 | 否1 | 是2 |
| 允许对加密文件进行离线基于文件的备份 | 否 | 是 |
- 嗯，这些文件系统中的单个文件可以用作容器（虚拟 loopback 设备！），但那样的话，我们就不能真正使用文件系统（及其提供的功能）了。
- ZFS 不支持。其他文件系统原生加密的挂载限制可能适用。
比较表
“dm-crypt +/- LUKS”列表示 dm-crypt 在 LUKS（“+”）和普通（“-”）加密模式下的功能。如果特定功能需要使用 LUKS，则由“(with LUKS)”指示。同样，“(without LUKS)”表示使用 LUKS 对于实现该功能适得其反，应使用普通模式。
| 总结 | Loop-AES | dm-crypt +/- LUKS | VeraCrypt | ZFS | fscrypt | eCryptfs | EncFS | gocryptfs |
|---|---|---|---|---|---|---|---|---|
| 加密类型 | 块设备 | 块设备 | 块设备 | 原生文件系统或块设备 | 原生文件系统 | 堆叠文件系统 | 堆叠文件系统 | 堆叠文件系统 |
| 注 | 存在时间最长的；可能最快的；在旧系统上运行 | Linux 上块设备加密的事实标准；非常灵活 | TrueCrypt 的维护分支，支持 TrueCrypt 和 VeraCrypt 卷 | 加密功能相对较新（2019 年）；由 ZVOL 提供的加密块设备 | Chrome OS 和 Android 加密的默认选项 | 比 EncFS 稍快；单个加密文件可在系统之间移植 | 最容易使用的；支持非 root 管理 | EncFS 的潜在继承者 |
| Arch Linux 中的可用性 | 需要手动编译的自定义内核 | 内核模块：已随默认内核提供；工具： device-mapper、cryptsetup | veracrypt | ZFS#Installation | 内核模块：已随默认内核提供；工具： fscrypt | 内核模块：已随默认内核提供；工具： ecryptfs-utils | encfs | gocryptfs |
| 许可证 | GPL | GPL | Apache 许可证 2.0，部分受 TrueCrypt 许可证 v3.0 约束 | CDDL | GPL (内核)，Apache 2.0 (用户空间工具) | GPL | GPL | MIT |
| 加密实现于... | 内核空间 | 内核空间 | 内核空间 | 内核空间 | 内核空间 | 内核空间 | 用户空间 (FUSE) | 用户空间 (FUSE) |
| 加密元数据存储于... | ? | 使用 LUKS 时：LUKS 头 | 设备开始/结束（解密后）（格式规范） | DSL（数据集和快照层；演讲/幻灯片） | 每个文件系统的根目录下的 .fscrypt 目录 |
每个加密文件的头 | 每个 EncFS 容器顶层的控制文件 | ? |
| 包装的加密密钥存储于... | ? | 使用 LUKS 时：LUKS 头 | 设备开始/结束（解密后）（格式规范） | DSL（数据集和快照层；演讲/幻灯片） | 每个文件系统的根目录下的 .fscrypt 目录 |
可以存储在任何地方的密钥文件 | 可以存储在任何地方的密钥文件 | ? |
| 可用性功能 | Loop-AES | dm-crypt +/- LUKS | VeraCrypt | ZFS | fscrypt | eCryptfs | EncFS | gocryptfs |
| 非 root 用户可以创建/销毁加密数据容器 | 否 | 否 | 否 | 是 | 是 | 有限 | 是 | 是 |
| 提供图形用户界面 | 否 | 否 | 是 | 否 | 否 | 否 | 是 | 否 |
| 支持登录时自动挂载 | ? | 是 | 是 | 是，使用 systemd | 是 | 是 | 是 | 是 |
| 支持在不活动时自动卸载 | ? | ? | ? | 否 | 否 | ? | 是 | 是 [3] |
| 安全性功能 | Loop-AES | dm-crypt +/- LUKS | VeraCrypt | ZFS | fscrypt | eCryptfs | EncFS | gocryptfs |
| 支持的密码 | AES | AES、Anubis、CAST5/6、Twofish、Serpent、Camellia、Blowfish……（内核加密 API 提供的所有密码） | AES、Twofish、Serpent、Camellia、Kuznyechik | AES | AES、ChaCha12 | AES、Blowfish、Twofish…… | AES、Blowfish、Twofish 以及系统上可用的任何其他密码 | AES |
| 完整性 | none | LUKS2 中可选 | none | CCM、GCM | none | none | 无（默认模式） HMAC（偏执模式） |
GCM |
| 支持加盐 | ? | 是 （使用 LUKS 时） |
是 | 是 | 是 | 是 | ? | 是 |
| 支持级联多个密码 | ? | 不在一个设备中，但块设备可以级联 | 是 AES-Twofish、AES-Twofish-Serpent、Serpent-AES、Serpent-Twofish-AES、Twofish-Serpent |
否 | 否 | ? | 否 | 否 |
| 支持密钥槽扩散 | ? | 是 （使用 LUKS 时） |
? | ? | 否 | ? | ? | ? |
| 防密钥清理 | 是 | 是 （不使用 LUKS 时） |
? | ? | 否 | ? | ? | ? |
| 支持同一加密数据有多个（可独立撤销的）密钥 | ? | 是 （使用 LUKS 时） |
? | 否 | 是 | ? | 否 | ? |
| 性能功能 | Loop-AES | dm-crypt +/- LUKS | VeraCrypt | ZFS | fscrypt | eCryptfs | EncFS | gocryptfs |
| 多线程支持 | ? | 是 [4] |
是 | 是 | 是 | ? | ? | 是 |
| 硬件加速加密支持 | 是 | 是 | 是 | 是 | 是 | 是 | 是 [5] |
是 |
| 块设备加密专用 | Loop-AES | dm-crypt +/- LUKS | VeraCrypt | ZFS | ||||
| 支持（手动）原地调整加密块设备大小 | ? | 是 | 否 | 是 | ||||
| 堆叠文件系统加密专用 | ZFS | fscrypt | eCryptfs | EncFS | gocryptfs | |||
| 支持的文件系统 | ZFS | ext4、F2FS、UBIFS | ext3、ext4、xfs（有例外）、jfs、nfs…… | ext3、ext4、xfs（有例外）、jfs、nfs、cifs…… | 任何 | |||
| 加密文件名的能力 | 是 zfs(8) |
是 | 是 | 是 | 是 | |||
| *不*加密文件名的能力 | 否 | 否 | 是 | 是 | 是 [7] | |||
| 稀疏文件优化处理 | 是 | 是 | 否 | 是 | 是 | |||
| 兼容性与普及性 | Loop-AES | dm-crypt +/- LUKS | VeraCrypt | ZFS | fscrypt | eCryptfs | EncFS | gocryptfs |
| 支持的 Linux 内核版本 | 2.0 或更新 | CBC 模式自 2.6.4 起，ESSIV 2.6.10，LRW 2.6.20，XTS 2.6.24 | ? | 2.6.32 或更新（截至 0.8.3） | 4.1 或更新 | ? | 2.4 或更新 | ? |
| 加密数据也可从 Windows 访问 | ? | ? | 是 | 是 Windows 上的 OpenZFS（仓库） |
否 | ? | 否（需要管理员权限） | 是（cppcryptfs 端口） |
| 加密数据也可从 Mac OS X 访问 | ? | ? | 是 | 是 OS X 上的 OpenZFS（仓库） |
否 | ? | 是 [8] |
是（测试版质量） |
| 加密数据也可从 FreeBSD 访问 | ? | ? | 是 | 是 FreeBSD 上的 ZFS（原生；仓库） |
否 | ? | 是 [9] |
? |
| Used by | ? | Debian/Ubuntu 安装程序（系统加密） Fedora 安装程序 |
? | ? | Android、Chrome OS | ? | ? | ? |
示例
实际上，这可能会变成：
- 示例 1
- 简单的用户数据加密（内部硬盘）使用用户主目录中的虚拟文件夹
~/Private，并使用 EncFS 加密- 文件在磁盘上
~/.Private中的加密版本 - 按需使用专用密码短语解锁
- 文件在磁盘上
- 示例 2
- 部分系统加密，每个用户的家目录都使用 ECryptfs 加密
- 在各自的用户登录时使用登录密码短语解锁
- 使用自动生成的每会话一次性密钥，使用 Dm-Crypt with LUKS 加密的
swap和/tmp分区 - 禁用 slocate（及类似应用程序）对
/home内容的索引/缓存。
- 示例 3
- 系统加密 - 整个硬盘（除了
/boot分区）（然而，/boot可以使用 GRUB 加密）使用 Dm-Crypt with LUKS 加密- 在启动期间使用密码短语或带密钥文件的 U 盘解锁
- 也许为每个用户使用不同的密码短语/密钥 - 可独立撤销
- 可能跨多个驱动器的加密或使用 LUKS on LVM 的分区布局灵活性
- 示例 4
- 隐藏/明文系统加密 - 整个硬盘使用 plain dm-crypt 加密
- U 盘启动，使用专用密码短语加上带密钥文件的 U 盘
- 挂载前检查数据完整性
/boot分区位于上述 U 盘上
- 示例 5
- 文件容器加密 - 一个预分配的文件用作用户数据的加密容器
- 一个文件，例如
~/.volume.img，使用 Dm-Crypt/Encrypting a non-root file system#File container 加密 - 通过将整个容器复制到远程主机来定期备份
- 一个文件，例如
当然，还有许多其他组合是可能的。您应该仔细规划哪种设置适合您的系统。
加密如何工作
本节旨在对通常的磁盘加密设置的核心概念和过程进行高层次的介绍。
它不深入技术或数学细节（请查阅相关文献），但应能让系统管理员对不同设置选择（尤其是关于密钥管理）如何影响可用性和安全性有一个大致的了解。
基本原理
对于磁盘加密而言，每个块设备（或堆叠文件系统加密中的单个文件）被划分为长度相等的**扇区**，例如 512 字节（4096 位）。加密/解密然后按扇区进行，因此块设备/文件在磁盘上的第 n 个扇区将存储原始数据第 n 个扇区的加密版本。
每当操作系统或应用程序请求块设备/文件中的某个数据片段时，包含该数据的整个扇区（或多个扇区）将从磁盘读取，即时解密，并临时存储在内存中。
╔═══════╗
sector 1 ║"???.."║
╠═══════╣ ╭┈┈┈┈┈╮
sector 2 ║"???.."║ ┊ key ┊
╠═══════╣ ╰┈┈┬┈┈╯
: : │
╠═══════╣ ▼ ┣┉┉┉┉┉┉┉┫
sector n ║"???.."║━━━━━━(decryption)━━━━━━━▶┋"abc.."┋ sector n
╠═══════╣ ┣┉┉┉┉┉┉┉┫
: :
╚═══════╝
encrypted unencrypted
blockdevice or data in RAM
file on disk
同样，在每次写入操作时，所有受影响的扇区都必须完全重新加密（而其余扇区则保持不变）。
为了能够解密/加密数据，磁盘加密系统需要知道与之关联的唯一秘密“密钥”。每当要挂载相关的加密块设备或文件夹时，都必须提供其对应的密钥（以下称为其“主密钥”）。
密钥的熵对于加密的安全性至关重要。例如，特定长度的随机生成的字节字符串，如 32 字节（256 位），具有期望的属性，但手动记住和在挂载时应用是不切实际的。
因此，使用了两种技术作为辅助。第一种是应用密码学来提高主密钥的熵属性，通常涉及一个独立的人类友好的密码短语。对于不同类型的加密，#比较表 列出了相应的特性。第二种方法是创建一个高熵的密钥文件，并将其存储在与要加密的数据驱动器分开的介质上。
另请参阅 Wikipedia:Authenticated encryption。
密钥、密钥文件和密码短语
以下是如何使用密钥文件存储和加密保护主密钥的示例：
- 存储在明文密钥文件中
将主密钥简单地存储在一个文件（以可读形式）中是最简单的选项。该文件——称为“密钥文件”——可以存放在 U 盘上，您将其存放在安全位置，仅在您想要挂载加密磁盘部分时（例如，在启动或登录期间）将其连接到计算机。
- 存储在密钥文件或磁盘本身的密码保护形式中
主密钥（以及因此的加密数据）可以用一个秘密密码短语来保护，您必须记住它，并在每次想要挂载加密块设备或文件夹时输入。有关详细信息，请参阅下面的 #加密元数据。
- 为每个会话随机生成
在某些情况下，例如加密交换空间或 /tmp 分区时，根本不需要保留持久的主密钥。可以为每个会话随机生成一个新的一次性密钥，无需用户干预。这意味着一旦卸载，写入该分区的所有文件都永远无法被*任何人*再次解密——在这些特定用例中，这完全没问题。
加密元数据
加密技术经常使用加密函数来增强主密钥本身的安全性。在挂载加密设备时，密码短语或密钥文件会通过这些函数进行处理，只有结果才能解锁主密钥以解密数据。
一种常见的设置是应用所谓的“密钥拉伸”到密码短语（通过“密钥派生函数”），并将生成的增强密码短语用作解密实际主密钥（已事先以加密形式存储）的挂载密钥。
╭┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈╮ ╭┈┈┈┈┈┈┈┈┈┈┈╮ ┊ mount passphrase ┊━━━━⎛key derivation⎞━━━━▶┊ mount key ┊ ╰┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈╯ ,──⎝ function ⎠ ╰┈┈┈┈┈┬┈┈┈┈┈╯ ╭──────╮ ╱ │ │ salt │───────────´ │ ╰──────╯ │ ╭──────────────────────╮ ▼ ╭┈┈┈┈┈┈┈┈┈┈┈┈╮ │ encrypted master key │━━━━━━━━━━━━━━━━━━━━(decryption)━━━━▶┊ master key ┊ ╰──────────────────────╯ ╰┈┈┈┈┈┈┈┈┈┈┈┈╯
密钥派生函数（例如 PBKDF2 或 scrypt）刻意设计得很慢（它会多次迭代哈希函数，例如 HMAC-SHA-512 的 1000 次迭代），以便使暴力破解密码短语的攻击变得不可行。对于授权用户的正常用例，每会话只需要计算一次，因此轻微的延迟不成问题。它还会将一个附加的数据块，即所谓的“salt”（盐），作为参数——这在磁盘加密设置期间随机生成一次，并作为加密元数据的一部分不受保护地存储。因为对于每个设置，它的值都不同，这使得攻击者无法通过预先计算的密钥派生函数表来加速暴力破解攻击。
加密的主密钥可以与加密数据一起存储在磁盘上。这样，加密数据的保密性完全取决于秘密密码短语。
可以通过将加密的主密钥存储在例如 USB 闪存盘的密钥文件中来获得额外的安全性。这提供了双因素认证：访问加密数据现在需要您知道（密码短语），还需要您拥有（密钥文件）。
实现双因素认证的另一种方法是增强上述密钥检索方案，在将密码短语传递给密钥派生函数之前，对其进行数学“组合”，将从一个或多个外部文件（位于 USB 闪存盘或类似设备上）读取的字节数据结合起来。相关文件可以是任何内容，例如普通的 JPEG 图像，这可能有利于#可否认性。在此上下文中，它们仍被称为“密钥文件”。
派生完成后，主密钥将被安全地存储在内存中（例如在内核密钥环中），只要加密的块设备或文件夹保持挂载状态。
然而，它通常不直接用于解密/加密磁盘数据。例如，在堆叠文件系统加密的情况下，每个文件都可以自动分配自己的加密密钥。每当要读取/修改文件时，该文件密钥首先需要使用主密钥进行解密，然后才能用于解密/加密文件内容。
╭┈┈┈┈┈┈┈┈┈┈┈┈╮
┊ master key ┊
file on disk: ╰┈┈┈┈┈┬┈┈┈┈┈┈╯
┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐ │
╎╭───────────────────╮╎ ▼ ╭┈┈┈┈┈┈┈┈┈┈╮
╎│ encrypted file key│━━━(decryption)━━━━▶┊ file key ┊
╎╰───────────────────╯╎ ╰┈┈┈┈┬┈┈┈┈┈╯
╎┌───────────────────┐╎ ▼ ┌┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┐
╎│ encrypted file │◀━━━━━━━━━━━━━━━(de/encryption)━━━━━▶┊ readable file ┊
╎│ contents │╎ ┊ contents ┊
╎└───────────────────┘╎ └┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┘
└ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘
类似地，在堆叠文件系统加密的情况下，可以为文件名的加密使用一个单独的密钥（例如每个文件夹一个）。
在块设备加密的情况下，每个设备（因此，所有数据）使用一个主密钥。某些方法提供为同一设备分配多个密码短语/密钥文件的功能，而另一些则不提供。一些方法使用上述函数来保护主密钥，而另一些则将密钥安全性完全交由用户控制。dm-crypt 在普通模式或 LUKS 模式下使用的加密参数解释了两个示例。
比较这两种模式使用的参数时，会注意到 dm-crypt 普通模式具有与如何定位密钥文件相关的参数（例如 --keyfile-size、--keyfile-offset）。dm-crypt LUKS 模式不需要这些，因为每个块设备在开头都包含一个包含加密元数据的头部。头部包括使用的密码、加密的主密钥本身以及解密时派生它所需的参数。后者参数反过来源于主密钥初始加密期间使用的选项（例如 --iter-time、--use-random）。
有关不同技术的优点/缺点，请参阅#比较表或浏览特定页面。
参见
- Security#Passwords
- Wikipedia:Passphrase
- Wikipedia:Key (cryptography)
- Wikipedia:Key management
- Wikipedia:Key derivation function
Ciphers and modes of operation
用于转换相互对应的未加密数据和加密数据（“明文”和“密文”）的实际算法，对于给定的加密密钥，称为“密码”。
磁盘加密使用“块密码”，它作用于固定长度的数据块，例如 16 字节（128 位）。截至本文撰写时，主要使用的有
| 块大小 | 密钥大小 | 注释 | |
|---|---|---|---|
| AES | 128 位 | 128、192 或 256 位 | NSA 批准用于保护“绝密”级别的美国政府信息，当使用 256 位密钥（CNSA 2.0）时。对于非量子攻击者，128 位和 192 位密钥仍然安全（下方亦然）。通常具有快速的硬件实现。 |
| Blowfish | 64 位 | 32–448 位 | 最早的无专利安全密码之一，公开可用，因此在 Linux 上非常普及。 |
| Twofish | 128 位 | 128、192 或 256 位 | 开发为 Blowfish 的后续，但尚未获得如此广泛的使用。 |
| Serpent | 128 位 | 128、192 或 256 位 | 被认为是 AES 竞赛五位决赛选手中最安全的一个[10][11][12]。 |
通过将扇区划分为与密码块大小匹配的小块，并遵循一套特定的规则（所谓的“操作模式”）来连续地将密码应用于各个块，从而实现扇区（见上文）的加密/解密。
简单地分别应用密码而无需修改（称为“电子密码本 (ECB)”模式）是不安全的，因为如果相同的 16 字节明文总是产生相同的 16 字节密文，攻击者可以轻易地识别存储在磁盘上的密文中的模式。
实践中最基本（也是最常见）的操作模式是“密码块链 (CBC)”。使用此模式加密扇区时，每个明文数据块在加密前会与前一个块的密文以数学方式组合。对于第一个块，由于没有前一个密文可以使用，因此使用存储在扇区加密元数据中并称为“初始化向量 (IV)”的特殊预生成数据块。
╭──────────────╮
│initialization│
│vector │
╰────────┬─────╯
╭ ╠══════════╣ ╭─key │ ┣┉┉┉┉┉┉┉┉┉┉┫
│ ║ ║ ▼ ▼ ┋ ┋ . START
┴ ║"????????"║◀━━━(cipher)━━━━━(+)━━━━━┋"Hello, W"┋ block ╱╰────┐
sector n ║ ║ ┋ ┋ 1 ╲╭────┘
of file or ║ ║──────────────────╮ ┋ ┋ '
blockdevice ╟──────────╢ ╭─key │ ┠┈┈┈┈┈┈┈┈┈┈┨
┬ ║ ║ ▼ ▼ ┋ ┋
│ ║"????????"║◀━━━(cipher)━━━━━(+)━━━━━┋"orld !!!"┋ block
│ ║ ║ ┋ ┋ 2
│ ║ ║──────────────────╮ ┋ ┋
│ ╟──────────╢ │ ┠┈┈┈┈┈┈┈┈┈┈┨
│ ║ ║ ▼ ┋ ┋
: : ... : ... ... : ... : ...
ciphertext plaintext
on disk in RAM
解密时，过程也以相反的方式进行。
值得注意的是每个扇区独特初始化向量的生成。最简单的选择是根据易于获取的值（例如扇区号）以可预测的方式计算它。然而，这可能允许攻击者通过反复访问系统来执行所谓的水印攻击。为防止这种情况，可以使用一种称为“加密盐值初始化向量 (ESSIV)”的方法来生成初始化向量，使其对潜在攻击者看起来完全随机。
还有许多其他更复杂的操作模式可用于磁盘加密，它们已经提供了针对此类攻击的内置安全性（因此不需要 ESSIV）。其中之一是 XTS，自 cryptsetup 2.7.0 起，它比 ESSIV 更受青睐。其中一些还可以额外保证加密数据的完整性（即确认其未被没有密钥访问权限的人修改/损坏）。
参见
Stream ciphers
流密码以流的形式工作，不需要“操作模式”。然而，磁盘加密所需的属性（例如“宽块”）意味着需要在其之上添加层。就 Linux 上的磁盘加密而言，主要例子是在Adiantum配置中的 XChaCha12，xchacha12,aes-adiantum，专为没有 AES 加速硬件的低端系统设计。Adiantum 在此类硬件上运行速度很快。它还保证加密数据的完整性。
Plausible deniability
参见Wikipedia:Plausible deniability 和 Wikipedia:Deniable Encryption。
磁盘加密场景的备份
制作用户数据的备份以防止数据丢失。通常，您的加密数据的备份也应进行加密。
块设备加密
有多种选择；您可以将加密容器所在的磁盘块设备作为映像进行备份，例如 /dev/sdx，或者您可以备份加密容器内的文件系统，例如 /dev/mapper/dm_name，或者您可以使用rsync等工具备份文件。以下部分列出了每种选项的优缺点。
磁盘块设备备份
磁盘块设备的备份是
- 按原样加密，安全级别与工作副本相同
- 包含您的 LUKS 头
- 始终与磁盘块设备一样大
- 不允许进行增量备份、压缩或去重等高级备份策略
- 轻松恢复到新磁盘，因为这也会恢复加密容器
文件系统或文件备份
文件系统或文件的备份是
- 按原样不加密
- 应在通过网络传输或保存到磁盘之前进行加密，这需要额外的努力
- 不一定以与工作副本相同的安全级别加密
- 不包含您的 LUKS 头
- 仅与文件系统上的已用空间一样大，例如参见 partclone
- 允许增量备份、压缩或去重等高级备份策略
- 需要手动将加密容器恢复到新磁盘，例如通过恢复 LUKS 头备份
LUKS 头备份
如果使用 LUKS，则可以制作LUKS 头备份：定期检查和同步这些备份可能很有意义，特别是当密码已被撤销时。
然而，如果您有数据备份并想恢复它，您可以从头开始使用 cryptsetup 重新创建 LUKS 加密分区，然后恢复数据，因此备份 LUKS 头的重要性不如备份数据。