Encryption

為什麼 Encrypt-Then-Sign 不會產生 CCA 安全的公鑰加密方案?

  • June 19, 2020

在對稱密碼學中,將 IND-CPA 安全對稱加密方案與安全 MAC 與 encrypt-then-MAC 方法相結合產生 IND-CCA 安全對稱加密方案。

我試圖理解為什麼這在不對稱情況下不成立。假設您有一個 IND-CPA 安全公鑰加密方案和一個 EUF-CMA(或 sEUF-CMA)安全簽名方案。當您通過 encrypt-then-sign 組合它們時,生成的方案不是 CCA 安全的。

我知道這個網站上有一些相關的問題(例如這個這個)。所以我明白問題在於,當 Alice 向 Bob 發送消息時,Mallory 可以攔截它,刪除簽名,用她自己的簽名再次簽名並將其轉發給 Bob。然後 Bob 成功驗證並解密了密文並獲得了消息,認為它來自 Mallory(因為它具有來自 Mallory 的有效簽名)。

但是為什麼這意味著它不是 IND-CCA 安全的呢?對手如何利用這一特性贏得 IND-CCA 安全實驗?

到目前為止我自己的想法:我不確定這種情況下的 IND-CCA 實驗是如何工作的。我假設所有密鑰都由挑戰者固定,而對手只獲得公共加密密鑰和公共驗證密鑰。這個假設正確嗎?因為在這種情況下,我看不到 Mallory 的上述攻擊如何幫助對手——因為所有密鑰都是固定的。

附錄:加密然後簽名是如何工作的(或者至少我理解它是如何工作的):

  1. 假設每個人都有一個加密密鑰對和一個簽名密鑰對
  2. 要加密消息,您首先獲取收件人的公共加密密鑰並用它加密您的消息。然後,您使用自己的秘密簽名密鑰並對密文進行簽名。
  3. 然後將最終密文(由簽名和實際密文組成)發送給收件人。
  4. 接收者使用他的秘密解密密鑰和發送者公共驗證密鑰解密密文。首先驗證簽名,然後解密密文。

我不確定在這種情況下 IND-CCA 實驗是如何工作的。

嗯,它不是真的。在 CCA 實驗中沒有指定驗證密鑰,在公鑰加密方案的定義中根本沒有指定發送者。

因此,與據稱加密密文的接收者進行通信的唯一方法是將其放入密文本身。但是,加密過程僅將加密密鑰和消息作為輸入。那麼簽名密鑰從哪裡來?

答案是:要麼它需要是一個輸入,在這種情況下,你所擁有的甚至不再是語法上的加密方案,或者你可以在每次加密時生成一個新的密鑰對。但是由於這些不會綁定到任何東西,所以這將是無用的。

對手如何利用這一特性贏得 IND-CCA 安全實驗?

選擇兩條任意消息 $ m_0\neq m_1 $ 並將它們作為挑戰輸出。接收挑戰密文 $ C^* = (c^,\sigma) $ 在哪裡 $ \sigma $ 是一個簽名 $ c^ $ 在一些我們將不得不假設接收者神奇地知道的關鍵下。生成新的密鑰對,簽名 $ c^* $ 再次,導致 $ \sigma’ $ 並要求挑戰者解密 $ C’=(c^,\sigma’) $ . 自從 $ \sigma’ $ 是有效的,因此 $ C’ \neq C^ $ 與我們將收到的攻擊者誠實生成的密文相同地分發 $ m_b $ ,從而破壞 CCA 安全性。

引用自:https://crypto.stackexchange.com/questions/81436