密碼回饋模式 (CFB) 中段的用途是什麼
在 NIST SP800-38A 中：關於塊密碼操作模式的建議 CFB 可以與一個參數
s（以比特為單位的數據段的大小）一起使用，該參數確定每個塊產生的密鑰流材料的數量。API 通常還具有至少生成 8 位段或與整個塊大小相同的段的參數 - 這是
s. 通常s當然限制為 8 的倍數，因為輸入/輸出以字節為單位。通常OFB也可以通過這種方式進行參數化，但似乎使用參數
s（具有與塊大小不同的值）不是標準中公認的操作模式。參數有什麼用
s？它只是與錯誤傳播有關嗎？
實際上，
s是在 CFB 模式下處理可以添加或刪除單個字節的加密數據的傳輸通道。在過去（比如 70 年代），通常通過串列通道（例如 RS-232）傳輸數據。這些通道並不完美，我們看到的一個常見錯誤是，如果發送器發送 7 個字節，接收器可能只得到 6 個（或者可能是 8 個）；這種情況只會偶爾發生，但絕對有可能。
現在，考慮一下如果我們通過這樣的通道發送 CBC 加密的數據會發生什麼。我們第一次丟棄一個字節時，會發生加密器和解密器假設的塊邊界不會對齊；加密器認為是下一個塊的第一個字節，解密器會假設是前一個塊的最後一個字節。解密器會變得亂七八糟，並且（這是重要的一點）它們沒有重新同步的機制。
這就是
sCFB 模式的用途；如果我們設置s=8，那麼在刪除（或添加）錯誤之後，解密器將獲得接下來的 8 個字節（假設 DES 是 8 個；畢竟這是 70 年代）作為亂碼，但隨後它將開始正確解密（當然假設，傳輸通道不會再給我們任何錯誤）。現在，時代變了；我們不再處理這些渠道了。此外，我們對主動攻擊者可以做什麼更加敏感。如果我們確實需要處理這樣的通道，我們更有可能將明文流分解為一系列記錄，分別加密（和 MAC）每條記錄，並插入非加密的重新同步協議（例如字節填充-of-record 標記）在它上面。這樣，一個錯誤可能會導致我們沒有收到一兩條記錄，但僅此而已（攻擊者無法引入任何虛假數據）。
至於
sOFB模式下的參數，那是公認的壞主意；使用 as < n極大地增加了 OFB 陷入短循環的可能性，而對補償沒有好處。