我正在盡最大努力了解這是如何作業的。我讀了很多文章，但總是感到困惑。
根據我有限的理解，發送方和接收方都必須使用證書頒發機構提供的密鑰/證書安裝他們的客戶端。但是發送方和接收方的郵件客戶端如何使用這些證書呢？
這里有一個讓我困惑的具體例子，來自維基百科（https://en.wikipedia.org/wiki/S/MIME）：
While it is technically possible to send a message encrypted (using the destination party certificate) without having one's own certificate to digitally sign, in practice, [...]
因此，發件人郵件客戶端應該能夠使用收件人證書加密訊息。在實踐中，發件人郵件客戶端如何僅從收件人的郵件地址推斷收件人證書是什么？發件人和收件人的郵件客戶端是否相互“ping”并以某種方式交換此資訊？它是從電子郵件地址的域推斷出來的嗎？或者電子郵件客戶端的用戶是否希望事先交換這些資訊？
uj5u.com熱心網友回復：
你在問幾個問題。那可能是因為你很困惑。讓我試著整理一下。
用于加密目的
- 發送方使用接收方的公共密鑰（從收件人的公證書），以加密的電子郵件
- 收件人，然后使用自己的私有密鑰來解密電子郵件
用于簽署目的
- 發件人使用自己的私鑰對電子郵件進行簽名
- 收件人然后使用發件人的公開密鑰（從發件人的公開證書）來驗證簽名
交換公共證書
- Alice 向 Bob 發送一封簽名但未加密的電子郵件
- 簽名包括 Alice 的公共證書
- Bob 可以從郵件中提取 Alice 的公共證書
- Bob 信任 Alice 的證書，因為它是由受信任的機構簽署的 *)
- Bob 現在可以驗證包括證書在內的簽名
- Bob 現在可以向 Alice 發送加密的電子郵件
*) 每個作業系統都帶有大量預先信任的證書頒發機構
然后，Bob 在回復 Alice 時還通過在電子郵件上簽名來共享他自己的證書。之后，可以在兩個方向上進行加密。
其他
維基百科的引述涉及不同的方面：
如果 Alice 向 Bob 發送一封加密的電子郵件，Alice 使用 Bob 的公鑰來加密電子郵件，因此只有 Bob 可以解密它。但這也意味著 Alice 無法解密她自己的電子郵件（它存盤在她的“已發送”檔案夾中）！
將未加密的電子郵件存盤在 Alice 的“已發送”檔案夾中將是嚴重的安全漏洞，那么可以做些什么呢？電子郵件可以被加密兩種，收件人鮑勃以及發件人愛麗絲。
現在如何使用多個加密密鑰加密一封電子郵件？
電子郵件實際上并未使用 Bob 的密鑰加密，而是使用
- 選擇一個隨機密鑰來加密電子郵件內容
- 隨機密鑰用 Bob 的密鑰加密并添加到訊息中
- 隨機密鑰也用 Alice 的密鑰加密并添加到訊息中
然后解密，隨機密鑰用收件人的私鑰解密，然后電子郵件內容用解密的密鑰解密。
在這種情況下，隨機密鑰稱為“內容加密密鑰”或 CEK，而個人密鑰稱為“密鑰加密密鑰”或 KEK。
還有另一個使用 CEK 的原因——這與對稱加密比非對稱加密更快、更具可擴展性有關——但這是另一個故事，應該在另一個問題的答案中講述。
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/383256.html