所謂“先把厚書讀薄，再把薄書讀厚”。
本文采取舉例來講解加密算法以及如何與小姐姐進行安全通信。
對稱加密算法
場景： 有一天我在華科聽宣講會認識一個可愛的小姐姐，但是很快我回到了自己學校，卻很想給她寫信，但是寫信可能會出現信息安全問題，那個“可惡”的郵遞員恰了檸檬對我寫給小姐姐的信進行了消息僞造、修改、監聽等行爲。於是我想到了學過的“加密算法”。
這時候我將小姐姐比作服務端（Server），而我是客戶端（Client）
- 我先發送信息詢問小姐姐的公鑰
- 小姐姐告訴我她的公鑰是abcdfg
- 此時我創建一個PSK（用AES算法加密了這個公鑰），再用小姐姐的公鑰加密這個PSK發給了小姐姐
- 小姐姐收到這個信息，她用私鑰解開就知道了“我們現在要使用對稱加密算法了，私鑰是123456”.
在這個過程中郵遞員沒有直接接觸到小姐姐的私鑰，他就無法知道小姐姐最後看到的是什麼，
一旦我和小姐姐都知道了PSK就可以使用對稱加密算法了。
信息傳輸安全
例子1：《寫信》
在寫信的過程中，手是私鑰，寫出來的信是簽名後的數據，筆跡是公鑰
簽名後的數據可以被公開，但無法被僞造，因爲郵遞員無法控制我的手也模仿不出我的筆跡。
例子2：《說話》
在交流的過程中，聲帶是私鑰，說出來的內容是簽名後的數據，音色是公鑰
同樣所有人都可以聽到我的聲音，但是他們無法模仿我的音色。
數字簽名+CA認證
上面的問題引出了另一個問題，這個“簽名”由誰來籤？
HTTPS需要解決信任問題，解決信任問題需要“信任鏈”。
比如在一場校內聯誼，我突然站起來說“hello大家好計科班長Luvsta！”
可是到場的其他班不知道我是計科班長，但咱們班一個男生的兄弟是聯誼班的學生
他說：“你看！這是我們班長Luvsta！”
這個時候聯誼班的同學會說：“哇~這就是你們計科的班長！”
如何解決“信任鏈”問題呢？
以上案例就很好的解決了信任鏈問題，我信任計科班長Luvsta，我朋友信任我，所以我朋友也信任計科班長。
以下例子能解釋爲什麼需要“安全傳遞信息”
在現代互聯網中，人的真實身份和網絡身份是分離的，網上的人可能是一個一秒百行的“鍵盤俠”，可生活中可能是一個身高不足160體重不足80斤“柴火人”，他們之所以敢到處“噴人”是因爲在網絡中大家都是一個匿名的身份，大家所看到的僅僅是一個ID，這個ID和線下生活中的這個人沒有任何關係。
CA機構
例如Lets Encrypt、DigiCert、賽門鐵克都是熟知的CA機構，它們頒發的數字證書稱之爲“密鑰對”。證書由CA機構自己的私鑰簽發稱之爲“Private Key”。
通常我們使用谷歌的Chrome瀏覽器打開一個URL時，如果Chrome信任這家CA，這家CA認證了的網站URL，此時Chrome就知道你訪問的URL是可信任、安全、綠色的。
此時我們結合第一個寄信例子加入CA數字簽名後如何通信
同樣小姐姐是服務端（Server），我是客戶端（Client）
- 我詢問小姐姐的公鑰
- 小姐姐告訴我一個帶有CA簽名的公鑰
- 我接收到後比對簽名，驗證它的確是受信任的CA機構頒發的證書
- 此時我用公鑰加密了另一個私鑰PSK發給小姐姐
- 小姐姐用私鑰解密了PSK
- 這個時候我們都知道了PSK，用就對稱加密算法以PSK爲密鑰加密內容互相通信了
在這個過程中被分離的身份被拼接到了一起，似乎完美的解決了信息安全這個問題，我寫給小姐姐信不會被“邪惡”的郵遞員僞造、修改、監聽。
疑點解答
110這類機構是不是給接受方（客戶端）只提供公鑰，而發送方（服務器）提供公私鑰對？如果給多個小姐姐寫信，她們簽名後的公鑰是不是都用同一個110公鑰去校驗？
在上面的例子裏，Luvsta(我)是發送方，作爲客戶端。小姐姐是接收方，作爲服務器。CA（110）是認證的小姐姐。
如果給多個小姐姐寫信，我需要知道多個小姐姐的公鑰。這些公鑰可能並不是同一個110簽發的，但一定是受信任的機構簽發的，比如119可能也會簽發。但12306不是受信任的機構，無權簽發證書。
如果先用小姐姐的公鑰加密， 再將加密後的信息用Lusvta的私鑰加密
信息可能會被僞造。郵遞員自己可以整一個密鑰對，用郵遞員的私鑰加密。小姐姐無法確定信息是否是luvsta的。其實，這個邏輯反向過來，靠CA認證luvsta，其實是可行的，只是雙向都需要密鑰對，算法比較複雜。只需要服務器端（小姐姐）具有RSA密鑰對即可。
私鑰都是具有相對唯一性，如手和聲音都是相對他人而言的唯一性，公鑰是他人知道且擁有的，如文字信息等等，具有大衆通識性的都算是公鑰，我們的語言就是一種公鑰，但是某些方言就是自己同鄉人的私鑰
方言也是公鑰。私鑰是每個人都擁有一份且永遠不會公開的。例如你的家門鑰匙，你的聲帶，你的手。他們對應的公鑰是你的家門，你的音色，你的字跡。
公鑰和私鑰都不是同一個東西，爲什麼能相互加解密。比如用公鑰是"123”，私鑰是"456”他們是怎麼相互加解密的？
比如我規定一個算法叫“乘法”，你把你要發給我的數據全都乘以“公鑰” 2，我解密時用我的“私鑰” 1/2 乘以你給我的數據，這就實現了一個公鑰加密。
假如世界上沒有人會算除法，沒有人會根據 2 算出來 1/2，沒有人知道怎麼根據算法 A0 * 2 * x = A0 解出來 x，那麼這個加密算法就足夠強了。
但是顯然大家都會算除法，所以人們找了一個特別噁心算法，大質數分解和乘方求餘數，你(至少現在)不能根據公鑰算出私鑰，現在 RSA 還足夠安全。
CA認證能力
認證的過程在應用層發生，認證的目標是域名。
HTTPS就是加密包裝算法嗎
HTTP協議基礎上額外增加一層，在這一層裏使用類似上述的加密算法，就是安全的HTTP，HTTPS。同理，websocket也可以加這一層，就是安全的Websocket，wss。ftp也可以變成ftps。RSA算法是基礎，HTTP是協議，它們可以組合，形成安全的協議。