公鑰私鑰

一、實驗目的

掌握產生公鑰金鑰對的程式設計方法

掌握產生公鑰加密/解密的程式設計方法

二、實驗場景

模擬實現 128 位資訊的加密通訊過程。

實驗物件包含三方：A，B，C。

其中，A 與 B 之間進行 128 位訊息的安全交換，這樣的資訊交換透過公鑰密碼演算法實現。

第三方 C 負責為 A 和 B 各生成一對公私鑰對，並分別把對應的私鑰傳給 A 和 B，並把他們的公鑰公開。

當 A 向 B 傳送訊息時，A 用 B 的公鑰加密，加密的資訊傳送給 B 後，B 再用自己的私鑰來解，從而獲得 A 發給 B 的訊息。

三、實驗步驟

0 實現 A，B，C 三方分別擁有的函式；定義公鑰體系環境配置；

1 編寫生成一對公鑰金鑰的程式；

2 生成實驗用的 128 位資訊；

3 設計生成對上述資訊的公鑰加密/解密的程式；

四、訊息傳遞及公鑰分發探索性步驟

設計客戶端-伺服器程式，實現 128 位訊息的傳遞，實現公鑰與私鑰的分發。

五、實驗思考

1 公鑰密碼演算法有哪些應用場合？

2 實際應用中，公鑰如何傳送及如何確定公鑰擁有者的身份？

說明：

1 程式語言任意

2 可以使用已有的公鑰密碼函式庫

實驗內容

1、本次實驗我採用的是socket程式設計，實現服務端與客戶端的互動。

C作為伺服器端，負責生成公私鑰對，將客戶端的公鑰公開，將私鑰傳遞給客戶端A和B。在這裡雖然把公鑰公開，但是這裡我還是進行了對公鑰進行了傳遞，以便後期A和B的互動。

C繫結localhost的埠，用listen函式開始監聽，運用accept函式接收客戶端傳送的訊息，分別與客戶端A，B建立聯絡。

服務端C生成公鑰與私鑰，

之後便是運用send函式傳送公鑰與私鑰。

在這次實驗中，對公鑰的傳輸過程中，一開始直接採用了str(publickey).encode(encoding=“utf-8”)，但是在這種情況下，傳輸後的公鑰卻沒有辦法用來加密，在這個過程中，一直出現一個bug，

後來我採用了pickle序列化的辦法，依舊是無法用公鑰加密，仍熱是以下這種情況：

最後我採用了pickle加上雜湊函式的辦法，在這種情況下，公鑰終於可以加密成功。我查詢了很多資料，關於為何會出現這種問題，始終沒有確定的答案。不過採用雜湊函式，保證了資料的完整性。

2、B負責接收C為B生成的公私鑰對，考慮到B要傳送公鑰給A，以及接收A的訊息，因此，B應該是C的客戶端，又是A的服務端。

因此設計的時候，我將B設計成兩個執行緒並行，我把B分為兩個部分：RecvData和Recvmsg。

RecvData作為C傳送公私鑰時，接收公私鑰的工具，同時為保證公鑰能傳送給A，以及解密資訊，需要將公鑰和私鑰設為全域性變數。

Recvmsg則是重新呼叫了socket程式，繫結埠，視為一個服務端，等待A的connect。當A與之建立連線之後，B傳遞自己的公鑰給A，等待A用公鑰加密的資訊傳送過來，之後B再用自己的私鑰進行解密。（紅框是解密過程）

3、客戶端A負責接收C傳來的自己擁有的公私鑰對，傳送資訊給B，接收B的公鑰，並用於加密。根據這個思路，A也是兩個執行緒並行，設定了兩個函式，分別是：Recvmsg（）， Sendmsg（）。

Recvmsg（），A作為C的一個客戶端，用於接收公私鑰對。（這裡思路與B一致）

Sendmsg（），此函式負責A與B互動，A作為B的客戶端，接收B發過來的公鑰，運用B的公鑰進行加密，向B傳送加了密的資訊。（第二個紅框是加密過程）

這裡生成128位訊息，運用了os庫，生成16byte的訊息，也就是128位。

4、執行截圖：

執行C程式後，再執行b和a的程式，C分別生成公鑰和私鑰，並向他們傳送。

B接收公鑰和私鑰後：

A接收公鑰和私鑰後：

B開始監聽，與A建立連線，並通訊：

A與B之間的通訊：

5、實驗與思考

（1）公鑰密碼演算法的應用：

①加密/解密：傳送方用接收方的公鑰對訊息加密。

②數字簽名：傳送方用自己的私鑰對訊息簽名。簽名可以透過對整條訊息加密或對訊息的小資料塊加密來生成，其中的小資料塊是整條訊息的函式。

③金鑰交換：通訊雙方交換會話金鑰。金鑰交換有幾種不同的方法，這些方法都使用通訊一方或雙方的私鑰。

（2） 公開金鑰系統需要一個值得信賴而且獨立的第三方機構充當認證中心(CA)，來確認聲稱擁有公開金鑰的人的真正身份。

要確認一個公共金鑰，CA首先製作一張“數字證書”，它包含使用者身份的部分資訊及使用者所持有的公開金鑰，然後CA利用本身的私鑰為數字證書加上數字簽名。

任何想發放自己公鑰的使用者，可以去認證中心(CA)申請自己的證書。CA中心在認證該人的真實身份後，頒發包含使用者公鑰的數字證書，它包含使用者的真實身份、並證實使用者公鑰的有效期和作用範圍(用於交換金鑰還是數字簽名)。其他使用者只要能驗證證書是真實的，並且信任頒發證書的CA，就可以確認使用者的公鑰。