可公開驗證的身份驗證器
我正在開發一個塊儲存系統，我需要由客戶端加密和驗證塊，但也希望伺服器能夠檢測位損壞，同時最大限度地減少對數據所做的工作。儲存塊大約為 1MB 段。
一種選擇是讓客戶端使用 AE(AD) 密碼（如 AES/GCM），然後添加強校驗和。由於 AES/GCM 還不是最優化的密碼（在我的 Java 世界中），因此另一種選擇是使用更傳統的 encrypt-then-HMAC。但是，對於正常的 HMAC，這不能用作可公開驗證的校驗和。計算 HMAC 和校驗和會使需要完成的工作量翻倍（通過消息）。只計算消息的校驗和，並在這個簡化的數據集上使用 HMAC 怎麼樣？
encrypted = AESCBC(IV, plaintext-1MB) checksum = SHA224(ID | IV | len | encrypted) sig = HMAC(ID | len | checksum) message = ID | IV | len | encrypted | checksum | sig在這種情況下，我計算了一個可公開驗證的數據校驗和（因此我可以檢測伺服器上的損壞），除了添加的 HMAC 身份驗證器之外，只有客戶端可以檢查。HMAC 不需要遍歷所有加密數據，而是使用校驗和作為捷徑。每個段的 ID 都是唯一的。
在我的情況下，該協議不能用作匿名預言機，並且明文長度不能無限擴展，但是有意使用更能抵抗擴展攻擊的雜湊。
我還沒有看到太多關於使用普通雜湊進行內容認證的分析。誰能給我一個關於這是否安全的指針？（我還沒有進行性能分析；如果速度足夠快，我可能會簡單地使用 AES/GCM+SHA）。或者是否有更標準的構造來生成可公開驗證和驗證的標籤？
我還沒有看到太多關於使用普通雜湊進行內容認證的分析。誰能給我一個關於這是否安全的指針？
有很好的原語選擇。公鑰簽名以類似的方式使用散列函式來辨識簽名的消息。
然而，在 MAC 只需要相當於第二原像抗性的情況下，散列函式通常也需要抗碰撞性，因為攻擊者可以自己計算任意數量。（這就是為什麼 SHA-1 在簽名中被棄用的原因，即使沒有跡象表明它不抗原像。）
HMAC 也比它使用的散列函式更強。因此，雖然 SHA-224 很強大，但使用它的安全性會低於使用 HMAC-SHA-2。從技術上講，這可能意味著您甚至沒有 128 位安全性——“只有”112 位。
您實際上不需要在 HMAC 中使用校驗和本身。您可以改為使用完整的 SHA-256（或 SHA-512，可能更快）。如果你想截斷——由於 HMAC，長度擴展攻擊不是問題——只在寫入校驗和時截斷它，而不是在計算 HMAC 時截斷它。假設您在檢測損壞時不需要那麼大的信心，您甚至可以將校驗和截斷為僅幾個字節並節省一些空間。
是的
hash = SHA-NNN(ID | IV | len | encrypted) checksum = truncate(hash) sig = HMAC(ID | len | hash) message = ID | IV | len | encrypted | checksum | sig（在 HMAC 中包含 ID 和 len 似乎沒有必要，但沒有什麼壞處。）