了解混合密碼學的概念：簽名和 CA
在學習了對稱加密、公鑰加密、單向散列、數字簽名和數字證書之後，我的任務是想出一個虛構的混合密碼系統。我是這樣思考的：
- Alice 和 Bob 就用於加密（使用 AES 等加密算法）消息的共享私鑰達成一致
- 為了達成私鑰協議，Alice 和 Bob 將使用 DH
- Alice 現在想將消息p發送給 Bob
- 為了確保 Bob 可以驗證消息p來自 Alice，Alice 將對消息p進行簽名。
- 因為簽名需要更多資源，並且通常只能對長度有限的消息進行簽名，所以 Alice 將首先散列（比如使用 SHA-1），然後將消息p散列到名為md1的消息摘要中。消息摘要md1然後由 Alice 簽名（使用一些簽名算法，如 RSA）。這個消息摘要md1現在包含一個數字簽名，將被稱為s
- 然後，Alice 將使用 DH 期間商定的私鑰使用加密算法（例如 AES）對原始消息p和簽名消息摘要***s進行加密，然後發送它們。***Alice 還發送有關驗證簽名的所需資訊。
現在消息發送過程完成。輪到 Bob 接收發送的包裹：
- Bob 將收到並加密原始消息p和簽名消息摘要s
- 使用 RSA，Bob 可以將簽名的消息摘要s轉換回消息摘要md2
- 為了驗證消息沒有在中途被篡改，Bob 現在將使用與發送的原始消息p相同的散列算法（在本例中為 SHA-1）進行散列，以創建另一個md3
- Bob 然後檢查md3和md2是否相同。如果是，它們來自愛麗絲。如果不是，Bob 將忽略此消息
- Bob 現在已收到原始消息
我正在按照上述構想進行思考，但有些觀點超出了我的腦海。
問題：
- Bob 神奇地知道使用的算法是 SHA-1、RSA 和 AES。Alice 和 Bob 在整個過程中使用的算法如何達成一致？
- 當我進行散列和簽名時，我同時提供完整性和身份驗證。如果我想提供這兩個方面，這兩個過程是不可分割的嗎？我假設由於效率問題（如上所述），您總是簽署消息摘要，這是正確的嗎？
- DH 的第一步是交換 Alice 和 Bob 生成的公鑰。為此，他們需要就初始大素數pn及其素數生成器g達成一致。然後，我將發送雙方生成的公鑰。但是，由於我將交換消息，我怎麼知道約定的pn和g沒有被他人篡改，並且雙方發送的公鑰確實來自自己而不是攻擊者？我需要簽署這些資訊交換嗎？
- 正如您在我的範例中所看到的，我未能將 CA 納入我想像的混合密碼系統中。據我了解，CA 將驗證消息確實來自公司/個人。為了驗證消息來自一側，CA 將看到與消息一起發送的數字證書。但是，當我可以自己簽名消息並要求接收者驗證簽名消息時，為什麼我需要讓 CA 參與？為什麼要涉及第三方？
你混淆了很多東西：
Alice 和 Bob 就用於加密的共享私鑰達成一致
您不能擁有“共享私鑰”；共享和保持私密是相反的術語。這將被稱為密鑰，因為它在 Alice 和 Bob 之間是保密的（有些書也混淆了這些術語，但是是的）。
為了達成私鑰協議，Alice 和 Bob 將使用 DH
好的，第一個語句應該在第二個語句之後。是的，密鑰協議或建立。
確保 Bob 可以驗證消息 $ p $ 來自愛麗絲，愛麗絲將簽署消息 $ p $ .
用什麼鑰匙？您已使用 DH 使用密鑰協議，並且您已指定使用密鑰進行加密。
因為簽名需要更多的資源並且通常只能對長度有限的消息進行簽名，所以 Alice 將首先散列（比如使用 SHA-1）然後消息 $ p $ 到一個名為的消息摘要 $ \mathit{md1} $ .
散列通常是簽名生成和驗證操作的一部分。
使用加密算法（比如 AES）對它們進行加密
AES 是一種分組密碼，它不是處理任何大小消息的通用密碼，它本身也不是 CPA 安全的。這很重要，因為如果您使用 AES CBC，它可能無法在您決定檢查簽名之前填充 oracle 攻擊。這是例如早期 TLS 協議的錯誤之一（嗯，直到 1.2，所以這不是遙遠的過去或任何東西）。
使用 RSA，Bob 可以轉換簽名的消息摘要 $ s $ 返回消息摘要 $ \mathit{md2} $ .
沒有規定檢索和比較雜湊是簽名方案驗證過程的一部分。重新計算雜湊當然是必要的，但驗證過程可能有不同的方法來確保雜湊相同。
- Bob 神奇地知道使用的算法是 SHA-1、RSA 和 AES。Alice 和 Bob 在整個過程中使用的算法如何達成一致？
他們事先就同意了。算法可能是靜態的，取決於單個版本號，或者是在握手期間建立的（a la TLS）。
2a。當我進行散列和簽名時，我同時提供完整性和身份驗證。如果我想提供這兩個方面，這兩個過程是不可分割的嗎？
這些過程並非不可分割，但它們通常相互關聯。除非你明確地想出一種方法來解開它們，否則你可能兩者都可以。
2b。我假設由於效率問題（如上所述），您總是簽署消息摘要，這是正確的嗎？
這取決於您通常使用經過身份驗證的密碼或 MAC 來提供消息完整性/真實性。那些可能根本不使用雜湊。
- DH 的第一步是交換 Alice 和 Bob 生成的公鑰。為此，他們需要就一個初始的大素數達成一致 $ \mathit{pn} $ 及其主要生成器 $ g $ . 然後，我將發送雙方生成的公鑰。但是，由於我將交換消息，我怎麼知道同意的 $ \mathit{pn} $ 和 $ g $ 沒有被他人篡改，雙方發送的公鑰確實來自自己，而不是攻擊者？我需要簽署這些資訊交換嗎？
這不是絕對必要的，因為使用不同的值會導致無效的秘密。這樣做很有意義：
- 在驗證消息之前驗證DH 是否成功。雖然不是嚴格要求，但它可以讓您更好地區分損壞的密鑰建立和損壞的消息。
- 在上述驗證中包含參數或參數名稱。
- 對於特定協議（具有 P-xxx 或 Brainpool 素數曲線的 ECDH）檢查公鑰的有效性。
但請注意，如果您使用預先確定的參數，攻擊者可能一開始就沒有攻擊向量。這取決於您的協議。
4a。正如您在我的範例中所看到的，我未能將 CA 納入我想像的混合密碼系統中。
您也未能定義用於簽名/驗證的密鑰對，因此這不足為奇。
4b。據我了解，CA 將驗證消息確實來自公司/個人。為了驗證消息來自一側，CA 將看到與消息一起發送的數字證書。
不正確。CA 用於建立對所使用證書的信任，其中包含用於簽名驗證（或在其他協議中為加密）的公鑰。CA 根本不參與傳輸協議，除了可能在建立連接時驗證證書仍然有效（CRL / OCSP）。
4c。但是，當我可以自己簽署消息並要求接收者驗證簽名消息時，為什麼我需要讓 CA 參與？為什麼要涉及第三方？
CA 僅參與讓接收者信任您證書的公鑰。如果您可以使用帶外程序來信任公鑰/證書，那麼您就不需要 CA（例如，在這種情況下，您可以使用自簽名證書）。
你離定義自己的安全傳輸協議還有很長的路要走。要麼您應該遵循加密課程並進行大量練習，要麼您應該使用現有的協議，例如 TLS。