Poly1305AES 發生了什麼？它已經過時了嗎？
有人告訴我，Poly1305AES是用於受限（嵌入式）環境的 MAC 的絕佳選擇。我簡單地查看了 DJB 的文章，不得不說我發現它的簡單性很討人喜歡，性能令人信服和安全證明足夠嚴格。
而且，
libsodium作者今天告訴我，他的圖書館不支持這種結構。因為…… **“它沒有在任何地方使用”。**我對這種稀缺的解釋感到困惑。
我也很困惑，因為 libsodium 確實支持 XChaCha20-Poly1305 和 AES，所以它具有所有原始部分；但不會給出組合結構。
弗蘭克丹尼斯還說：
沒有錯
$$ poly1305aes $$，但它沒有在任何地方使用，並且與現有結構相比，它沒有任何好處。
那些現有的建築是什麼？我猜對了嗎，HMAC-SHA2？
請對算法有所了解；我離高級密碼學還很遠，這種互動（+我的後續研究）只會讓我覺得“我知道我知道的不多”。
Poly1305 是一個通用雜湊函式。該函式的輸出未經加密就無法安全使用。
為了加密它，可以使用任何密碼。AES 在論文中被用作範例，但同一篇論文提到：
使用者可以從 Poly1305-AES 切換到 Poly1305-AnotherFunction，具有相同的安全保證。在 Poly1305-AES 的非 AES 部分投入的所有努力都可以重複使用；Poly1305-AES 的非 AES 部分不能被破壞。
事實上，即使是 Bernstein 也沒有在 AES 中使用這個功能。Poly1305 的第一個實際實例化是使用 Salsa20。
Poly1305 今天被廣泛使用，主要是與 Salsa20 變體 ChaCha20 一起使用。
使用 AES，它從未見過太多實際部署，而且 Poly1305-AES 從未成為任何標準的一部分。
GMAC 與 Poly1305 非常相似，但可以從許多也提供 AES 加速的平台上的硬體加速中受益。這可能是當今最常用的結構。
在受限系統上，AES-CCM 等結構是更好的候選者，因為 AES 核心功能可以同時用於加密和身份驗證，而不必實現兩個完全不同的功能。
回顧一下，Poly1305-AES 只是一個例子。該特定範例並未在實踐中使用，因為已經存在具有 AES 的標準化和廣泛部署的結構。這些要麼更緊湊，要麼由於硬體支持而最終變得非常高效。
但是 Poly1305 很好，尤其是在缺乏有效實現 GMAC 所需的硬體上（進行較少的乘法運算）。因此，它與在沒有硬體支持的情況下也很有效的密碼一起使用，而不是與 AES 一起使用。
那些現有的建築是什麼？
通常人們會考慮三到四種嵌入式環境的身份驗證加密方案：
- 受限於 ROM + RAM在這種情況下，您可能希望使用盡可能少的原語，並使用EAX或CCM模式等方式來使用分組密碼進行身份驗證和加密。（例如：廉價的物聯網設備）
- **執行時受限（無加速器）**在這種情況下，您可以通過使用具有輕量級身份驗證的 32 位優化 Salsa / ChaCha 流密碼來做出比 AES 更好的選擇，例如 Poly1305 導致 (X)ChaCha-Poly1305 / ( X)Salsa20-Poly1305。（例如：舊手機上的文件加密）
- **執行時受限（帶 AES 加速器）**在這種情況下，您可能希望充分利用您的加速器並再次使用 AES-EAX 或 AES-CCM 之類的東西，或者取決於可能的 AES- GCM基準。（範例：一些具有更好晶片的物聯網設備）
- **執行時受限（帶 AES 和無進位乘法硬體）**在這種情況下，您可能只會選擇 AES-GCM（因為操作的兩個部分都完全加速），除非您有一些更奇特的要求，例如加密大量數據或其他一些約束（例如沒有消息擴展）。
更具體地說：您可能更喜歡 AES-Poly1305 而不是 AES-GCM 的唯一情況是，如果您沒有用於無進位乘法的硬體加速，但即便如此，標準合規性可能比您獲得的速度更有價值在 AES-GCM 上使用 AES-Poly。如果您沒有 AES 加速，則通常沒有理由選擇 AES-Poly1305，而不是像 CCM 或 EAX 這樣的僅 AES 模式或像 ChaCha-Poly1305 這樣的一些 32 位優化密碼。