SSH HTTPS 公鑰、祕鑰、對稱加密、非對稱加密、 總結理解

做者：shede333
主頁：http://my.oschina.net/shede333 && http://blog.sina.com.cn/u/1509658847
版權聲明：原創文章，版權聲明：自由轉載-非商用-非衍生-保持署名 | [Creative Commons BY-NC-ND 3.0][]

---

###DES: Digital Encryption Standard. Obsolete standard. 單密鑰算法,是信息的發送方採用密鑰A進行數據加密,信息的接收方採用同一個密鑰A進行數據解密.

單密鑰算法是一個對稱算法. 算法好在加/解速度快,密鑰量短,採用對稱加密

###DSA: Digital Signature Algorithm. based on discrete logarithms computation. 主要用於簽名
在DSA數字簽名和認證中，發送者使用本身的私鑰對文件或消息進行簽名，接受者收到消息後使用發送者的公鑰
DSA只是一種算法，和RSA不一樣之處在於它不能用做加密和解密，也不能進行密鑰交換，
只用於簽名,它比RSA要快不少.

DSA只能與SHA-1一塊兒使用，而RSA能夠與任何摘要算法一塊兒使用。DSA簽名不包括摘要標識符，因此若是容許多種摘要算法就會使DSA遭受前面RSA裏面介紹的那種替換攻擊。DSA主要依賴於整數有限域離散對數難題。

與RSA不一樣的是，RSA是對簽名數據「解密」後再比對摘要值，而DSA中摘要值是須要參與計算的。

###RSA: RSA 是一種非對稱加解密算法。
RSA 與 DSA 都是非對稱加密算法。其中RSA的安全性是基於極其困難的大整數的分解（兩個素數的乘積）；DSA 的安全性

是基於整數有限域離散對數難題。基本上能夠認爲相同密鑰長度的 RSA 算法與 DSA 算法安全性至關。

公鑰用於加密，它是向全部人公開的；私鑰用於解密，只有密文的接收者持有。

DSA 用於簽名，而 RSA 可用於簽名和加密。

**refer: **

DES _百度百科

RSA,DSA等加解密算法介紹_愈來愈好_新浪博客

DSA與RSA的區別-ad007520-ITPUB博客

非對稱算法-數字簽名算法-DSA

###公鑰、私鑰 的解釋

公鑰 :用於向外發佈，任何人都能獲取，
私鑰 :要本身保存，切勿給別人

一下兩種狀況常常有人弄混，必定要理解。

狀況1：公鑰用於【加密】， 私鑰用於【解密】
若是加密密鑰是公開的，這用於客戶給私鑰全部者上傳加密的數據，這被稱做爲公開密鑰加密(狹義)。
例如，網絡銀行的客戶發給銀行網站的帳戶操做的加密數據。HTTPS 等。

狀況2：公鑰用於【解密】，私鑰用於【加密】
若是解密密鑰是公開的，用私鑰加密的信息，能夠用公鑰對其解密，用於客戶驗證持有私鑰一方發佈的數據或文件是完整準確的，接收者由此可知這條信息確實來自於擁有私鑰的某人，這被稱做數字簽名，公鑰的形式就是數字證書。例如，從網上下載的安裝程序，通常都帶有程序製做者的數字簽名，能夠證實該程序的確是該做者（公司）發佈的而不是第三方僞造的且未被篡改過（身份認證/驗證）。

refer:

公開密鑰加密 - 維基百科，自由的百科全書

數字證書原理

###簽名：

加密後的hash值
這裏主要解釋一下簽名，簽名就是在信息的後面再加上一段內容，能夠證實信息沒有被修改過，怎麼樣能夠達到這個效果呢？通常是對信息作一個hash計算獲得一個hash值，注意，這個過程是不可逆的，也就是說沒法經過hash值得出原來的信息內容。在把信息發送出去時，把這個hash值加密後作爲一個簽名和信息一塊兒發出去

###指紋： 指紋算法 即 一個hash算法 ，例如md5算法；
注意，爲了保證安全，在證書的發佈機構發佈證書時，證書的指紋和指紋算法，都會加密後再和證書放到一塊兒發佈，以防有人修改指紋後僞造相應的數字證書。這裏問題又來了，證書的指紋和指紋算法用什麼加密呢？他們是用證書發佈機構的私鑰進行加密的。能夠用證書發佈機構的公鑰對指紋和指紋算法解密，也就是說證書發佈機構除了給別人發佈證書外，他本身自己也有本身的證書。證書發佈機構的證書是哪裏來的呢？？？這個證書發佈機構的數字證書(通常由他本身生成)在咱們的操做系統剛安裝好時(例如windows xp等操做系統)，這些證書發佈機構的數字證書就已經被微軟(或者其它操做系統的開發機構)安裝在操做系統中了，微軟等公司會根據一些權威安全機構的評估選取一些信譽很好而且經過必定的安全認證的證書發佈機構，把這些證書發佈機構的證書默認就安裝在操做系統裏面了，而且設置爲操做系統信任的數字證書。這些證書發佈機構本身持有與他本身的數字證書對應的私鑰，他會用這個私鑰加密全部他發佈的證書的指紋做爲數字簽名。

refer: 數字簽名是什麼？

---

###公鑰登錄 error

使用密碼登陸，每次都必須輸入密碼，很是麻煩。好在SSH還提供了公鑰登陸，能夠省去輸入密碼的步驟。 所謂"公鑰登陸"，原理很簡單，就是用戶將本身的公鑰儲存在遠程主機上。登陸的時候，遠程主機會向用戶發送一段隨機字符串，用戶用本身的私鑰加密後，再發回來。遠程主機用事先儲存的公鑰進行解密，若是成功，就證實用戶是可信的，直接容許登陸shell，再也不要求密碼。 這種方法要求用戶必須提供本身的公鑰。若是沒有現成的，能夠直接用ssh-keygen生成一個：

　　$ ssh-keygen

refer:

SSH原理與運用（一）：遠程登陸 - 阮一峯的網絡日誌

localhost：客戶端，
remotehost：服務器
密鑰訪問：localhost經過ssh-keygen來生成公鑰密鑰對，若是他想訪問一個remotehost，則只須要將公鑰添加到 remotehost的~/.ssh/authorized_keys中，接下來，當localhost經過ssh登陸 username@remotehost時，remotehost會生成一個隨機數，經過autrorized_keys中的公鑰們生成一系列數值發給 localhost，localhost會經過本身的私有密鑰解密發過來的一系列數值（固然，只有用對應的公鑰生成的數值纔會被正常解密），隨 後，localhost將解密後的數值發回去，remotehost若發現發回來的數值是原先產生的隨機數時，便會容許該localhost訪問。固然， 若是localhost生成的rsa密鑰是須要密碼的話，接下來還要輸入該密碼。

refer:

ssh 密鑰訪問

---

###SSH基本原理和免密碼登陸

從客戶端來看,SSH提供兩種級別的安全驗證：

第一種級別是基於口令的安全驗證:

（1）遠程主機收到用戶的登陸請求，把本身的公鑰發給用戶。

（2）用戶使用這個公鑰，將登陸密碼加密後，發送回來。

（3）遠程主機用本身的私鑰，解密登陸密碼，若是密碼正確，就贊成用戶登陸。

缺點：若是有人冒充服務器，就會給你假服務器公鑰，最後就能得到你迴應的密碼，這就是中間人攻擊。

第二種級別是基於密匙的安全驗證：

前提：客戶端建立一對公鑰+祕鑰，同時將公鑰放在服務器上。

1.客戶端軟件就會向服務器發出請求，請求用你的密匙進行安全驗證； 2. 服務器收到請求以後，先在該服務器上尋找你的公鑰，而後把它和你發送過來的公用密匙進行比較。若是兩個密匙一致，服務器就用這個公鑰加密一個【隨機字符串】並把它發送給客戶端軟件； 3.客戶端軟件收到【加密後的-隨機字符串】以後，就能夠用你的私人密匙解密，再把【隨機字符串】發送給服務器

與第一種級別相比，第二種級別不須要在網絡上傳送口令。第二種級別不只加密全部傳送的數據，並且「中間人」這種攻擊方式也是不可能的（由於他沒有你的私人密匙）。可是整個登陸的過程可能須要10秒，可是相比輸入密碼的方式來講10秒也不長。

refer:

SSH基本原理和免密碼登陸

---

###公鑰認證的原理

所謂的公鑰認證，其實是使用一對加密字符串，一個稱爲公鑰(public key)，任何人均可以看到其內容，用於加密；另外一個稱爲密鑰(private key)，只有擁有者才能看到，用於解密。經過公鑰加密過的密文使用密鑰能夠輕鬆解密，但根據公鑰來猜想密鑰卻十分困難。

ssh 的公鑰認證就是使用了這一特性。服務器和客戶端都各自擁有本身的公鑰和密鑰。爲了說明方便，如下將使用這些符號。

Ac 客戶端公鑰
Bc 客戶端密鑰
As 服務器公鑰
Bs 服務器密鑰
在認證以前，客戶端須要經過某種方法將公鑰 Ac 登陸到服務器上。

認證過程分爲兩個步驟。

會話密鑰(session key)生成
客戶端請求鏈接服務器，服務器將 As 發送給客戶端。
服務器生成會話ID(session id)，設爲 p，發送給客戶端。
客戶端生成會話密鑰(session key)，設爲 q，並計算 r = p xor q。
客戶端將 r 用 As 進行加密，結果發送給服務器。
服務器用 Bs 進行解密，得到 r。
服務器進行 r xor p 的運算，得到 q。
至此服務器和客戶端都知道了會話密鑰q，之後的傳輸都將被 q 加密。
認證
服務器生成隨機數 x，並用 Ac 加密後生成結果 S(x)，發送給客戶端
客戶端使用 Bc 解密 S(x) 獲得 x
客戶端計算 q + x 的 md5 值 n(q+x)，q爲上一步獲得的會話密鑰
服務器計算 q + x 的 md5 值 m(q+x)
客戶端將 n(q+x) 發送給服務器
服務器比較 m(q+x) 和 n(q+x)，二者相同則認證成功

refer:

ssh 公鑰私鑰認證原理

---

###非對稱加密

服務器創建公鑰： 每一次啓動 sshd 服務時，該服務會主動去找 /etc/ssh/ssh_host* 的文件，若系統剛剛安裝完成時，因爲沒有這些公鑰，所以 sshd 會主動去計算出這些須要的公鑰，同時也會計算出服務器本身須要的私鑰
*
客戶端主動聯機請求： 若客戶端想要聯機到 ssh 服務器，則須要使用適當的客戶端程序來聯機，包括 ssh, putty 等客戶端程序鏈接
*
服務器傳送公鑰給客戶端： 接收到客戶端的要求後，服務器便將第一個步驟取得的公鑰傳送給客戶端使用 (此時應是明碼傳送，反正公鑰原本就是給你們使用的)
*
客戶端記錄並比對服務器的公鑰數據及隨機計算本身的公私鑰： 若客戶端第一次鏈接到此服務器，則會將服務器的公鑰記錄到客戶端的用戶家目錄內的 ~/.ssh/known_hosts 。如果已經記錄過該服務器的公鑰，則客戶端會去比對這次接收到的與以前的記錄是否有差別。若接受此公鑰， 則開始計算客戶端本身的公私鑰
*
回傳客戶端的公鑰到服務器端： 用戶將本身的公鑰傳送給服務器。此時服務器：具備服務器的私鑰與客戶端的公鑰，而客戶端則是： 具備服務器的公鑰以及客戶端本身的私鑰，你會看到，在這次聯機的服務器與客戶端的密鑰系統 (公鑰+私鑰) 並不同，因此才稱爲非對稱加密系統
*
開始雙向加解密： (1)服務器到客戶端：服務器傳送數據時，拿用戶的公鑰加密後送出。客戶端接收後，用本身的私鑰解密 (2)客戶端到服務器：客戶端傳送數據時，拿服務器的公鑰加密後送出。服務器接收後，用服務器的私鑰解密，這樣就能保證通訊安全

refer:

SSH 協議與OpenSSH詳解 - Share your knowledge … - 51CTO技術博客

---

###SSL/TLS協議

SSL/TLS協議的基本思路是採用公鑰加密法，也就是說，客戶端先向服務器端索要公鑰，而後用公鑰加密信息，服務器收到密文後，用本身的私鑰解密。

SSL/TLS協議(HTTPS 也是這樣的)的基本過程是這樣的:

1.客戶端生成【隨機數1】，客戶端（一般是瀏覽器）先向服務器發出加密通訊的請求，發送【隨機數1】，向服務器端索要公鑰；  
2.服務器收到客戶端請求後，生成【隨機數2】，向客戶端發出迴應，迴應信息包括【隨機數2】，服務器證書(包含公鑰)  
3.客戶端收到後，驗證服務器證書的有效性，取出公鑰，生成【隨機數3】，使用公鑰加密【隨機數3】，發給服務器。  
4.服務器迴應， 至此，服務器和客戶端都有3個隨機數，使用3個隨機數生成此次的會話祕鑰(即對稱祕鑰)，兩者開始使用對稱加密通信。服務器通知客戶端：編碼改變通知，表示隨後的信息都將用雙方商定的加密方法和密鑰發送。服務器握手結束通知，表示服務器的握手階段已經結束。這一項同時也是前面發送的全部內容的hash值，用來供客戶端校驗(對稱加密)。
5.以後兩者將經過對稱加密來通信。

解釋：爲啥使用3個隨機數。
不論是客戶端仍是服務器，都須要隨機數，這樣生成的密鑰纔不會每次都同樣。因爲SSL協議中證書是靜態的，所以十分有必要引入一種隨機因素來保證協商出來的密鑰的隨機性，三個隨機數經過一個密鑰導出器最終導出一個對稱密鑰，增長隨機性

以前不少講HTTPS原理的(包括下面的https)，都只有1個隨機數，爲啥？由於畢竟是講原理，並無講清細節；
簡單來講，一開始使用的非對稱加密，就是爲了安全的傳遞對稱祕鑰，畢竟對稱加密的速度快。

refer:

SSL/TLS協議運行機制的概述

---

###https 非對稱+對稱

refer:

圖解HTTPS 無網不剩