摘要：很多安全規範及安全文章中都提到一條規則：先加密後簽名是不安全的，應當先簽名後加密。這條規則背後的原理是什麼？先加密後簽名一定不安全嗎？本文為您一一解答。先簽名後加密是指先對訊息進行簽名，然後對訊息的簽名值和訊息一起進行加密。如果採用先加密後簽名的方式，接收方只能知道該訊息是由簽名者傳送過來的，但並不能確定簽名者是否是該訊息的建立者。比如在傳送乙個認證憑據時採用先加密後簽名的方式，訊息在傳送過程中就有可能被第三方截獲並將認證憑據密文的簽名值修改為自己的簽名，然後傳送給接收方。第三方就有可能在不需知道認證憑據的情況下通過這種方式來通過認證獲取許可權。
採用先簽名後加密方式可以避免這類問題的發生，因為只有在知道訊息明文的情況下才能對其進行簽名。
雖然不同的規範描述有差異，但核心觀點都是「先簽名後加密」。但是這條規範的適用場景是什麼呢，「先加密後簽名」一定不安全嗎？需要深挖一下。
如果使用「先加密後簽名」，則訊息傳送方alice和訊息接收方bob的處理過程如下圖：
alice傳送的明文訊息先經過alice私鑰簽名，再將訊息明文和訊息簽名一起使用bob的公鑰加密，密文經過網路傳輸到bob。因為bob使用私鑰解密還原出訊息明文和簽名，而私鑰只有bob持有，這能保證訊息明文不會洩露給第三方eve，然後bob使用alice的公鑰驗證訊息明文和簽名是否一致，因為alice的簽名只有alice的公鑰才能驗證，這能保證訊息一定來自alice，不可抵賴，且沒有被第三方mallory篡改。在拿不到訊息明文的情況下，無法計算出訊息簽名，而還原訊息明文又必須使用bob的私鑰，這樣就能防止網路傳輸過程中的中間人進行篡改攻擊。
假如「先加密後簽名」，會存在什麼樣的攻擊風險呢，先看下「先加密後簽名」的處理流程：
訊息明文使用bob的公鑰加密，不可能洩露給第三方，簽名也有了，可以防篡改，不仔細看的話，似乎沒什麼問題。繼續看下面這張圖：
如果存在乙個中間人mallory可以攔截alice和bob的訊息，在不篡改訊息明文和密文的情況下，使用mallory的私鑰對訊息密文進行簽名，並替換alice原始的簽名，最後篡改後的訊息傳輸給接收方bob，bob仍然可以成功解密明文，同時用mallory的公鑰成功驗證簽名，最終這條訊息會被bob認為是mallory傳送的合法訊息。
從上面的演示來看，「先加密後簽名」似乎一定不安全，是這樣嗎？中間人mallory針對「先加密後簽名」進行替換簽名攻擊得手的前提條件：
1、 接收方bob根據簽名內容中的證書id找到對應的mallory公鑰來驗證簽名。
2、 接收方bob僅使用公鑰驗簽來識別傳送方的身份。
只要打破上面的任意乙個前提，「先加密後簽名」也是安全的：
1、 bob使用固定的公鑰來驗證簽名，而不是根據簽名內容來找對應公鑰，或者不使用多個公鑰嘗試驗籤。即mallory替換簽名後，bob仍然用alice的公鑰驗證簽名，肯定能發現請求被篡改。
2、 bob使用公鑰+應用層屬性一起識別傳送方的身份，假設alice在訊息明文中攜帶自己的使用者id，bob驗證公鑰和使用者id是否匹配，即使mallory替換簽名也無法攻擊。
所以「先加密後簽名」是不是安全，還要看業務應用是怎麼設計的，不能絕對的認定為不安全。
點選關注，第一時間了解華為雲新鮮技術~
資訊保安 加密 摘要 簽名
保密性 完整性可用性 不可抵賴性 加密摘要 數字簽名 常見加密演算法 aes 高階加密標準rijndael加密法 rc 5 idea 128位秘鑰 64位資料塊 比des的加密性好，對計算機功能要求低 優點 加密快 缺點 加密強度低，秘鑰分發困難 使用場景 常見非對稱加密方式 優點 加密強度高 缺點...
安全之道 加密與數字簽名
鍾峰 2004年10月 版本 1.0.0 本指南介紹為基於 microsoft 的多層應用程式設計和編寫由應用程式管理的安全和數字簽名的指導原則，主要討論常見的安全任務和方案，並提供相應的資訊幫助您選擇最佳方法和技術。本指南適用於體系結構設計人員和開發人員。本指南假定讀者已經了解 xml web s...
判斷轉換後的字串是不是實數
cstring轉換成float後並沒有內建的函式判斷是否轉換成功，如果沒轉換成功，沒有提示，就進行下一步運算，肯定有錯誤！尤其是要把輸入的資料寫入到資料庫中，沒有判斷就坑了。因此小馬寫乙個判斷轉換成浮點數是否成功的函式 以下程式基於mfc dlg update id number 是我定義的類名 b...