是否所有 AEAD 實現在實踐中都使用對稱密鑰密碼？
到目前為止，我在現代實現（Linux Kernel AEAD API、JVM 加密提供程序 (AES-GCM)、RFC 8439、libsodium等）中看到的一切似乎都暗示在實踐中只使用對稱密鑰塊密碼用於 AEAD。是否有確保經過身份驗證的加密的非對稱密鑰算法？
當人們說“AEAD”時，他們想到的是對稱方案。但從概念上講，經過身份驗證的加密並不局限於對稱密鑰。只是公鑰變體在文獻和實踐中都沒有受到太多關注。但是有實現。例如，NaCl 有一個用於公鑰認證加密的 API，基於Jee Hea An 2001的安全概念。該結構基於公鑰加密和 MAC。這表明非對稱設置中的 AE 與簡單地簽署加密消息有根本的不同，如 NaCL API 文件中所述：
crypto_box 函式並不意味著提供不可否認性。相反：crypto_box 函式保證了可否認性。接收者可以隨意修改裝箱的消息，因此無法說服第三方該特定消息來自發送者。然而，發送者和接收者受到保護，免受其他方的偽造。在https://groups.google.com/group/sci.crypt/msg/ec5c18b23b11d82c的術語中，crypto_box 使用“公鑰驗證器”而不是“公鑰簽名”。
想要公共可驗證性（或接收者輔助的公共可驗證性）的使用者應改為使用簽名（或簽密）。
顯然，此 API 和論文中的形式化不包括 AEAD 的“附加數據”（AD）部分，但我認為沒有基本限制。AEAD 作為對稱設置中的單一原語直到 2001 年才開始流行，所以我相信 Jee Hea An 在 2001 年根本沒有考慮將“附加數據”作為有用的功能。
我只能推測，但我相信經過身份驗證的公鑰加密沒有受到太多關注的一個原因是（即使是未經身份驗證的）公鑰加密本身是一種很少使用的原語。公鑰加密在發送方和接收方不同時線上的設置中很有用。突出的例子是電子郵件加密，但不幸的是，電子郵件加密由於各種原因從未起飛（Johnny Still, Still Can’t Encrypt)，以及諸如 PGP/GPG 和 S/MIME 等電子郵件安全協議在概念上將機密性和身份驗證分開，並通過公鑰加密和數字簽名（而不是 MAC！）來實現它們。當然，這些可以組合起來（“sign-then-encrypt”、“encrypt-then-sign”或“encrypt-and-sign”），但正確執行此操作的責任主要由使用者承擔，而 2001 年的論文表明所有這些結構都是不夠的。（PGP 和 S/MIME 明確需要簽名的一個原因是您仍然可以對公共電子郵件進行身份驗證，例如，發佈到公共郵件列表。）
我們應該將經過身份驗證的加密視為具有單個防誤用 API 的單一原語，其使用者無需成為密碼學專家的想法的成功出現在對稱設置的後期，因為人們以無窮無盡的方式搞砸了“加密- then-MAC”、“MAC-then-encrypt”、“encrypt-and-MAC”，它們是上述模式的對稱對應物。但是請注意，在身份驗證方面，對稱和非對稱設置很難比較，例如，由於提到的可否認性和公開可驗證性的微妙之處。MAC 和簽名是非常不同的野獸。