一、密碼(clpher)

• 是一種用于加密或者解密的算法

密碼學中的密碼（cipher）和我們日常生活中所說的密碼不太一樣，計算機術語『密碼 cipher』是一種用于加密或者解密的算法，而我們日常所使用的『密碼 password』是一種口令，它是用于認證用途的一組文本字符串，這里我們要討論的是前者：cipher。

二、密鑰(key)

• 密鑰是一種參數，它是在使用密碼（cipher）算法過程中輸入的參數。
• 密文 = 密碼(密鑰，明文) 或者 密文 = 加密函數(密鑰，明文)
• 密鑰是決定密文是否安全的重要參數，通常密鑰越長，破解的難度越大，越安全。
• 密鑰分為對稱密鑰與非對稱密鑰。

密鑰是一種參數，它是在使用密碼（cipher）算法過程中輸入的參數。同一個明文在相同的密碼算法和不同的密鑰計算下會產生不同的密文。很多知名的密碼算法都是公開的，密鑰才是決定密文是否安全的重要參數，通常密鑰越長，破解的難度越大，比如一個8位的密鑰最多有256種情況，使用窮舉法，能非常輕易的破解，知名的DES算法使用56位的密鑰，目前已經不是一種安全的加密算法了，主要還是因為56位的密鑰太短，在數小時內就可以被破解。密鑰分為對稱密鑰與非對稱密鑰。

三、明文/密文

• 明文（plaintext）：加密之前的原始數據。
• 密文（ciphertext）：是通過密碼運算后得到的結果。

四、對稱密鑰(Symmetric-key algorithm)

• 又稱為共享密鑰加密。（通訊的兩端共享）
• 對稱是指：加密和解密的過程中使用的密鑰相同。
• 需要在通訊的兩端共享，讓彼此知道密鑰是什么對方才能正確解密。
• 計算速度快，但是不安全。?密文 = 密碼(密鑰，明文) ，知道了密文，密鑰和密碼，就可推出明文數據
• 如果每個客戶端與服務端單獨維護一個密鑰，那么服務端需要管理的密鑰將是成千上萬，這會給服務端帶來噩夢
• 常見的對稱加密算法：DES、3DES、AES、RC5、RC6
• 采用更復雜的密鑰管理和交換協議，如公鑰基礎設施（PKI）和密鑰分發中心（KDC），來提高系統的安全性。

五、非對稱密鑰(public-key cryptography)

• 又稱為公開密鑰加密
• 服務端生成一對密鑰，私鑰與公鑰
• 私鑰保存在服務端，公鑰發布出去，供任何人使用
• 加密：密文 =? 密碼（明文，公鑰）==解密==>? ?明文 = 密碼（密文，私鑰）
• 公鑰加密，私鑰解密
• 客戶端：公鑰加密明文得到密文傳輸給服務端
• 服務端：私鑰解密密文得到明文

六、數字簽名

• 驗證傳輸的數據是不是真實數據
• 防止傳輸的數據被篡改或者被調包
• 是非對稱加密的一種應用場景，不過是反過來的，用私鑰來加密，通過與之配對的公鑰來解密。

過程梳理：

第一階段：創建并發送簽名

• 生成摘要：服務器先使用SHA-256哈希算法對原始報文進行處理，產生一個唯一的摘要信息（Digest）。這一步確保了任何對報文的微小改動都會導致摘要不同。

• 簽名生成：接著，服務器利用自己的私鑰對生成的摘要信息（Digest）進行加密，形成數字簽名。這一操作基于非對稱加密技術，確保了只有對應的公鑰能夠驗證簽名，從而證明報文來源的可靠性和完整性。

• 發送信息：服務器將原始報文和這個數字簽名一起發送給客戶端。注意，這里原始報文并未加密，而是明文發送，因為真正的安全在于簽名的驗證過程。

  • 摘要=hash(報文)

    數字簽名 = 密碼(摘要,私鑰)

    數字簽名 = 密碼(hash(報文),私鑰)

第二階段：驗證簽名與身份

• 接收數據：客戶端收到服務器發送的原始報文及簽名。

• 簽名驗證：客戶端使用服務器提供的公鑰嘗試解密接收到的數字簽名。如果解密成功，說明簽名確實是用對應的私鑰生成的，從而驗證了發送者的身份。同時，解密結果得到摘要信息（Digest1）。

  • 摘要 = 密碼(數字簽名，公鑰)

第三階段：驗證報文完整性

• 計算本地摘要：客戶端對收到的原始報文同樣應用SHA-256哈希算法，計算出一個新的摘要信息（Digest2）。

• 比對摘要：最后，客戶端比較從簽名解密得到的摘要（Digest1）與自己計算出的摘要（Digest2）。如果兩者完全相同，這表明報文在傳輸過程中未被篡改，內容完整可信。反之，如果摘要不匹配，則報文可能已被修改。

  • 摘要 = hash(報文)

七、數字證書（Certificate Authority）

????????權威機構給某網站頒發的認可憑證，確定服務器是真實的。

問題

舉例子：

????????A廠家給你們家安裝鎖，同時把鑰匙也交給你，只要鑰匙能打開鎖，你就可以確定鑰匙和鎖是配對的，如果有人把鑰匙換了或者把鎖換了，你是打不開門的，你就知道肯定被竊取了，但是如果有人把鎖和鑰匙替換成另一套表面看起來差不多的，但質量差很多的，雖然鑰匙和鎖配套，但是你卻不能確定這是否真的是A廠家給你的，那么這時候，你可以找質檢部門來檢驗一下，這套鎖是不是真的來自于A廠家，質檢部門是權威機構，他說的話是可以被公眾認可的。 ?

????????同樣的， 因為如果有人（張三）用自己的公鑰把真實服務器發送給瀏覽器的公鑰替換了，于是張三用自己的私鑰執行相同的步驟對文本Hash、數字簽名，最后得到的結果都沒什么問題，但事實上瀏覽器看到的東西卻不是真實服務器給的，而是被張三從里到外（公鑰到私鑰）換了一通

解決

? ? ? ? 如何保證你現在使用的公鑰就是真實服務器發給你的呢？

????????我們就用數字證書來解決這個問題。數字證書一般由數字證書認證機構（Certificate Authority）頒發，證書里面包含了真實服務器的公鑰和網站的一些其他信息，數字證書機構用自己的私鑰加密后發給瀏覽器，瀏覽器使用數字證書機構的公鑰解密后得到真實服務器的公鑰。這個過程是建立在被大家所認可的證書機構之上得到的公鑰，所以這是一種安全的方式。

? ? ? ? 機構私鑰：GS? ? 機構公鑰：GG

? ? ? ? 服務器公鑰：FG

? ? ? ? 實際上就是，在服務器分發公鑰FG給瀏覽器的時候，經過了一層機構的包裝，由機構用它自己的私鑰GS加密這個服務器給的公鑰FG信息，并會將對應的公鑰GG給到瀏覽器，瀏覽器通過這個公鑰GG解密得到公鑰FG。

八、數字簽名為什么要用私鑰加密公鑰解密？

數字簽名使用私鑰加密而公鑰解密的機制，其核心目的在于確保信息的完整性和來源的不可抵賴性

• 驗證發送方身份：私鑰只有簽名者本人持有，且應保持秘密。使用私鑰進行簽名意味著任何人都可以使用與之對應的公鑰來驗證簽名，但不能偽造簽名。這證明了信息確實出自持有對應私鑰的發送方，從而確認了發送者的身份。

• 保證數據完整性：數字簽名通常包括對原始消息的哈希值進行加密，而不是直接加密消息本身。這樣，接收方在用公鑰驗證簽名時，會重新計算消息的哈希并與解密后的簽名比較。如果兩者一致，說明消息在傳輸過程中未被篡改。

• 不可抵賴性：由于私鑰的私密性，一旦消息被私鑰簽名，發送方就不能否認他們曾經發送過該消息，因為除了他們自己，沒有人能生成有效的簽名。這提供了法律上的可接受證據，即發送方認可了消息內容。