⑴ RSA的公鑰、私鑰
RSA的公鑰、私鑰
採用單鑰 密碼系統 的加密方法，同一個 密鑰 可以同時用作信息的加密和解密，這種加密方法稱為對稱加密，也稱為單 密鑰加密 。
與對稱加密 演算法 不同， 非對稱加密演算法 需要兩個 密鑰 ： 公開密鑰 （publickey）和私有密鑰（privatekey）。 公開密鑰 與私有密鑰是一對，如果用公開密鑰對數據進行加密，只有用對應的私有密鑰才能解密；如果用私有密鑰對數據進行加密，那麼只有用對應的公開密鑰才能解密。因為加密和解密使用的是兩個不同的 密鑰 ，所以這種演算法叫作 非對稱加密演算法 。
一、舉個例子
1、發消息
用對方的公鑰給對方發消息
2、發公告
發公告的時候，用自己的私鑰形成簽名！
二、加密和簽名
RSA的公鑰、私鑰是互相對應的，RSA會生成兩個密鑰，你可以把任何一個用於公鑰，然後另一個就是你必須保護好的私鑰了。
RSA的公鑰、私鑰都可以加密，也都可以解密。
其中：
用公鑰加密需要私鑰解密，稱為「加密」。由於私鑰是不公開的，確保了內容的保密，沒有私鑰無法獲得內容；
用私鑰加密需要公鑰解密，稱為「簽名」。由於公鑰是公開的，任何人都可以解密內容，但只能用發布者的公鑰解密，驗證了內容是該發布者發出的。
所以：
如果用於加密解密，那就是用公鑰加密私鑰解密（僅你可讀但別人不可讀，任何人都可寫）
如果用於證書驗證，那就是用私鑰加密公鑰解密（僅你可寫但別人不可寫，任何人都可讀）
三、認證過程
標簽: HTTP
⑵ 【深度知識】區塊鏈之加密原理圖示(加密,簽名)
先放一張以太坊的架構圖：
在學習的過程中主要是採用單個模塊了學習了解的，包括P2P,密碼學，網路，協議等。直接開始總結：
秘鑰分配問題也就是秘鑰的傳輸問題，如果對稱秘鑰，那麼只能在線下進行秘鑰的交換。如果在線上傳輸秘鑰，那就有可能被攔截。所以採用非對稱加密，兩把鑰匙，一把私鑰自留，一把公鑰公開。公鑰可以在網上傳輸。不用線下交易。保證數據的安全性。
如上圖，A節點發送數據到B節點，此時採用公鑰加密。A節點從自己的公鑰中獲取到B節點的公鑰對明文數據加密，得到密文發送給B節點。而B節點採用自己的私鑰解密。
2、無法解決消息篡改。
如上圖，A節點採用B的公鑰進行加密，然後將密文傳輸給B節點。B節點拿A節點的公鑰將密文解密。
1、由於A的公鑰是公開的，一旦網上黑客攔截消息，密文形同虛設。說白了，這種加密方式，只要攔截消息，就都能解開。
2、同樣存在無法確定消息來源的問題，和消息篡改的問題。
如上圖，A節點在發送數據前，先用B的公鑰加密，得到密文1，再用A的私鑰對密文1加密得到密文2。而B節點得到密文後，先用A的公鑰解密，得到密文1，之後用B的私鑰解密得到明文。
1、當網路上攔截到數據密文2時， 由於A的公鑰是公開的，故可以用A的公鑰對密文2解密，就得到了密文1。所以這樣看起來是雙重加密，其實最後一層的私鑰簽名是無效的。一般來講，我們都希望簽名是簽在最原始的數據上。如果簽名放在後面，由於公鑰是公開的，簽名就缺乏安全性。
2、存在性能問題，非對稱加密本身效率就很低下，還進行了兩次加密過程。
如上圖，A節點先用A的私鑰加密，之後用B的公鑰加密。B節點收到消息後，先採用B的私鑰解密，然後再利用A的公鑰解密。
1、當密文數據2被黑客攔截後，由於密文2隻能採用B的私鑰解密，而B的私鑰只有B節點有，其他人無法機密。故安全性最高。
2、當B節點解密得到密文1後， 只能採用A的公鑰來解密。而只有經過A的私鑰加密的數據才能用A的公鑰解密成功，A的私鑰只有A節點有，所以可以確定數據是由A節點傳輸過來的。
經兩次非對稱加密，性能問題比較嚴重。
基於以上篡改數據的問題，我們引入了消息認證。經過消息認證後的加密流程如下：
當A節點發送消息前，先對明文數據做一次散列計算。得到一個摘要, 之後將照耀與原始數據同時發送給B節點。當B節點接收到消息後，對消息解密。解析出其中的散列摘要和原始數據，然後再對原始數據進行一次同樣的散列計算得到摘要1, 比較摘要與摘要1。如果相同則未被篡改，如果不同則表示已經被篡改。
在傳輸過程中，密文2隻要被篡改，最後導致的hash與hash1就會產生不同。
無法解決簽名問題，也就是雙方相互攻擊。A對於自己發送的消息始終不承認。比如A對B發送了一條錯誤消息，導致B有損失。但A抵賴不是自己發送的。
在(三)的過程中，沒有辦法解決交互雙方相互攻擊。什麼意思呢？ 有可能是因為A發送的消息，對A節點不利，後來A就抵賴這消息不是它發送的。
為了解決這個問題，故引入了簽名。這里我們將(二)-4中的加密方式，與消息簽名合並設計在一起。
在上圖中，我們利用A節點的私鑰對其發送的摘要信息進行簽名，然後將簽名+原文，再利用B的公鑰進行加密。而B得到密文後，先用B的私鑰解密，然後 對摘要再用A的公鑰解密，只有比較兩次摘要的內容是否相同。這既避免了防篡改問題，有規避了雙方攻擊問題。因為A對信息進行了簽名，故是無法抵賴的。
為了解決非對稱加密數據時的性能問題，故往往採用混合加密。這里就需要引入對稱加密，如下圖:
在對數據加密時，我們採用了雙方共享的對稱秘鑰來加密。而對稱秘鑰盡量不要在網路上傳輸，以免丟失。這里的共享對稱秘鑰是根據自己的私鑰和對方的公鑰計算出的，然後適用對稱秘鑰對數據加密。而對方接收到數據時，也計算出對稱秘鑰然後對密文解密。
以上這種對稱秘鑰是不安全的，因為A的私鑰和B的公鑰一般短期內固定，所以共享對稱秘鑰也是固定不變的。為了增強安全性，最好的方式是每次交互都生成一個臨時的共享對稱秘鑰。那麼如何才能在每次交互過程中生成一個隨機的對稱秘鑰，且不需要傳輸呢？
那麼如何生成隨機的共享秘鑰進行加密呢？
對於發送方A節點，在每次發送時，都生成一個臨時非對稱秘鑰對，然後根據B節點的公鑰 和 臨時的非對稱私鑰 可以計算出一個對稱秘鑰(KA演算法-Key Agreement)。然後利用該對稱秘鑰對數據進行加密，針對共享秘鑰這里的流程如下：
對於B節點，當接收到傳輸過來的數據時，解析出其中A節點的隨機公鑰，之後利用A節點的隨機公鑰 與 B節點自身的私鑰 計算出對稱秘鑰(KA演算法)。之後利用對稱秘鑰機密數據。
對於以上加密方式，其實仍然存在很多問題，比如如何避免重放攻擊(在消息中加入 Nonce )，再比如彩虹表(參考 KDF機制解決 )之類的問題。由於時間及能力有限，故暫時忽略。
那麼究竟應該採用何種加密呢？
主要還是基於要傳輸的數據的安全等級來考量。不重要的數據其實做好認證和簽名就可以，但是很重要的數據就需要採用安全等級比較高的加密方案了。
密碼套件 是一個網路協議的概念。其中主要包括身份認證、加密、消息認證(MAC)、秘鑰交換的演算法組成。
在整個網路的傳輸過程中，根據密碼套件主要分如下幾大類演算法：
秘鑰交換演算法：比如ECDHE、RSA。主要用於客戶端和服務端握手時如何進行身份驗證。
消息認證演算法：比如SHA1、SHA2、SHA3。主要用於消息摘要。
批量加密演算法：比如AES, 主要用於加密信息流。
偽隨機數演算法：例如TLS 1.2的偽隨機函數使用MAC演算法的散列函數來創建一個 主密鑰 ——連接雙方共享的一個48位元組的私鑰。主密鑰在創建會話密鑰（例如創建MAC）時作為一個熵來源。
在網路中，一次消息的傳輸一般需要在如下4個階段分別進行加密，才能保證消息安全、可靠的傳輸。
握手/網路協商階段：
在雙方進行握手階段，需要進行鏈接的協商。主要的加密演算法包括RSA、DH、ECDH等
身份認證階段：
身份認證階段，需要確定發送的消息的來源來源。主要採用的加密方式包括RSA、DSA、ECDSA(ECC加密，DSA簽名)等。
消息加密階段：
消息加密指對發送的信息流進行加密。主要採用的加密方式包括DES、RC4、AES等。
消息身份認證階段/防篡改階段：
主要是保證消息在傳輸過程中確保沒有被篡改過。主要的加密方式包括MD5、SHA1、SHA2、SHA3等。
ECC ：Elliptic Curves Cryptography，橢圓曲線密碼編碼學。是一種根據橢圓上點倍積生成 公鑰、私鑰的演算法。用於生成公私秘鑰。
ECDSA ：用於數字簽名,是一種數字簽名演算法。一種有效的數字簽名使接收者有理由相信消息是由已知的發送者創建的，從而發送者不能否認已經發送了消息(身份驗證和不可否認)，並且消息在運輸過程中沒有改變。ECDSA簽名演算法是ECC與DSA的結合，整個簽名過程與DSA類似，所不一樣的是簽名中採取的演算法為ECC，最後簽名出來的值也是分為r,s。 主要用於身份認證階段 。
ECDH ：也是基於ECC演算法的霍夫曼樹秘鑰，通過ECDH，雙方可以在不共享任何秘密的前提下協商出一個共享秘密，並且是這種共享秘鑰是為當前的通信暫時性的隨機生成的，通信一旦中斷秘鑰就消失。 主要用於握手磋商階段。
ECIES： 是一種集成加密方案,也可稱為一種混合加密方案，它提供了對所選擇的明文和選擇的密碼文本攻擊的語義安全性。ECIES可以使用不同類型的函數：秘鑰協商函數(KA)，秘鑰推導函數(KDF)，對稱加密方案(ENC)，哈希函數(HASH), H-MAC函數(MAC)。
ECC 是橢圓加密演算法，主要講述了按照公私鑰怎麼在橢圓上產生，並且不可逆。 ECDSA 則主要是採用ECC演算法怎麼來做簽名， ECDH 則是採用ECC演算法怎麼生成對稱秘鑰。以上三者都是對ECC加密演算法的應用。而現實場景中，我們往往會採用混合加密(對稱加密，非對稱加密結合使用，簽名技術等一起使用)。 ECIES 就是底層利用ECC演算法提供的一套集成(混合)加密方案。其中包括了非對稱加密，對稱加密和簽名的功能。
<meta charset="utf-8">
這個先訂條件是為了保證曲線不包含奇點。
所以，隨著曲線參數a和b的不斷變化，曲線也呈現出了不同的形狀。比如:
所有的非對稱加密的基本原理基本都是基於一個公式 K = k G。其中K代表公鑰，k代表私鑰，G代表某一個選取的基點。非對稱加密的演算法 就是要保證 該公式 不可進行逆運算( 也就是說G/K是無法計算的 )。 *
ECC是如何計算出公私鑰呢？這里我按照我自己的理解來描述。
我理解，ECC的核心思想就是：選擇曲線上的一個基點G，之後隨機在ECC曲線上取一個點k(作為私鑰)，然後根據k G計算出我們的公鑰K。並且保證公鑰K也要在曲線上。*
那麼k G怎麼計算呢？如何計算k G才能保證最後的結果不可逆呢？這就是ECC演算法要解決的。
首先，我們先隨便選擇一條ECC曲線，a = -3, b = 7 得到如下曲線：
在這個曲線上，我隨機選取兩個點，這兩個點的乘法怎麼算呢？我們可以簡化下問題，乘法是都可以用加法表示的，比如2 2 = 2+2，3 5 = 5+5+5。 那麼我們只要能在曲線上計算出加法，理論上就能算乘法。所以，只要能在這個曲線上進行加法計算，理論上就可以來計算乘法，理論上也就可以計算k*G這種表達式的值。
曲線上兩點的加法又怎麼算呢？這里ECC為了保證不可逆性，在曲線上自定義了加法體系。
現實中，1+1=2，2+2=4，但在ECC演算法里，我們理解的這種加法體系是不可能。故需要自定義一套適用於該曲線的加法體系。
ECC定義，在圖形中隨機找一條直線，與ECC曲線相交於三個點(也有可能是兩個點)，這三點分別是P、Q、R。
那麼P+Q+R = 0。其中0 不是坐標軸上的0點，而是ECC中的無窮遠點。也就是說定義了無窮遠點為0點。
同樣，我們就能得出 P+Q = -R。 由於R 與-R是關於X軸對稱的，所以我們就能在曲線上找到其坐標。
P+R+Q = 0, 故P+R = -Q , 如上圖。
以上就描述了ECC曲線的世界裡是如何進行加法運算的。
從上圖可看出，直線與曲線只有兩個交點，也就是說 直線是曲線的切線。此時P,R 重合了。
也就是P = R, 根據上述ECC的加法體系，P+R+Q = 0, 就可以得出 P+R+Q = 2P+Q = 2R+Q=0
於是乎得到 2 P = -Q (是不是與我們非對稱演算法的公式 K = k G 越來越近了)。
於是我們得出一個結論，可以算乘法，不過只有在切點的時候才能算乘法，而且只能算2的乘法。
假若 2 可以變成任意個數進行想乘，那麼就能代表在ECC曲線里可以進行乘法運算，那麼ECC演算法就能滿足非對稱加密演算法的要求了。
那麼我們是不是可以隨機任何一個數的乘法都可以算呢？ 答案是肯定的。 也就是點倍積 計算方式。
選一個隨機數 k, 那麼k * P等於多少呢？
我們知道在計算機的世界裡，所有的都是二進制的，ECC既然能算2的乘法，那麼我們可以將隨機數k描 述成二進制然後計算。假若k = 151 = 10010111
由於2 P = -Q 所以 這樣就計算出了k P。 這就是點倍積演算法 。所以在ECC的曲線體系下是可以來計算乘法，那麼以為這非對稱加密的方式是可行的。
至於為什麼這樣計算 是不可逆的。這需要大量的推演，我也不了解。但是我覺得可以這樣理解：
我們的手錶上，一般都有時間刻度。現在如果把1990年01月01日0點0分0秒作為起始點，如果告訴你至起始點為止時間流逝了 整1年，那麼我們是可以計算出現在的時間的，也就是能在手錶上將時分秒指針應該指向00：00：00。但是反過來，我說現在手錶上的時分秒指針指向了00：00：00,你能告訴我至起始點算過了有幾年了么？
ECDSA簽名演算法和其他DSA、RSA基本相似，都是採用私鑰簽名，公鑰驗證。只不過演算法體系採用的是ECC的演算法。交互的雙方要採用同一套參數體系。簽名原理如下：
在曲線上選取一個無窮遠點為基點 G = (x,y)。隨機在曲線上取一點k 作為私鑰， K = k*G 計算出公鑰。
簽名過程：
生成隨機數R, 計算出RG.
根據隨機數R,消息M的HASH值H,以及私鑰k, 計算出簽名S = (H+kx)/R.
將消息M,RG,S發送給接收方。
簽名驗證過程：
接收到消息M, RG,S
根據消息計算出HASH值H
根據發送方的公鑰K,計算 HG/S + xK/S, 將計算的結果與 RG比較。如果相等則驗證成功。
公式推論：
HG/S + xK/S = HG/S + x(kG)/S = (H+xk)/GS = RG
在介紹原理前，說明一下ECC是滿足結合律和交換律的，也就是說A+B+C = A+C+B = (A+C)+B。
這里舉一個WIKI上的例子說明如何生成共享秘鑰，也可以參考 Alice And Bob 的例子。
Alice 與Bob 要進行通信，雙方前提都是基於 同一參數體系的ECC生成的 公鑰和私鑰。所以有ECC有共同的基點G。
生成秘鑰階段：
Alice 採用公鑰演算法 KA = ka * G ，生成了公鑰KA和私鑰ka, 並公開公鑰KA。
Bob 採用公鑰演算法 KB = kb * G ，生成了公鑰KB和私鑰 kb, 並公開公鑰KB。
計算ECDH階段：
Alice 利用計算公式 Q = ka * KB 計算出一個秘鑰Q。
Bob 利用計算公式 Q' = kb * KA 計算出一個秘鑰Q'。
共享秘鑰驗證：
Q = ka KB = ka * kb * G = ka * G * kb = KA * kb = kb * KA = Q'
故 雙方分別計算出的共享秘鑰不需要進行公開就可採用Q進行加密。我們將Q稱為共享秘鑰。
在以太坊中，採用的ECIEC的加密套件中的其他內容：
1、其中HASH演算法採用的是最安全的SHA3演算法 Keccak 。
2、簽名演算法採用的是 ECDSA
3、認證方式採用的是 H-MAC
4、ECC的參數體系採用了secp256k1, 其他參數體系 參考這里
H-MAC 全程叫做 Hash-based Message Authentication Code. 其模型如下：
在 以太坊 的 UDP通信時(RPC通信加密方式不同)，則採用了以上的實現方式，並擴展化了。
首先，以太坊的UDP通信的結構如下：
其中，sig是 經過 私鑰加密的簽名信息。mac是可以理解為整個消息的摘要， ptype是消息的事件類型，data則是經過RLP編碼後的傳輸數據。
其UDP的整個的加密，認證，簽名模型如下：
⑶ 測試那些事兒（十三）- 簽名和驗簽、公鑰和私鑰、加密和解密
在做介面測試時，大家一定都遇到過需要提供簽名的場景。這時，我們就會被各種名詞比如 簽名和驗簽、公鑰和私鑰、加密和解密 沖擊。所以，了解一下它們很有必要，可以幫助我們知道為什麼要這么做，而不是簡單的去當一個驗證執行者。甚至，在你了解了它們之後，你也可以在介面的安全性測試上更進一步。
數字簽名其實就是一個別人無法仿造，能夠證明申請者真實性的一段字元串。 我們在真實生活中，最常用的簽名應該就是手簽我們的姓名了。
所以，在介面請求時，很多介面也不是你來一個請求我就給你返回你要的數據，而是要驗證你的簽名，進而證明你的身份後才能做出後續動作。在此過程中，介面調用者需要進行的工作就叫做 簽名 ，而被調用者需要進行的工作就叫做 驗簽 。
公鑰 ：由介面被調用方提供，RSA 密鑰體系中對外公開的部分，通常用於數據加密、驗證數字簽名。
私鑰 ：由介面被調用方提供，RSA 密鑰體系中非公開的部分，需由介面調用方嚴密保存，通常用於數據解密、數據簽名。
這個就很好理解了，傳遞數據時為了保證數據的安全性，不進行明文傳遞，而是通過某種演算法對敏感數據進行 加密 ，傳遞後再由接收方使用對應演算法進行 解密 來獲取明文信息。
將上面的定義總結為圖，會更加的清晰：
之所以用發送方的私鑰加簽，是因為，即便信息被黑客攔截，黑客修改了信息，但是加簽需要用發送方的私鑰，黑客沒有發送方的私鑰，所以也無法生成正確的簽名，接收方驗簽就不用通過。
反之如果用接收方的公鑰加簽，如果信息被黑客攔截，黑客修改了信息，因為接收方的公鑰是公開的，黑客就可以重新生成新的簽名，替換原有的簽名，發送出去，接收方接收到信息，拿自己的公鑰校驗是通過的，所以接收方無法辨別信息是真正的發送方還是黑客發送過來的，這樣的加簽不能辨別信息是否被篡改過。
之所以用接收方的公鑰加密，是因為，如果信息被黑客攔截，需要用接收方的私鑰來解密，黑客無法獲取接收方的私鑰，即便攔截了信息（情報），黑客也無法看到明文，只能看天書?了。
反之，如果用發送方的私鑰加密，如果信息被黑客攔截，因為發送方的公鑰是公開的，黑客就可以用發送方的公鑰解密密文獲得明文，這樣的加密所有的人都可以看到明文，不能保證信息的隱私。
了解了以上這些知識，在測試過程中就可以更加深入的了解簽名的目的，進而可以更深入的了解簽名的實現等。簽名的實現有很多種，這個要根據每個團隊選擇哪種具體分析，但作為測試，基本上我們都是可以按照約定的規則來生成的，這也幫助我們擴展了介面測試覆蓋的廣度（如介面用例覆蓋度、過期時間等隱藏功能），是非常有意義的。
https://blog.csdn.net/liyanlei5858/article/details/84664308
⑷ 四、公鑰和私鑰，加密和數字簽名
本文涉及到支付寶SDK的內容，均摘自支付寶開放平台。
因為支付寶SDK使用RSA來加密和生成數字簽名，所以本文中涉及到的概念也都是針對於RSA的。
一對兒密鑰生成後，會有公鑰和私鑰之分，我們需要把私鑰保存下來，而把公鑰發布出去。一對兒公鑰和私鑰，不能由其中一個導出另一個。
比如使用支付寶SDK的時候，我們商戶端會生成一對兒密鑰A和B，A是私鑰，B是公鑰，支付寶也會生成一對兒密鑰C和D，C是私鑰，D是公鑰。我們商戶端需要把商戶端私鑰A保存下來，而把商戶端公鑰B發布出去給支付寶，支付寶需要把支付寶私鑰C保存下來，而把支付寶公鑰D發布出去給我們商戶端。
加密是指我們使用一對兒密鑰中的一個來對數據加密，而使用另一個來對數據解密的技術，需要注意的是公鑰和私鑰都可以用來加密，也都可以用來解密 ，並不是規定死了只能用公鑰加密私鑰解密，但是加解密必須是一對兒密鑰之間的互相加解密，否則不能成功。
加密的目的是為了保證數據的不可讀性，防止數據在傳輸過程中被截獲。
知道了加密這個概念，我們先看一下支付寶的加密過程，再引出數字簽名這個概念。接著第1小節的例子，當我們商戶端和支付寶互相發布了公鑰之後，我們商戶端手裡就有 商戶端私鑰 和 支付寶公鑰 兩個密鑰，支付寶手裡也有 商戶端公鑰 和 支付寶私鑰 兩個密鑰。現在假設我們商戶端要給支付寶傳輸訂單信息，那麼為了保證傳輸訂單信息時數據的安全性，結合我們商戶端手裡所擁有的密鑰，可以有兩套加密方案
貌似這兩套加密方案都能達到對訂單信息加密的效果，而且如果採用方案二，我們商戶端甚至只需要存儲支付寶公鑰這一個密鑰，都不用去申請一對兒商戶端的公私鑰來維護，支付寶也不用保存我們一堆商戶那麼多的商戶端公鑰了，這不是更簡單嗎，那為什麼支付寶開放平台讓我們採用的是方案一而不是方案二呢？下面來回答一下。
支付寶開放平台說明：當我們採用RSA（1024位密鑰）來加密的時候，支付寶分配給所有商戶的支付寶公鑰都是一樣的，即支付寶針對那麼多的商戶只負責維護一對兒支付寶公私鑰，這就意味著支付寶公鑰隨便什麼人拿到後都是一樣的；而當我們採用RSA2（2048位密鑰）來加密的時候，支付寶會分配給每個商戶單獨的一個支付寶公鑰，即支付寶為每一個的商戶單獨的維護一對獨立的支付寶公私鑰，當然一個商戶下的多個App的支付寶公鑰是一樣的。RSA是早就支持的，RSA2是最近才支持的。
知道了上面這段話，現在假設我們採用的是方案二，並且採用RSA加密（很多老業務並沒有使用RSA2加密），業務邏輯將會是下面這樣。
這就出問題了， RSA加密下，支付寶公鑰是公開發布的，而且所有的商戶用的都是同一個支付寶公鑰（上面聲明了RSA2加密下，支付寶才針對每個商戶維護了一對兒公私鑰），攻擊者很容易就能獲取到，而 notify_url 也很容易被截獲，那攻擊者拿到這兩個東西就可以做和商戶一樣的操作來發起支付請求，這樣就會一直給小明充錢了。
所以 支付寶就需要確認支付請求確實是商戶發給他們的，而不是攻擊者發給他們的。 這就用到了 數字簽名 ，我們會通過方案一的實現流程來引出數字簽名的具體概念。如果我們採用的是方案一，我們商戶端保存的就是商戶端私鑰和支付寶公鑰，而支付寶保存的就是需要存著商戶端公鑰和支付寶私鑰的，業務邏輯將會是下面這樣。
這樣就可以保證交易的安全性了，我們也可以看出使用支付寶SDK保證交易的安全性注重的其實不是訂單信息是否加密，而是如何確保商戶端和支付寶能夠互相確認身份，訂單信息是明文的，但是後面拼接了數字簽名。
數字簽名其實就是明文數據加密之後得到的一個密文，只不過它是用私鑰加密生成的而已，我們一般會把數字簽名拼接在明文數據後面一起傳遞給接收方，接收方收到後用公鑰解密數字簽名，從而驗證發送方的身份、以及明文數據是否被篡改。數字簽名的生成過程其實就是一個加密過程，數字簽名的驗簽過程就是一個解密過程。
數字簽名的目的有兩個：一、發送方和接收方互相驗證身份；二、驗證數據是否被篡改。
從上面第一部分我們知道為了確保商戶和支付寶交易的安全性，約定採用的是給訂單信息加數字簽名傳輸的方式。支付寶也為我們提供了 一鍵生成RSA密鑰的工具 ，可以幫助我們很快的生成一對商戶端公私鑰。以下會對支付寶SDK的支付流程做個大概的解釋，並點出實際開發中我們使用支付寶SDK時應該注意的地方。
由我們商戶端自己生成的RSA私鑰（必須與商戶端公鑰是一對），生成後要保存在服務端，絕對不能保存在客戶端，也絕對不能從服務端傳輸給客戶端。
用來對訂單信息加簽，加簽過程一定要在服務端完成，絕對不能在客戶端做加，客戶端只負責用加簽後的訂單信息調起支付寶來支付。
由我們商戶端自己生成的RSA公鑰（必須與商戶端私鑰是一對），生成後需要填寫在支付寶開放平台。
用來給支付寶服務端驗簽經過我們加簽後的訂單信息，以確保訂單信息確實是我們商戶端發給支付寶的，並且確保訂單信息在傳輸過程中未被篡改。
這個和我們就沒關系了，支付寶私鑰是他們自己生成的，也是他們自己保存的。
用來對支付結果進行加簽。
支付寶公鑰和支付寶私鑰是一對，也是支付寶生成的，當我們把商戶端公鑰填寫在支付寶開放平台後，平台就會給我們生成一個支付寶公鑰，我們可以復制下來保存在服務端，同樣不要保存在客戶端，並且不要傳輸給客戶端。
用來讓服務端對支付寶服務端返給我們的同步或非同步支付結果進行驗簽，以確保支付結果確實是由支付寶服務端返給我們服務端的，而且沒有被篡改，對支付結果的驗簽工作也一定要在服務端完成。
上面已經說過了： 訂單信息的加簽和支付結果的驗簽是一定要在服務端做的，絕對不能在客戶端做。
下面是在客戶端對訂單信息加簽的過程，僅僅是為了模擬服務端來表明訂單信息是如何通過加簽最終轉變為orderString的， 千萬不要覺得訂單信息的加簽過程也可以放在客戶端完成 。
假設我們服務端收到了來自支付寶服務端的支付結果，即： 支付結果+數字簽名 。
那麼我們服務端就會對支付結果進行驗簽，怎麼個驗法呢？
⑸ 加密和簽名公鑰私鑰問題
數字簽名主要經過以下幾個過程：信息發送者使用一單向散列函數（HASH函數）對信息生成信息摘要；信息發送者使用自己的私鑰簽名信息摘要；信息發送者把信息本身和已簽名的信息摘要一起發送出去；信息接收者通過使用與信息發送者使用的同一個單向散列函數（HASH函數）對接收的信息本身生成新的信息摘要，再使用信息發送者的公鑰對信息摘要進行驗證，以確認信息發送者的身份和信息是否被修改過。數字加密主要經過以下幾個過程：當信息發送者需要發送信息時，首先生成一個對稱密鑰，用該對稱密鑰加密要發送的報文；信息發送者用信息接收者的公鑰加密上述對稱密鑰；信息發送者將第一步和第二步的結果結合在一起傳給信息接收者，稱為數字信封；信息接收者使用自己的私鑰解密被加密的對稱密鑰，再用此對稱密鑰解密被發送方加密的密文，得到真正的原文。數字簽名和數字加密的過程雖然都使用公開密鑰體系，但實現的過程正好相反，使用的密鑰對也不同。數字簽名使用的是發送方的密鑰對，發送方用自己的私有密鑰進行加密，接收方用發送方的公開密鑰進行解密，這是一個一對多的關系，任何擁有發送方公開密鑰的人都可以驗證數字簽名的正確性。數字加密則使用的是接收方的密鑰對，這是多對一的關系，任何知道接收方公開密鑰的人都可以向接收方發送加密信息，只有唯一擁有接收方私有密鑰的人才能對信息解密。另外，數字簽名只採用了非對稱密鑰加密演算法，它能保證發送信息的完整性、身份認證和不可否認性，而數字加密採用了對稱密鑰加密演算法和非對稱密鑰加密演算法相結合的方法，它能保證發送信息保密性。
⑹ 關於RSA中公鑰和私鑰的具體使用情況區分
公鑰和私鑰在一些銀行系統、第三方支付系統SDK中經常會遇到，剛接觸公鑰私鑰的朋友們估計很難區分兩者的區別。
RSA公鑰和私鑰是什麼？
首先來說，RSA是一種非對稱加密演算法，它是由三位數學家（Rivest、Shamir、Adleman）設計出來的。非對稱加密是相對於對稱加密而言的。對稱加密演算法是指加密解密使用的是同一個秘鑰，而非對稱加密是由兩個密鑰（公鑰、私鑰）來進行加密解密的，由此可見非對稱加密安全性更高。
公鑰顧名思義就是公開的密鑰會發放給多個持有人，而私鑰是私有密碼往往只有一個持有人。
公私鑰特性
公鑰和私鑰都可用於加密和解密
公鑰和私鑰都可以用於加解密操作，用公鑰加密的數據只能由對應的私鑰解密，反之亦然。雖說兩者都可用於加密，但是不同場景使用不同的密鑰來加密，規則如下：
1、私鑰用於簽名、公鑰用於驗簽
簽名和加密作用不同，簽名並不是為了保密，而是為了保證這個簽名是由特定的某個人簽名的，而不是被其它人偽造的簽名，所以私鑰的私有性就適合用在簽名用途上。
私鑰簽名後，只能由對應的公鑰解密，公鑰又是公開的（很多人可持有），所以這些人拿著公鑰來解密，解密成功後就能判斷出是持有私鑰的人做的簽名，驗證了身份合法性。
2、公鑰用於加密、私鑰用於解密，這才能起到加密作用
因為公鑰是公開的，很多人可以持有公鑰。若用私鑰加密，那所有持有公鑰的人都可以進行解密，這是不安全的！
若用公鑰加密，那隻能由私鑰解密，而私鑰是私有不公開的，只能由特定的私鑰持有人解密，保證的數據的安全性。
⑺ 「數字簽名技術採用的是公鑰體制,它是用私鑰進行加密」的對不
對。
公鑰體制是數字簽名的基礎，數字簽名就是使用數字證書的私鑰對數據的摘要加密，以保證數據的完整性、真實性和不可抵賴。
⑻ 加密和簽名的區別
加密是對信息的加密，比如A給B發消息則會使用b的公鑰加密，發送後只能使用B的私鑰才能解密。
簽名，是給信息加個身份，是由誰發送的。一般用私鑰生成。A給B發送，A使用自己的私鑰簽名，B收到後用A的公鑰解密，來確認是不是A發的。
對稱加密:是加密解密使用相同的密鑰。
優使用簡卜薯單快捷高效。
缺加密強度不高，密鑰分發困難
DES採用替換和移位，密鑰56位，每次對64位數據塊加密。
3DES使喚弊鬧用兩個密鑰K1,k2,
加密時k1加密，k2解密，k1加密
解密時k1解密，k2加密，k1解密
rc-5:rsa 數據安全公司很多產品使用了rc-5
idea:密鑰是128位每次對64位數據塊加密。
非對稱加密:一個公鑰一個私鑰
優:解決了加密強度不高，密鑰分發困難的問題
缺:加密速度慢
rsa:512位密鑰，計算量大，難破解。
ecc:橢圓體制曲線密碼
信息摘要:一份長文件的數字指紋，可以用於創建數字簽名
md5 128位散列值
sha 160位散列值
md5+salt
簡單的md5密碼加和罩密，黑客可以通過密碼md5比較，可以輕松試出密碼。
如果加上salt，密碼加密之前拼接上salt,之後再散列。
黑客用自己密碼和salt值試，就很難找到密碼。
⑼ 理解兩種加密方式中私鑰和公鑰的概念
私鑰加密演算法 ，又稱 對稱加密演算法 ，因為這種演算法解密密鑰和加密密鑰是相同的。也正因為同一密鑰既用於加密又用於解密，所以這個密鑰是不能公開的。常見的有《 DES加密演算法 》、《 AES加密演算法 》。
公鑰和私鑰成對出現
公開的密鑰叫公鑰，只有自己知道的叫私鑰
用公鑰加密的數據只有對應的私鑰可以解密
用私鑰加密的數據只有對應的公鑰可以解密
如果可以用公鑰解密，則必然是對應的私鑰加的密
如果可以用私鑰解密，則必然是對應的公鑰加的密
公鑰和私鑰是相對的，兩者本身並沒有規定哪一個必須是公鑰或私鑰。
要實現數據的安全傳輸，當然就要對數據進行加密了。
如果使用對稱加密演算法，加解密使用同一個密鑰，除了自己保存外，對方也要知道這個密鑰，才能對數據進行解密。如果你把密鑰也一起傳過去，就存在密碼泄漏的可能。所以我們使用 非對稱演算法 ，過程如下：
首先 接收方 生成一對密鑰，即私鑰和公鑰；
然後，接收方 將公鑰發送給 發送方；
發送方用收到的公鑰對數據加密，再發送給接收方；
接收方收到數據後，使用自己的私鑰解密。
由於在非對稱演算法中，公鑰加密的數據必須用對應的私鑰才能解密，而私鑰又只有接收方自己知道，這樣就保證了數據傳輸的安全性。
除了保證數據的安全傳輸之外，公鑰體系的另一個用途就是對數據進行簽名。通常 「數字簽名」 是用來驗證發送方的身份並幫助保護數據的完整性。
例如：一個發送者 A 想要傳些資料給大家，用自己的私鑰對資料加密，即簽名。這樣一來，所有收到資料的人都可以用發送者的公鑰進行驗證，便可確認資料是由 A 發出來的了。（因為只有A使用私鑰簽名得到的信息，才能用這個公鑰來解） 採用數字簽名，可以確認兩點：
保證信息是由簽名者自己簽名發送的，簽名者不能否認或難以否認。
保證信息自簽發辯巧後到收到為止未曾作過任何修改。
之所以可以確認這兩點，是因為用公鑰可以解密的必然是用對應的私鑰加的密，而私鑰只有簽名者持有。
四、公鑰演算法的缺點
現實中，公鑰機制也有它的缺點，那就是 效率非常低 ，比常用的私鑰演算法（如 DES 和 AES）慢上一兩個數量級都有可能。所以它不適合為大量的原始信息進行加密。為了同時兼顧安全和效率，我們通常結合使用公鑰演算法和私鑰演算法：
首先，發送方使用對稱演算法對原始信息進行加密。
接收方通過公鑰機制生成一對密鑰，一個公鑰，一個私鑰。
接收方 將公鑰發送給 發送方。
發送方用公鑰對對稱演算法的密鑰進行加密，並發送給接收方。
接收方用私鑰進行解密得到對稱演算法的密鑰。
發送方再把已加密的原始信息發送給接穗灶粗收方。
接收方使用對稱猜鎮演算法的密鑰進行解密。
⑽ 公鑰與私鑰用於加解密和簽名
公鑰：公開持有，每個人都可以獲得。
私鑰：個人持有，需要保密不能泄露。
公鑰加密，私鑰解密
信息從公鑰持有者中的某一個向私鑰持有者發送。
加解密是為了讓通信的第三方無法獲取消息內容。
私鑰簽名，公鑰驗簽
信息從私鑰持有者向公鑰持有者中的某一個發送。
簽名是為了證明消息發送者的身份合法，即是「我」本人而不是其他人冒充我發送的消息。（但這個消息可能是公開的，如果希望加密發送，則需要另外一對兒公鑰和私鑰反方向持有，完成加解密過程）
私鑰和公鑰是一對，誰都可以加解密，只是誰加密誰解密是看情景來用的：
第一種情景是簽名,使用私鑰加密,公鑰解密,用於讓所有公鑰所有者驗證私鑰所有者的身份並且用來防止私鑰所有者發布的內容被篡改.但是不用來保證內容不被他人獲得。
第二種情景是加密,用公鑰加密,私鑰解密,用於向公鑰所有者發布信息,這個信息可能被他人篡改,但是無法被他人獲得。
比如加密情景：
如果甲想給乙發一個安全的保密的數據,那麼應該甲乙各自有一個私鑰,甲先用乙的公鑰加密這段數據,再用自己的私鑰加密這段加密後的數據.最後再發給乙,這樣確保了內容即不會被讀取,也不會被篡改。
英文版： http://www.youdzone.com/signature.html
中文版： http://www.blogjava.net/yxhxj2006/archive/2012/10/15/389547.html
https://www.hu.com/question/25912483