不同的加密標準以及它們與身份驗證和算法的關係
我的主要困惑是圍繞不同的 PKCS 以及與 SSL (TLS) 的關係。我做了很多研究，發現了一些零碎的東西，但不一定是它們之間的關係，所以讓我解釋一下，但首先要有一點背景。
首先，我對 SSL（以及隨後的 TLS）的工作方式以及隨後的雙向 TLS 非常滿意。通常使用 CA 簽名的 X.509 證書用於相互身份驗證，有時使用自簽名證書。以及如何使用對稱密鑰進行內容加密以及如何使用非對稱密鑰加密對稱密鑰。
我對 PGP、加密、簽名、不同算法、內置 zip 壓縮等功能也相當熟悉。對RSA 加密和簽名算法特別感興趣，但稍後會詳細介紹。因此，到目前為止，我們擁有 SSL，如果您在使用傳輸級加密之前加密有效負載，則可以增強其安全性，特別是如果您將數據發送到您不希望任何靜態數據未加密的地方。
現在到 PKCS，它開始變得有點朦朧。我知道PKCS只是標準。
PKCS#12 - 這些是您的.pfx 或 .p12文件，可用於儲存您的 X.509 證書和相應的私鑰（非常簡單的定義）。我的猜測，如果我錯了，請糾正我，這些通常是創建一個想要設置 HTTPS 的伺服器。可以使用不同的算法，例如 PGP 中也提到的 RSA。
PKCS#7 - 隨後的CMS，通常用於生成和驗證數字簽名。這是我發現一些相互矛盾的資訊的地方。我了解
digital signatures，使用私鑰計算雜湊加密，以便您可以使用公鑰驗證消息未被篡改並且來自正確的發件人。在談到與身份驗證相關的主要問題之前，我看到 PKCS#7 可以使用 AES，這是一種對稱密鑰算法。這有意義嗎？如果是這樣，這很常見還是如何運作？現在主要問題很抱歉，如果那是冗長的。
- 有人告訴我下載 PFX 文件以使用 API 進行身份驗證，類似於這個問題。關於這個的問題，與我關於 PKCS7 的下一個問題有關，該身份驗證是如何工作的？我從伺服器以文件的形式獲取私鑰和證書，
.pfx這是否意味著伺服器只是自簽名，這本質上是使用自簽名證書的雙向 TLS？如果不是，那麼我們只是使用 TLS（使用伺服器公鑰加密），消息內容是我們的有效負載，使用我們的私鑰簽名？- PKCS7 類似。我完全理解我們如何使用公鑰驗證簽名。如果我們將數據發送到某個 API（通常來說），我們如何處理身份驗證？因為從技術上講，一旦我們擁有具有數字簽名的東西，實際上任何地方的任何人都可以發送它，所以我們怎麼知道它是由特定客戶發送的，還是我們不在乎？
很抱歉這篇長文，希望你能幫我解決一些問題。
PKCS#7 - 隨後的 CMS，通常用於生成和驗證數字簽名。
我不會去那裡“通常”。目前 PKCS7/CMS 主要有以下三種用途：
- 從 Java 或 Windows 程式碼到 PDF 文件的各種數據的簽名
- S/MIME 中郵件消息或附件的簽名和/或加密
- 作為證書和/或 CRL 的容器，如您為 PKCS12（以及其他）連結的 Q 中所述
我沒有數字，我會接受第一個可能更常見，但其他存在。
我了解數字簽名，計算雜湊
$$ and $$使用私鑰加密，這樣您就可以使用公鑰驗證消息沒有被篡改並且來自正確的發件人。
不，這是一個經常重複的錯誤，但簽名不是“使用私鑰加密”或“反向加密”。僅對於 RSA，而不是其他算法，存在 30 年前的數學相似性導致人們使用這種描述，但實際的簽名和加密方案截然不同，更重要的是語義上不同，所以有見識的人不再這麼說. 在https://security.stackexchange.com/questions/159282/can-openssl-decrypt-the-encrypted-signature-in-an-amazon-alexa-request-#159289上查看我不斷增長的 Qs 或 As 列表。與此處相關，比較任何 CMS，甚至最早在 1999 年其中說 SignerInfo.signature “是數字簽名生成的結果，使用消息摘要和簽名者的私鑰”，並將簽名生成和驗證定義為分別使用私鑰和公鑰，否則將它們留給其他標準，而不是實際的 PKCS7v1。 5由 IETF 在 1998 年重新分發，但實際上由當時的 RSALabs 在 1993 年發布，其中說 SignerInfo.encryptedDigest “是使用簽名者的私鑰加密消息摘要和相關資訊的結果”，並且在 9.4 中基本上複製了當時的一部分- PKCS1 的目前版本。
確實，數字簽名允許驗證者確定數據未被篡改並且“來自”（或至少被持有私鑰的一方看到/批准），這應該是唯一的（更多下文），並且可以（至少嘗試）根據與該正確性相關的任何標準來驗證簽名者是“正確的”發件人。
我看到 PKCS#7 可以使用 AES，這是一種對稱密鑰算法。這有意義嗎？如果是這樣，這很常見還是如何運作？
僅適用於“封裝”（即加密）消息，不適用於簽名消息或分離簽名；正如我上面所說，我沒有使用數字。
有人告訴我下載 PFX 文件以使用 API 進行身份驗證，類似於 (link) …該身份驗證如何工作？我從伺服器獲取 .pfx 文件形式的私鑰和證書，這是否意味著伺服器只是自簽名，這本質上是使用自簽名證書的雙向 TLS？如果不是，那麼我們只是使用 TLS（使用伺服器公鑰加密），消息內容是我們的有效負載，使用我們的私鑰簽名？
這很可能是帶有客戶端身份驗證的 TLS，也稱為相互身份驗證或只是相互 TLS，是的。證書必須是您連接的伺服器信任的證書；這可以由伺服器自簽名，它可以由充當 CA 的伺服器簽名，或者可以從簽署它的某個其他 CA 獲得。只要結果是可信的，這對您來說並不重要，儘管如果您好奇，您可以使用可以查看 PKCS12/PFX 或從其中提取的一個或多個證書的許多工具中的任何一種來查看證書.
TLS 從不使用伺服器的公鑰加密數據。TLS 使用對稱算法在兩個方向上加密和驗證數據，每個會話（和連接）“工作”密鑰是在初始握手期間由“密鑰交換”過程創建的。請參閱例如https://security.stackexchange.com/questions/20803/how-does-ssl-work/以獲得廣泛但略微過時的解釋 - 它尚未更新（尚未？）TLS 1.3於 2018 年發布，現在變得越來越普遍。最古老且現在大多已過時的密鑰交換，稱為“靜態”或“普通”RSA，確實使用伺服器公鑰加密預主密鑰，但較新的密鑰交換（特別是在 1.3 中）使用 Diffie-Hellman簽名通過伺服器私鑰並由客戶端使用伺服器公鑰驗證（來自其證書，在驗證後）。相反，TLS 中的客戶端身份驗證始終使用客戶端私鑰對握手數據進行簽名，並由伺服器使用客戶端公鑰進行驗證（同上）。
PKCS7 類似。我完全理解我們如何使用公鑰驗證簽名。如果我們將數據發送到某個 API（通常來說），我們如何處理身份驗證？因為從技術上講，一旦我們擁有具有數字簽名的東西，實際上任何地方的任何人都可以發送它，所以我們怎麼知道它是由特定客戶發送的，還是我們不在乎？
創建將成功驗證的數字簽名需要使用私鑰，而公鑰密碼學的整個概念是只有“所有者”擁有私鑰；其他人應該只有公鑰。因此，如果特定密鑰屬於客戶端 X，則只有客戶端 X 可以使用該密鑰創建簽名。但是，在您的範例中，伺服器顯然會隨意傳遞包含私鑰的 PKCS12，這不被認為是好的做法，這種保證被大大削弱：對於該伺服器和任何其他獲得“你的’ PKCS12 從“你”偽造數據（在本例中為連接）。雖然如果你的連接是在同一台伺服器上，它建立連接的能力並不重要，因為它可以很容易地謊報在合法連接上收到的內容。