1.對稱數(shù)據(jù)加密
就像上圖所示， 這加密和解密算法是公開的，那個密鑰是保密的， 只有兩人才知道， 這樣生成的加密消息（密文） 別人就無法得知了。這叫對稱加密算法，因為加密和解密用的是同一個密鑰。
問題來了，這個密鑰的雙方必須得知道，但是通過網(wǎng)絡(luò)發(fā)送又不安全，這該怎么辦呢？這時候就出現(xiàn)了非對稱數(shù)據(jù)加密。
2.RSA：非對稱加密
這個RSA算法非常有意思，它不是像之前的算法， 雙方必須協(xié)商一個保密的密鑰， 而是有一對兒鑰匙， 一個是保密的，稱為私鑰，另外一個是公開的，稱為公鑰。
更有意思的是，用私鑰加密的數(shù)據(jù)，只有對應(yīng)的公鑰才能解密，用公鑰加密的數(shù)據(jù)， 只有對應(yīng)的私鑰才能解密。
有了這兩個漂亮的特性， 當(dāng)張大胖給Bill發(fā)消息的時候， 就可以先用Bill的公鑰去加密（反正Bill的公鑰是公開的，地球人都知道）， 等到消息被Bill 收到后， 他就可以用自己的私鑰去解密（只有Bill才能解開，私鑰是保密的 ）【也就是A發(fā)送消息給B時候，利用B的公鑰，然后B收到后利用私鑰解密接收。】
反過來也是如此， 當(dāng)Bill 想給張大胖發(fā)消息的時候，就用張大胖的公鑰加密， 張大胖收到后，就用自己的私鑰解密。
3.非對稱加密+對稱加密
為什么會出現(xiàn)這種情況呢？
因為RSA的加密和解密的速度比較慢，RSA的算法比之前的對稱密鑰算法要慢上百倍。
回到咱們最初的問題，我們想用一個密鑰來加密通信，那個對稱加密算法是非常快的，但是苦于密鑰無法安全傳輸， 現(xiàn)在有了RSA ，我想可以結(jié)合一下， 分兩步走 (1) 我生成一個對稱加密算法的密鑰， 用RSA的方式安全發(fā)給你， (2) 我們隨后就不用RSA了， 只用這個密鑰，利用對稱加密算法來通信，這樣即可以保證安全又可以加快速度。【也就是只利用RSA傳輸密鑰，保證密鑰的安全。然后利用對稱加密進行信息傳輸。】
這樣以來既解決了密鑰的傳遞問題， 又解決了RSA速度慢的問題，不錯。
于是兩人就安全地傳遞了對稱加密的密鑰， 用它來加密解密，果然快多了！
HTTPS就是使用上述混合加密的方法。
4.中間人攻擊
這個話題，主要是針對你如何確認對面的人是你想通信的人。
假如啊，Bill給你發(fā)公鑰的時候， 有個中間人，截取了Bill的公鑰， 然后把自己的公鑰發(fā)給了你，冒充Bill ，你發(fā)的消息就用中間人的公鑰加了密，那中間人利用自己的密鑰不就可以解密看到消息了【這個是利用自己的密鑰，然后自己的私鑰接收】？同時，還可以用Bill的公鑰加密，發(fā)給Bill , Bill和我根本都意識不到， 還以為我們在安全傳輸呢！【這個是利用Bill的公鑰，發(fā)送自己的信息給Bill。】
**看來問題出現(xiàn)在公鑰的分發(fā)上！**雖然這個東西是公開的，但是在別有用心的人看來，截取以后還可以干壞事 ！
但是怎么安全地分發(fā)公鑰呢？ 似乎又回到了最初的問題： 怎么安全的保護密鑰（之前是利用非對稱保護私鑰的傳輸，現(xiàn)在是考慮如何保證公鑰的發(fā)送方）？
可是似乎和最初的問題還不一樣，這一次的公鑰不用保密，但是一定得有個辦法聲明這個公鑰確實是Bill的， 而不是別人的。
5.信息摘要、數(shù)字簽名、數(shù)字證書
簡單來講是這樣的， Bill可以把他的公鑰和個人信息用一個Hash算法生成一個消息摘要， 這個Hash算法有個極好的特性，只要輸入數(shù)據(jù)有一點點變化，那生成的消息摘要就會有巨變，這樣就可以防止別人修改原始內(nèi)容。
可是作為攻擊者的中間人笑了： “雖然我沒辦法改公鑰，但是我可以把整個原始信息都替換了， 生成一個新的消息摘要， 你不還是辨別不出來？”
張大胖說你別得意的太早 ， 我們會讓有公信力的認證中心（簡稱CA）用它的私鑰對消息摘要加密，形成簽名：
這還不算， 還把原始信息和數(shù)據(jù)簽名合并， 形成一個全新的東西，叫做“數(shù)字證書”
大胖接著說：當(dāng)Bill把他的證書發(fā)給我的時候， 我就用同樣的Hash 算法， 再次生成消息摘要，然后用CA的公鑰對數(shù)字簽名解密， 得到CA創(chuàng)建的消息摘要， 兩者一比，就知道有沒有人篡改了！
如果沒人篡改， 我就可以安全的拿到Bill的公鑰嘍，有了公鑰， 后序的加密工作就可以開始了。
那么這個CA的公鑰怎么保證他的安全性？
附注：我們利用上面數(shù)字證書保證傳輸安全的前提就是，我們默認CA的公鑰是安全的。因為CA的公鑰安全，所以得出的消息摘要是安全的，這就可以與Hash算法得出的消息摘要比較是否相同，從而確保消息的安全的。
6.HTTPS
數(shù)字證書的實例：HTTPS協(xié)議。這個協(xié)議主要用于網(wǎng)頁加密。
1.首先，客戶端向服務(wù)器發(fā)出加密請求。
2.服務(wù)器用自己的私鑰加密網(wǎng)頁以后，連同本身的數(shù)字證書，一起發(fā)送給客戶端。
3.客戶端（瀏覽器）的"證書管理器"，有"受信任的根證書頒發(fā)機構(gòu)"列表。客戶端會根據(jù)這張列表，查看解開數(shù)字證書的公鑰是否在列表之內(nèi)。
4.如果數(shù)字證書記載的網(wǎng)址，與你正在瀏覽的網(wǎng)址不一致，就說明這張證書可能被冒用，瀏覽器會發(fā)出警告。
5.如果這張數(shù)字證書不是由受信任的機構(gòu)頒發(fā)的，瀏覽器會發(fā)出另一種警告
6.如果數(shù)字證書是可靠的，客戶端就可以使用證書中的服務(wù)器公鑰，對信息進行加密，然后與服務(wù)器交換加密信息
