这里它表示，当使用ddthroughdm-crypt覆盖块设备时，仅dd应使用默认块大小，因为dm-crypt的块大小相同（512 字节），并且增加 的dd块大小可能会阻止写入最终块。
这也适用于openssl（在 Linux 中）吗？
这里吉尔斯说这openssl是默认的缓冲大小为8kB。在这种情况下，缓冲区大小与块大小相同吗？
鉴于 的dd默认块大小为 512，如果我想在 中使用 1M 的块大小dd，是否也必须为 设置-bufsize为相同的数字openssl？以-bufsize字节为单位？
同样，鉴于的默认（且不可配置）块大小为 128kB，是否不建议使用catthrough ？opensslcat
答案1
TLDR 没关系（如果我猜对了的话）
首先，openssl命令行可以做大约 50 种不同的事情；其中只有两个采用批量输入数据：enc加密或解密“文件”或对 base64 进行编码/解码作为特殊情况（并非真正加密），以及dgst对“文件”进行散列并可选地签名或验证。其中仅enc产生可用于“覆盖”某些内容的输出，所以我假设您是这个意思；rand还可以产生批量输出，但不依赖于任何输入。
二、问题在你链接的问题是延迟由于等待密码数据块或编码（base64）块通过网络。如果您只关心获得正确的输出，则延迟并不重要，并且如果源不是远程的，则无论如何都不会延迟。
openssl enc 使用分组密码和模式，特别是默认的 CBC，默认使用PKCS#5 填充（所谓的；官方是基于PKCS#5的PKCS#7，但是包括OpenSSL在内的很多人都只是说PKCS#5）。这使得它能够加密和解密任意数量的字节适合操作系统和文件系统支持的输入和输出“文件”的数据。加密文件（添加了填充）始终是所使用密码的块大小的精确倍数。对于基于密码的盐加密（也是默认设置），密文最多比明文长 32 个字节，因此在加密时您可能需要考虑这一点。如果您指定-nopad（对于分组密码/模式）禁用填充，并且明文必须是密码块大小的精确倍数。如果不是，则会发生错误并且输出不完整 - 尽管通常是非空的，这可能会使粗心的人或脚本/等误认为它是有效的，而实际上并非如此。
如果您使用流密码（目前只有RC4）或流模式分组密码（CFB OFB CTR）不需要或使用填充，并且明文可以是任意数量的字节（适合文件）。对于加盐的 PBE，密文仍然长了 16 个字节。 （警告：某些版本错误地将 CCM 和 GCM 模式列为 上支持的enc；如果您尝试使用它们，它们实际上不会工作。）
-bufsize是（仅）用于读取和写入数据的大小。它不需要与密码块大小（如果有）相关，尽管默认情况下它是 2 的中等幂，并且所有受支持的块密码的块大小都是 2 的小幂，因此它们恰好可以均匀划分。密码逻辑将大数据作为分成任意大小的块的流来处理；只有总长度很重要。但处理效率较低地段小块，因为它对 C 库和（通常）操作系统进行更多调用。
cat通过管道输入到输入中是可以的，尽管如果它只读取一个“文件”，那么与仅将该文件作为 的（重定向的）stdin或参数openssl enc没有任何好处。同样，如果只是复制数据，使用既没有坏处也没有好处；如果您使用任何其他功能，例如转换 EBCDIC 和/或固定长度记录（典型的 IBM 大型机数据），显然这是需要的。如果你openssl-indddd想1234+0 records in您确实需要dd或类似的有关等的统计数据。