在此設置中，AEAD 是否比原始密碼提供任何好處？
我正在研究一個加密數據儲存，其中需要通過加密數據的雜湊來辨識和引用 blob。想想帶有加密節點的默克爾樹。在散列已經建立真實性的這種設置中（假設散列函式本身沒有被破壞），使用 AEAD 而不是直接使用密碼是否有任何價值？
我相信這與經典的 encrypt-then-MAC 主題不同，因為 Blob 中沒有儲存散列或 MAC 來對其進行身份驗證。相反，雜湊是來自其他地方的外部引用，已經過身份驗證（不受攻擊者的警告）。
我最初忽略了一個進一步的細節，認為它無關緊要，但事後看來，它似乎澄清了問題：沒有預共享的對稱密鑰；可以在原始密碼或 AEAD 中使用的密鑰是從臨時秘密和接收方通過 ECDH 的公鑰派生的密鑰。因此，任何知道公鑰的攻擊者都可以使用他們自己的臨時密鑰生成帶有有效 AEAD 標籤的 blob。但是，假設散列函式沒有被破壞，這樣的 blob 將不會散列到接收方期望的值，因此永遠不會被使用。
如果已經有驗證明文的方法，那麼確實可以通過其他方法跳過對明文或密文的驗證。
當然也有一些流行語。
首先，明文在經過驗證的雜湊值被驗證之前不應該以任何方式使用。如果不是這種情況，那麼攻擊者可以更改明文，這意味著該方會受到多種類型的攻擊，包括明文預言或可能的故障注入。
此外，實現不應提供有關解密過程的任何資訊。如果是這樣，那麼實現可能會受到側通道攻擊。更糟糕的是，如果使案例如 CBC，則應用填充預言。因此，使用 AES-CTR 或 ChaCha20 等流密碼更有意義。
使用認證模式時，可以避免最後兩個設計/實現錯誤。因此，即使密鑰不可信，認證模式也有一些用途。一個缺點是其他開發人員可能會假設已驗證模式確實提供了所需的身份驗證，並開始使用明文，即使消息尚未經過身份驗證。
我個人不會為此使用身份驗證模式。
請注意，您描述的協議中未指定 IV 處理。如果這是保護明文而不是密文，則不需要成為散列的一部分。但是，您應該確保使用相同密鑰加密的每條消息都是唯一的（如果您使用 CBC 模式，則無法預測）。
如果經過身份驗證的雜湊同時用於辨識和身份驗證，我也看不到該協議是否容易受到重放攻擊和明文猜測攻擊。
雜湊建立完整性，而不是真實性。密文的 AEAD 標籤或 MAC 同時建立完整性和真實性。
如果散列是密文，攻擊者可以簡單地修改密文併計算新的散列，因為散列不依賴於密鑰。
如果散列是明文，你會得到與“MAC-then-encrypt”方案相同的弱點，在這些方案中你違反了密碼末日原則。