為什麼像 A5/1 和 ZUC 這樣的流密碼有“幀”？
A5/1 和（我認為）ZUC 都是移動通信中使用的流密碼，都有“幀”，其中除了密鑰之外，還向密鑰流生成器提供了一個幀號，它產生了一個相對較短的偽隨機序列，稱為“幀”（最多為幾千字節）。
推進流密碼需要增加計數器並再次執行算法，而不會從前一幀的生成中繼承任何狀態。這與 RC4、Trivium 和 Grain 等流密碼形成對比，其中 $ i $ th keystream 位只能在生成前一個之後計算 $ i-1 $ 位，與計數器模式和流密碼（如 ChaCha20）相比，它們能夠完全隨機訪問。
這些“框架”背後的基本原理是什麼？如果他們想要的話，為什麼不直接進行完全隨機訪問呢？
這些“框架”背後的基本原理是什麼？如果他們想要的話，為什麼不直接進行完全隨機訪問呢？
那是因為它們用於移動通信。在那裡，數據包在傳輸過程中很容易被丟棄（例如，由於恰好在錯誤的時間進入的一點電雜訊）；可能與接收者甚至不知道他錯過了一個。
因此，有必要設計我們的加密系統，即使封包遺失也能夠解密；使用只有在成功接收到先前的數據包時才能解密的系統是行不通的。一種方法是輸入幀號；通過使用幀號，即使他錯過了一些數據包，解密器也可以工作。
現在，您可能會認為我們還可以嘗試使系統可靠，方法是讓發送方重新傳輸接收方沒有收到的數據包（就像 TLS 一樣）。這確實不適用於語音通信。它不僅消耗額外的頻寬（這是寶貴的），現場語音是時間敏感的；如果下一個音頻片段確實來晚了，接收者就無法對它做任何事情，因此重新傳輸它沒有任何意義。
至於為什麼他們使用序列號，而不是另一種方法（例如隨機隨機數），需要序列號來告訴接收者何時應該重播這段語音，因此語音通信無論如何都有序列號；將相同的東西用於兩個不同的目的會減少使用的頻寬（正如我所說，這是無線的主要問題）。
這些“框架”背後的基本原理是什麼？如果他們想要的話，為什麼不直接進行完全隨機訪問呢？
首先為名稱“幀號”。在低級通信技術中，例如乙太網或 WiFi，您會考慮“位”而不是“高級數據包/結構”，單個數據包不需要一對一映射到 IP 數據包，被稱為幀。
現在他們為什麼使用它。這個幀索引對密碼的作用與對 GCM 等成熟模式的隨機數相同：因此，相同明文的不同加密會產生不同的明文。為此，您需要隨機數的唯一性，這恰好是幀索引的情況。
最後，為什麼不使用隨機訪問？**這不是必需的。**您很少需要隨機訪問明文（而是一次性解密整條消息），這是設計人員認為擁有這種隨機數機制就足夠的情況之一。此外，如果您像在 CTR 中那樣實現流密碼塊索引之間的關係，這很容易被誤用，因為在 CTR 中，如果您的消息長於 1 個塊，則您的 IV 需要比 1 更大的偏移量，而使用這個偏移量 1 可能是安全的。