將數據附加到使用流密碼加密的經過身份驗證的密文中
假設我們使用 Poly1305 對 xSalsa20 進行了身份驗證。如果 $ X $ 是密文， $ N $ 是 nonce 值，並且 $ H $ 是身份驗證標籤，因此最終密文是 $ N || X || H $ ，然後給定密鑰 $ K $ , 是否可以擴展 $ X $ 有更多數據，無需解密，更新 $ N $ 和 $ Y $ 如所須？（我不確定是否 $ N $ 將需要更改。）
為了更清楚，說 $ X_m $ 是經過身份驗證的原始密文。我想附加明文數據 $ A $ 給它。我正在尋找一個實施方案 $ X_n = Append(X_m, A, K) $ 這樣 $ Decrypt(X_n, K) = Decrypt(X_m, K) | A $ .
Salsa20 是一種流密碼，因此它產生一個 CSPR 密鑰流， $ S $ ，然後密文就變成了 $ X = S \oplus P $ ， 在哪裡 $ P $ 是明文。所以我直覺上覺得這應該比使用分組密碼容易得多。也許通過生成相同的密鑰流直到密文的大小，並使用超過該點的密鑰流的一部分來加密新數據。如果身份驗證標籤是從密文生成的，那麼也不需要解密。據我所知，nonce 也不會真正在這樣的方案中重用。
這將如何轉化為 XChaCha20-Poly1305 等其他流密碼？
如果 $ X $ 是密文， $ N $ 是 nonce 值，並且 $ H $ 是身份驗證標籤，因此最終密文是 $ N | X | H $ ，然後給定密鑰 $ K $ , 是否可以擴展 $ X $ 有更多數據，無需解密，更新 $ N $ 和 $ H $ 如所須？
對於大多數方案，這是很有可能的，是的。
這有兩個部分：使用的 CPA 安全加密功能和消息驗證碼。
首先是加密功能：
- 如果它是基於 CTR 的，這沒有問題，因為只需將計數器跳過到最後一個塊的索引即可獲得必要的密鑰流。AES-CTR 被覆蓋，而且 (X)ChaCha 和 (X)Salsa 都是 CTR 模式下的 PRF。
- 對於 CBC，Aleksander 已經有了答案：您解密最後一個塊，繼續在使用填充的地方填充它，並將倒數第二個塊用作 IV。
- 對於 CFB，故事應該與 CBC 大致相同，但由於它很少使用，所以我沒有研究細節。
- 對於 OFB，因為它本質上是計算 $ S_i=E_k(S_{i-1}) $ 並使用 $ S_i $ 作為密鑰流，如果你知道相應的明文，你也可以從最後一個完全使用的塊中恢復狀態，如果你不走運，你必須從隨機數開始。
至於與這些有關的安全考慮：至少對於流模式，您永遠不會重複使用密鑰流，因此可以保留消息的保密性，但是對手當然可以知道消息已被擴展。
至於身份驗證程式碼，事情變得非常混亂：
- 對於 HMAC，即使知道密鑰，這似乎確實不可能重新計算完整的 MAC，因為 HMAC 的最後一步是執行密鑰，並且通過不允許恢復的不可逆 PRF 減少整個消息的結果從輸出的內部狀態。
- 對於 CCM 的 CBC-MAC，情況同樣嚴峻，因為它包括開頭的精確消息長度以及取決於此值的每個內部狀態。
- 對於使用不可逆 PRF（因此不是分組密碼）的 CBC-MAC，圖片類似於 HMAC，無法從輸出中恢復狀態。
然而，這給我們留下了兩類廣泛使用的 MAC：基於塊密碼 CBC-MAC 的 MAC 和 Carter-Wegmann MAC，如 Poly1305 和 GHASH。
- 對於基於 CBC-MAC 的使用分組密碼且不預先設置消息的方案*，*它們通常對最終塊進行特殊處理，無論是將特殊值異或到最後一個消息塊中，還是使用不同的密鑰再次加密密文。但是，如果您知道密鑰，這些轉換都是可逆的。因此，您可以有效地恢復最後一個塊之前的內部狀態，並為最後一個塊和您的更新重新計算 MAC。
- 對於 Carter-Wegman MAC，正如 poncho 解釋的那樣，它有點複雜，並且可能適用於特殊的非危險實現處理，但原則上它是可能的（特別是 GCM 使用的 GHASH），儘管如果對手得到，當然是非常危險的看到兩個密文。
請注意，在使用基於 CBC-MAC 的方案（如 EAX）時進行此擴展是安全的，因為使用的變體具有適當的 PRF，因此相關輸入的輸出與無密鑰對手沒有可觀察到的關係。