我要使用 AES（使用 TrueCrypt）加密 PenDrive。格式化时最有效的分配单元大小是多少？
由于 AES 块大小为 16 KB，那么 16 KB 是否最有效？这个逻辑正确吗？
答案1
簇大小应根据物理介质的扇区大小和文件系统内文件的大小来选择。由于 U 盘是闪存，因此它使用块和页面而不是扇区。
闪存块通常为 16KiB 或 128KiB，页面大小为 512B 或 2048B。较大/较小工艺的闪存芯片使用较大的块大小。因此，可以安全地假设闪存上任何典型的 NTFS 簇大小都是可以接受的，大多数用途最多为 16KB。闪存以块为单位写入，因此除非文件很少被修改或大小足够大，否则不应选择大于块大小的簇大小。
讨论文件系统的内容时会更加复杂。没有标准做法，我根据预期的文件类型及其平均大小使用设定值。
对于 NTFS，4KiB 是大型磁盘最常见的尺寸，但当文件很大时（如视频文件和高比特率音频），这种尺寸就太浪费了。文件系统需要跟踪每个文件使用哪些簇，因此 16GiB 视频文件在文件表中将有 4194304 个簇条目。64KiB 簇文件系统上的同一文件只需要 262144 个条目。如果您只需要很少更改的大文件，请选择尽可能大的簇大小。如果文件较小或经常修改，则 2KiB 到 16KiB 之间是合适的范围。
对于 exFAT，32KiB 是外部闪存设备最常见的尺寸。exFAT 在设计时就考虑到了闪存，32KiB 适合大多数用途，但较大的不经常修改的文件除外，这些文件应使用较大的群集。此文件系统是新的，并且操作系统兼容性有限。
使用磁盘加密软件与簇大小无关，因为密码块大小小于最小可用簇大小。
答案2
关注底层文件系统而不是 AES 属性。以下是 MS 的列表，其中列出了不同文件系统/版本下不同卷大小的默认分配单元。您将无法实现密码块大小和文件系统分配单元大小之间的奇偶校验。事实上，尝试这样做可能会降低每个文件的加密效率，除非您的文件非常非常小。
答案3
集群（分配单元）的大小实际上与加密几乎没有任何关系——使用非加密虚拟磁盘时也会遇到完全相同的问题。
无论如何，引用TrueCrypt 文档（强调矿）：
“簇的大小
簇是分配单位。例如，在 FAT 文件系统中，一个字节的文件会分配一个簇。当文件超出簇边界时，会分配另一个簇。从理论上讲，这意味着簇大小越大，浪费的磁盘空间就越多；但是，性能越好。如果您不知道使用哪个值，请使用默认值。“
无论如何，您几乎肯定希望选择与存储 TrueCrypt 容器的磁盘相同的簇大小，或者可能是其偶数倍或分数，以便 TrueCrypt 卷中的簇与底层文件系统上的簇对齐（因此大概与存储它的实际磁盘上的扇区对齐）。
除此之外，这基本上只是速度/空间的权衡。具体细节将根据您使用的文件系统和要存储的文件类型而有所不同（经验法则：大文件 → 大簇，大量小文件 → 小簇），但通常默认值应该没问题。
答案4
使用磁盘加密软件有很多相关性，一些芯片一次读取/写入 32KiB，或其他大小，无论文件系统的簇大小是多少；磁盘加密软件使用长读/写，就像预加载缓存一样。
可怜的是他们中的大多数没有告知这一点，使用低级扫描仪我看到 VeraCrypt 使用 32KiB 读/写操作（在某些 Linux 上），而文件系统是 Ext4（仅允许 4kiB 集群），因此第一次读取比未加密的读取多花费八倍，但接下来的 7 次连续读取几乎都是即时的（也就是说，由第一次读取缓存）。
所以，是的，使用磁盘加密软件具有很大的相关性。
我希望我可以将 Ext4 簇大小设置为 32KiB，随机读取会比 4KiB 快得多，因为 VeraCrypt 始终读取 32KiB，因此在随机 4KiB 读取上浪费了 28KiB 读取。
请记住，许多加密工具（大多数是满盘）使用大块来读/写，这对于连续性来说非常好，但对于随机性来说却很糟糕。
而且 Linux 自己的磁盘缓存（预读）也很重要且相关，在加密时（未加密时也是如此）会对性能产生负面影响......这完全取决于您如何访问数据。
我遵循这个规则：系统磁盘 4KiB 非条带化，如果是条带化则为 128KiB（大多数是 SSD）；数据磁盘从 32KiB 到 128KiB，取决于小文件与大文件的比例；并且我总是在五个不同的媒体上保留五个副本，我手动同步，同时连接的次数不超过两次。
警告：AES 已损坏（至少 4096 位）。