Aes
某些分組密碼模式是否對隨機數進行加密，然後將其與數據進行異或？
閱讀https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Counter_(CTR)看起來 CTR（和其他一些模式）加密了 nonce（加上計數，用於 CTR）而不是明文。
然後將明文與加密的隨機數進行異或運算以生成密文。
我是否正確理解了這一點？
為什麼要這樣循環？
是的，CTR (resp. OFB) 模式首先“加密隨機數”然後增加它（分別用塊加密的結果替換它），然後重複，產生一個密鑰流；明文只是與密鑰流異或，形成密文。實際上，CTR 和 OFB 是由分組密碼製成的流密碼。
優點包括：
- 解密和加密是一樣的。
- 對於 AES，軟體中的塊解密本質上比塊加密的計算密集度更高，從而降低了解密成本。
- 無需填充明文以阻止邊界；截斷密鑰流就足夠了。
- 可以在數據可用之前生成密鑰流，從而減少加密/解密延遲。
- 對於 CTR，準備密鑰流是可並行的。與 CBC 相比，其中加密必須是順序的（除了要求數據的可用性之外）。
唯一的缺點是密文的延展性（意味著切換一點密文只會切換解密明文中的相應位），這是流密碼固有的。但是延展性對於像 AES-GCM（使用 CTR 模式進行加密）這樣的經過身份驗證的加密模式來說不是問題，因為依賴 CBC 模式的弱完整性屬性無論如何都是災難的根源。