再見丶無法複製的曾經
密碼學中將加密分為對稱加密和非對稱加密。所謂對稱不對稱指的就是密鑰（yuè），注意這個字的發音，常常容易讀錯。一段數據從明文到密文再到明文的過程，如果用的同一個密鑰就是對稱加密，用的兩個密鑰就是非對稱加密，把非對稱加密中從明文到密文使用的密鑰稱為公鑰，從密文到明文使用的密鑰稱為私鑰。
題主第一個問題本質上說的是密鑰協商算法，最流行的就是DH協議了，全稱Diffie-Hellman，一個非常簡單的基於離散對數難題的算法，再往深了說，還有基於橢圓曲線上的離散對數難題的ECDHE密鑰協商算法，DH算法的升級版。目前就應用在HTTPS中。感興趣的童鞋用火狐訪問下百度，點擊鏈接前面的綠色的鎖，查看詳情，就能看到用的哪些算法：
題主第二個問題想問的應該是非對稱加密目前的應用場景。非對稱加密時間是比對稱加密長的，而且不是一點半點，極端情況下，同一段數據慢上數千倍都有可能的。那麼是否非對稱加密算法就沒有用武之地了呢？非也，我們可以不用非對稱算法來加密數據。我們再回到上面圖中的算法，你一眼應該就能看到一個熟悉的身影，RSA，典型的非對稱加密算法。前面說了，ECDHE是用來交換密鑰的，密鑰是來自對稱加密AES算法的128位密鑰，RSA的作用是什麼？
非對稱算法的一個重大領域就是簽名。你需要做的就是把非對稱算法倒過來用。公鑰加密，私鑰解密，倒過來就是，私鑰簽名，公鑰驗證。RSA在我訪問百度HTTPS中的作用就是，在ECDHE交換密鑰過程中給服務器簽名，通過我這邊火狐瀏覽器進行公鑰驗證，從而完成了百度服務器的身份認證。
前面我為了大家的理解，一直沒有說的是，其實DH或者ECDHE也屬於非對稱加密算法。於是非對稱算法的另一個重大領域也呼之欲出，就是密鑰協商。
SuperBean
場景一
轉賬交易：
假設我要做個轉賬的app叫支付寶，要完成轉賬的功能，轉賬時，需要輸入對方支付寶賬號和姓名，然後點擊轉賬，輸入支付密碼，就可以完成轉賬的功能。
實現方式，客戶端通過http協議發送轉賬報文給服務端
報文無加密和簽名機制
現在用戶甲要轉賬給用戶乙。
安全隱患
網絡傳輸不安全，如果有人截取客戶端請求報文，進行篡改，比如篡改收款方的支付寶賬號和真實姓名，那麼服務端就會把錢轉到別的地方去。
結論：需要防止報文被篡改
場景二
某商城A要接支付寶移動支付，大致流程：
客戶端app調用支付寶的sdk發送支付報文
客戶端接收支付寶服務端的處理響應
商戶服務端接收支付寶服務端的交易成功通知
客戶端發送請求的安全隱患同場景一
服務端接收通知時，存在如下隱患，黑客甲，去商城A
人為模擬支付寶的通知報文，將訂單變成成功。
這是一個通知報文要做簽名的案例
需要注意的是，步驟2和3同樣需要做簽名驗證
結論：需要確認報文來自真實合法的服務端（其實在商戶對商戶的通信過程中，也需要確認報文來自真實合法的客戶端）
場景一和場景二的最終結論：
安全網絡通信過程中，需要防止報文被篡改
安全網絡通信過程中，需要客戶端和服務端雙方確認對方的身份，即交易完成後，不可抵賴
方案一 對稱加密簽名機制
具體方案：用一種對稱加密算法將報文加密，並得出一個簽名串
舉例：MD5加密簽名，簽名串=md5(原文&密鑰)（其他對稱加密算法簽名道理是一樣的，不做詳述）
假設最終的報文是：最終報文=原文&簽名串
此方案達到的效果：
如果黑客截取報文，並篡改原文，那麼服務端進行驗籤的時候，將不會通過。
因為原文變化了，算出的簽名串會改變，那麼黑客需要重新計算出簽名串
要算出簽名串，需要知道如下要素
簽名算法（包含加密算法），原文，密鑰
前2個肯定是會暴露的，無法保密，而客戶端是app，密鑰也是暴露的，所以簽名串會被重新計算出來，因此黑客將成功篡改轉賬報文。
方案二 對稱加密簽名，動態密鑰
從方案一我們得出一個結論：
簽名算法（包含加密算法），原文，密鑰三者只要保證其中一個不被黑客截取，將無法算出簽名串，也就無法篡改報文。
那麼我們可以動態生成簽名的密鑰，並用rsa公鑰對其進行加密（此處rsa私鑰在服務端，不會洩密，因為簽名密鑰不會被解密），然後傳至服務端
次方案用於場景一，可以解決報文被篡改的問題。
但是服務端就無法確認客戶端是否合法，尤其在機構與機構通信的時候，這個方案就更不可取。
且次方案不適合於方案2，支付寶服務端發通知的時候，總不能動態產生密鑰，這樣你就無法判定報文是否是支付寶服務端發送來的。
方案三 報文加密（對稱加非對稱）
從方案一我們得出一個結論：
簽名算法（包含加密算法），原文，密鑰三者只要保證其中一個不被黑客截取，將無法算出簽名串，也就無法篡改報文。
那麼我們就採取對報文加密，可用方式是對稱加密和非對稱加密
1.對稱加密：3des
簽名串=md5(原文&密鑰1)
最終報文=3des密鑰2&簽名串
傳輸過程中，報文是加密的，無法篡改（因為無法拿到用戶關鍵信息，如session，tokenId等認證信息），看似沒有問題，但是密鑰1和密鑰2都可能洩密，而且3des會被解密掉，所以又回到方案一的結果。
2.非對稱加密+對稱加密：3des+rsa+md5
那麼我們可以從方案二吸取經驗，用rsa密鑰加密對稱加密密鑰
簽名串=md5(原文&密鑰1)
最終報文=3des密鑰2|簽名串|rsarsa公鑰
此方案仍然有方案二的缺陷，只能解決場景1，不能解決場景2
原因在於簽名的密鑰，服務端和客戶端是一樣的，無法產生唯一性身份
我們需要用rsa來簽名
方案四 rsa簽名+https
報文加密是必須的，那麼我們用https加密，其原理同非對稱加密+對稱加密
場景一方案：
客戶端產生一對公私鑰 pubKey_c，priKey_c
服務端產生一對公私鑰 pubkey_s，priKey_s
客戶端與服務端置換公鑰
最終持有情況如下：
客戶端：pubkey_s，priKey_c
服務端：pubKey_c，priKey_s
簽名串=rsapriKey_c
最終報文=https(報文原文+簽名串);
場景二，相對於場景二
服務端用pubKey_c做驗籤，
產生效果：客戶端私鑰priKey_c沒有被盜取時，可以防止報文被篡改，且服務端可以確認信息來自合法的客戶端，在機構與機構通信時，次種假設是成立的。
客戶端是app, 客戶端私鑰priKey_c會被盜取，不能保證客戶端的合法性（即客戶端可以不是官方提供的），但仍然可以防止報文被篡改。
服務端響應報文時：
簽名串=rsapriKey_s
最終報文=https(報文原文+簽名串);
產生效果：因為服務端的私鑰priKey_s在理論上是不會洩密的，所以可以保證響應報文不會被篡改，且來自真實合法的服務端
場景二方案：
簽名串=rsapriKey_s
最終報文=https(報文原文+簽名串);
客戶端用pubkey_s來驗籤即可，可保證，報文不會被篡改，且來自真實合法的服務端
不一樣的程序猿
通常會組合使用非對稱加密和對稱加密。
第一次通訊的時候，會使用非對稱加密，利用非對稱加密把對稱加密的密鑰傳輸給另一端，後續所有的通訊都會基於對稱加密來進行。這樣避免了每次通訊都使用非對稱加密導致速度慢的問題，又利用非對稱加密解決了密鑰傳輸問題。
目前使用極為廣泛的https就是這個原理。
種碼人
用非對稱加密技術去加密對稱加密的秘鑰。業界一直都是這麼幹的。
zhangjint5
用非對稱密碼降低對稱密碼的生命週期
