我需要使用帶有非對稱加密的 MAC 嗎？
網際網路讓我明白，當我傳遞任何對稱加密的數據時，我還應該傳遞一個 MAC 以在任何解密發生之前對其進行身份驗證。如果我使用非對稱加密，我是否也需要這樣做？如果是這樣，正確的機制是什麼？
到目前為止，我使用的正常模式是使用與 MAC 加密相同的對稱密鑰。像這樣的東西：
// Alice ciphertext = aes_encrypt(plaintext, aes_key, iv) mac = hmac_sha(ciphertext + iv, aes_key) // Bob verify_hmac_sha(ciphertext + iv, aes_key, alice_mac) plaintext = aes_decrypt(ciphertext, aes_key, iv)現在，如果我用非對稱算法替換加密，我會立即遇到雙方之間沒有預先共享的對稱密鑰的麻煩。將非對稱密鑰對的公鑰用於 HMAC 密鑰似乎很荒謬，因為它顯然是公開的，任何人都可以偽造 MAC。
然而，假設 Bob 也知道 Alice 的公鑰，Alice 可以簡單地使用適當的非對稱簽名算法對發送的數據進行簽名。對我來說，這似乎等同於使用 MAC。
我的理解正確嗎？此外，需要具有對稱加密的 MAC 的漏洞是否會影響非對稱加密？
是的，（非對稱）encrypt-then-sign 將提供與（對稱）encrypt-then-mac 相同的屬性。它將提供密文的完整性和真實性。
但是，如果使用 encrypt-then-sign ，則其他人可以重新簽署加密消息。當在同一網路中信任其他方時，這是一個問題。還要注意，如果另一方創建密文，它不一定提供明文的完整性和真實性。由於這個原因，通常使用先加密而不是先加密。
請注意，這意味著密文解密發生在簽名驗證之前；這意味著對密文的一些攻擊可能是可能的——例如在完全執行簽名驗證之前對消息上的任何操作進行填充預言攻擊和明文預言攻擊。出於這個原因，確保您的非對稱加密常式不受這些攻擊可能是一個好主意。如果也使用對稱加密（混合密碼系統），那麼使用身份驗證模式可能仍然有意義。
由於對稱和非對稱加密的案例會有所不同，因此在如何實現 encrypt-then-sign 方面存在差異。最重要的區別當然是，雖然在對稱加密的情況下會話密鑰由雙方保存。對於非對稱加密，用於簽名的私鑰通常與用於解密的私鑰不同（如果涉及多方）。一方的私鑰將用於簽名生成和解密，而公鑰將用於簽名驗證和解密。所以你會有一個完全不同的密鑰管理方案。
對對稱塊操作模式的攻擊（例如填充預言攻擊）不會直接轉化為對非對稱原語的攻擊。但通常可以發現相同類型的問題。例如，針對加密的 PKCS#1 v1.5 編碼存在填充預言機攻擊（Bleichenbacher 攻擊）。因此，儘管不相同，但可能會出現相同類型的問題。
對於非對稱加密，通常定義混合密碼系統。您可以一起使案例如 RSA OAEP 和經過身份驗證的對稱密碼來維護機密性和完整性。在這種情況下，可能不需要簽名來維護完整性和機密性。當然，您仍然需要簽名以確保真實性。此構造可用於先簽名後加密（如本答案第二部分所述）。
請注意，使用 PKCS#1 v1.5 填充和/或 CBC 操作模式可能容易受到明文和填充 oracle 攻擊，因此您不想使用這些算法進行簽名然後加密，除非您確定那些某種攻擊是不可行的（通常在使用文件加密等加密/解密時）。
然而，假設 Bob 也知道 Alice 的公鑰，Alice 可以簡單地使用適當的非對稱簽名算法對發送的數據進行簽名。對我來說，這似乎等同於使用 MAC。我的理解正確嗎？
這是。Bob 不僅需要知道公鑰，他還需要信任公鑰。但這假設您只接受由一個私鑰生成的簽名。
此外，需要具有對稱加密的 MAC 的漏洞是否會影響非對稱加密？
是的，他們可能會。但這種說法過於寬泛，無法用是或否來回答。對對稱和非對稱原語肯定有不同的攻擊（不容易從一個系統轉換到另一個系統）。