假设我想使用 cryptsetup 创建一个存储在文件中的大型加密驱动器，第一步是创建一个随机文件，假设大小应为 3T：
dd if=/dev/urandom of=$FILE bs=1G count=3000
上述过程可能需要很长时间。我想知道以下快捷方式是否有意义（从安全角度来看，记住目标是创建存储在 $FILE 中的加密驱动器）：
dd if=/dev/urandom of=$FILE bs=1G count=1000- 将上述文件复制3份，每个文件大小1T，随机内容相同
- 合并3个文件，创建1个目标大小为3T的随机文件
我猜想这个过程并不严格，因为数据有点“不太”随机，但从务实的角度来看，这是一个可行的解决方案（它会快几乎3倍）？这比创建一个全是零的 3T 文件（使用/dev/zero）更好吗？
答案1
/dev/urandom对于这么大的数据量来说太慢了。
如果伪随机足够好：
shred -v -n 1 /kill/me
如果加密的随机数足够好：
cryptsetup open --type=plain /kill/me cryptkillme
shred -v -n 1 /dev/mapper/cryptkillme
cryptsetup close cryptkillme
加密也很慢，但仍然比/dev/urandom.
shred对于任何磁盘来说，应该足够快地生成随机数据。
另请注意，对于这个大小，您确实应该使用常规块设备，而不是文件。如果承载巨大文件的文件系统损坏，您将面临一个无法解决的难题，其中有很多碎片，因为这种大小的文件通常会严重碎片化。
如果你坚持使用文件，你可以考虑首先不要用随机数据填充它；您可以使用稀疏文件来代替，并修剪/打孔它以节省未使用区域的存储空间。
如果覆盖旧的未加密数据是您的目标，您还必须覆盖文件系统中的所有可用空间，而不仅仅是容器文件本身，因为您不知道它是否与您想要的未加密数据分配在同一位置摆脱。
答案2
回答您问题的最后部分：您的方法（使用相同的随机数据三次）是否比使用零更好。
不完全一样，几乎是一样的。通过三个相同的随机部分，设备上的每个块都是三个相同块的一部分。因此，攻击者可以绘制出设备中已更改的块，这与攻击者从清零设备获取的信息相同。只有当您的设备太满以至于每个三元组具有三个不同的块时，这种情况才会发生故障。