沒有MAC的ChaCha20可以實現數據認證嗎？
我的情況比較特殊。我需要以小塊發送數據，每個小於 32 字節。ChaCha20 狀態為 64 字節。
由於我將接收塊中的數據流，我喜歡即時驗證它（即在我收到每個塊之後，確保它沒有被調和）。
使用 MAC 是一個糟糕的選擇，因為我每次發送 32 字節塊並將其附加到消息時都必須計算 MAC。而且我認為這不是 Poly1305 的標準方法，據我了解，當所有數據傳輸時，您只計算一次 MAC，而不是發送中間 MAC。
所以我有了這個想法：與其計算 MAC（使用 Poly1305 或其他），不如只使用兩次 32 字節數據，製作一個可以與 ChaCha20 的一個狀態進行異或的 64 字節塊。
解密後，我驗證前 32 個字節等於後 32 個字節。如果是，則沒有修改。如果不是，則存在一些篡改/傳輸錯誤。
所以我的問題是：
1.重複密文兩次是否會損害流密碼的安全性？（假設攻擊者知道這一點）
2. 是否有一些標準方法如何在沒有這種“黑客”的情況下使用流密碼提供消息身份驗證？
感謝您的回答和意見！
對於一個塊，明文是 64 個字節，實際上是 32 個字節重複。重複不會影響接下來發生的事情。ChaCha 密鑰流是隨機的 64 字節。您將密鑰流與明文異或，從而創建密文。您通過網路發送密文。攻擊者翻轉密文中的位。你在另一邊產生相同的密鑰流，將它與被篡改的接收到的密文進行異或運算，你現在得到了明文，其中的位正好在攻擊者翻轉它們的位置翻轉。如果攻擊者知道明文的結構，他們可以翻轉位，使消息仍然有意義（反序列化、解析、解釋）但具有不同的含義。
這不是純粹的理論：Matthew Green攻擊了 Apple iMessage，它使用了 deflate 壓縮並設法翻轉了哈夫曼編碼的壓縮數據中的位，這些數據仍然可以很好地解壓。這種攻擊是可能的，因為密文沒有經過身份驗證。
您似乎不了解 CTR 或 Chacha 加密的工作原理。它不像 CBC，其中明文被送入隨機排列並且位翻轉會打亂整個塊（在 CBC 中，位翻轉會打亂一個塊但會精確影響下一個塊，因此 CBC 仍然具有很強的延展性，不得使用無需身份驗證，但 ChaCha 和 CTR 更具延展性）。
不要做你描述的。使用 MAC。不使用 MAC 會呼叫“密碼末日原則”。
如果您需要針對發送簡訊進行優化的 MAC，也許這裡有人可以推荐一些東西，儘管我認為 ssh 對 ChaCha20Poly1305 所做的事情是正確的做法。
總的來說：你有密碼學的高級學位嗎？不？不要發明自己的密碼原語。使用經過社區測試的良好加密原語。不要以新穎的方式組合好的密碼原語。使用經過良好測試的組合/協議。盡量不要自己實現好的協議。使用經過良好測試的實現。