dd、cat 和 openssl：塊大小和緩衝區大小
這裡它說當使用
ddthroughdm-crypt覆蓋塊設備時，dd應該只使用預設的塊大小，因為dm-crypt’ 的塊大小是相同的（512 字節），並且增加dd’ 的塊大小可能會阻止最終塊被寫入。這是否也適用於
openssl（在 Linux 中）？這裡Gilles 說
openssl’ 的預設緩衝區大小是 8kB。在這種情況下，緩衝區大小與塊大小相同嗎？鑑於
dd預設的塊大小是 512，如果我想使用 1M in 的塊大小dd，我是否也必須設置-bufsize為相同的數字openssl？是-bufsize字節嗎？同樣，考慮到預設（且不可配置）塊大小為 128kB ，是否不建議使用
catthrough ？openssl``cat
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管道openssl enc輸入輸入很好，儘管如果它只讀取一個“文件”，那麼僅將該文件作為（重定向的）stdinopenssl或-in參數沒有任何好處。dd同樣，如果只是複制數據，使用它既無害也無益；如果您使用任何其他功能，dd例如轉換 EBCDIC 和/或固定長度記錄（典型的 IBM 大型機數據），顯然是需要的。如果你想要關於等的統計資訊1234+0 records in，你確實需要dd或類似的。