android數據加密傳輸

A. android怎麼對文件，數據加密傳輸到伺服器

我知道有款軟體，MISUO，這款軟體是可以針對所有的安卓系統知段進行數據加密的、
但是你描述的問題不是很清楚，所以不知穗配道需要達到的具體效果是什麼樣的，不過建議猜猛指你可以下載試用一下

B. Android之網路—第二篇（Https原理）

Android之網路—第一篇（Http原理）
Android之網路—第二篇（Https原理）
Android之網路—第三篇（解讀OkHttp）
Android之網路—第四篇（解讀Retrofit）

說的通俗一點就是身披安全衣的Http，本質還是http，只是在http外層嵌套了一個SSL/TLS的安全層，該層做了一些數據的加解密處理。

在講解Https原理之前，先做點准備工作，因為會涉及到SSL/TLS連接建立、SSL/TLS加解密方面的知識。所以會整體從網路架構和比較重要的知識點回顧下網路知識。

在講解什麼是SSL/TLS之前，回顧下TCP/IP協議的分層概念。通常一個網路的傳輸中間會經過很多的傳輸節點，才最終達到伺服器。期間過程會包含數據的拆分和拼裝、IP的解析、數據的傳輸等等操作，但是網路傳輸是很不穩定的，如果這次網路請求在中間的某一節點失敗了，難道還要重新再發送一遍么？答案是不應該這么做。

為了網路傳輸的統一規范，就設計了這么一套網路通信的規范，每一層都專注做一件事情，即使當前失敗了，也在這層做處理就可以了，盡量避免重發。

簡單解釋下，每層的含義：

通過上圖發現，數據是由上往下傳遞後，再由下往回傳遞。這是怎麼回事呢？總結就是：在 TCP / IP協議中數據先由上往下將數據裝包，然後由下往上拆包。在裝包的時候，每一層都會增加一些信息用於傳輸，這部分信息就叫報頭，當上層的數據到達本層的時候，會將數據加上本層的報頭打包在一起，繼續往下傳遞。在拆包的時候，每一層將本層需要的報頭讀取後，就將剩下的數據往上傳。

簡要分析下傳輸過程：

這里簡單總結下傳輸層的兩種連接方式：TCP和UDP

三次握手：客戶端主動打開連接，伺服器被動打開連接。

四次揮手：客戶端主動關閉，伺服器被動關閉

說個概念性的東西就是，現代密碼學分為對稱加密和非對稱加密，跟傳統密碼學不一樣的地方就是，除了可以加密文字內容外，還可以用於各種二進制數據的加解密。

通信雙方使用同一個密鑰，使用加密演算法配合上密鑰來加密，解密時使用解密演算法（加密過程的完全逆運算）配合密鑰來進行解密。常用的經典演算法：DES（56 位密鑰，密鑰太短而逐漸被棄用）、AES（128 位、192 位、256 位密鑰，現在最流行）。

通信雙方使用公鑰和加密演算法對數據進行加密得到密文；使用私鑰和加密演算法對數據進行解密得到原數據。常用的經典演算法：RSA（可用於加密和簽名）、DSA（僅用於簽名，但速度更快）。

這個有什麼用？其實這個就是後面Https加解密的原理。原理這么簡單么？是的，就這么簡單。但是要理解還得慢慢往下看。

A用自己的私鑰通過加密演算法得到的數據密文數據，這個數據就可以稱為簽過名。接收方B再用A提供的公鑰通過加密演算法就可以還原數據，從而就驗證了數據的真實性。因為只有A一個人擁有自己的私鑰。

到這里咱們就可以聊聊剛才中間人偽造數據是如何處理了。通過對稱加密可以防止中間人偷窺數據，通過數字簽名可以防止中間人篡改偽造數據。

但是完整版的簽名信息需要將簽名數據取Hash值，減少數據大小

好了，看完理解了上面的知識點，到這里我們可以慢慢分析Https是如何工作的了。

先來總結一句話：Https的本質就是在客戶端和服務端之間用非對稱加密協商出一套對稱密鑰，每次發送信息之前將內容加密，接收後解密，達到內容的加密傳輸。解釋下，就是整個數據的傳輸過程是用對稱加密的方式來傳輸的，只是密鑰的生成是由客戶端和服務端 在創建連接的時候 通過 非對稱加密的方式 協商生成的。

那這里就會有一系列的問題啦：
Q：為什麼不直接用非對稱加密的方式直接加密呢？
A：因為非對稱加密的計算過程是復雜的數學運算，太復雜了，很慢。
Q：哦哦，那既然使用對稱加密的話，這個對稱密鑰是怎麼來的？
A：在實際的場景中，服務端會對接N個客戶端，這個對稱密鑰如果都使用同一個密鑰來通信的話，肯定是不合理的，只要破解了其中一個，其他所有的都會被破解。所以整體的網路架構應該是使用不同加密方式用不同的密鑰來進行數據傳輸的。模型如下圖

Q：但是在網路場景中，對稱加密的密鑰是不能直接在網路上傳輸的。服務端和客戶端是如何都知道的呢？
A：這個是服務端和客戶端一起協商根據只有它倆知道的規則分別生成，就不用通過網路傳輸啦。
Q：如果保證它倆協商出來的密鑰不被破解呢？
A：當然是使用非對稱加密的方式啦。通過之前的加密知識，可以知道非對稱加密是目前來說是絕對安全的。而且一個私鑰可以有多個公鑰，正好滿足一個服務端對N個客戶端的場景。模型如下圖：

實際在協商通訊的過程中，這個公鑰是服務端給客戶端發送的。而且需要注意 這個公鑰是用來協商生成對稱密鑰的，不是用來做數據的加密傳輸的 。

Q：哦哦，原來是這樣，但是這樣子還是有問題啊，客戶端與服務端在協商生成密鑰的過程中為了保證數據被偷窺和被篡改的風險，一般會要求有兩套公鑰和私鑰分別做加解密和簽名驗證處理的，上面的模型只有一套公鑰和私鑰，沒法規避數據被被篡改的風險呀。
A：能提出這個問題，說明之前的學習理解得很好。從上面的模型，可以保證在協商的過程中客戶端A/B/C/D分別向伺服器傳輸的數據是安全。但是伺服器發送給客戶端的數據是如何保證的呢？換句話說就是，客戶端如何驗證數據是服務端發送過來的，而不是被中間假冒掉包的數據。這不就是之前講的數字簽名的內容么？而實際情況中，就是通過CA證書來處理這個問題的。
Q：那這個CA證書是怎麼驗證的呢？
A：請看下面的CA證書的分析。

回歸之前的分析，我們的問題點卡在了「伺服器發送給客戶端的數據是如何保證的呢」。對吧。實際上在協商通信的過程中，服務端會先給客戶端下發證書信息，這個證書信息裡面會包含非對稱加密的公鑰。但是考慮一個問題，如何保證這個公鑰就是客戶端要的公鑰呢？或者說怎麼保證這個證書就是真實的證書，而不是被篡改假冒的證書。只有驗證了這一步，客戶端才完全信賴服務端，才給伺服器發消息，也才接受伺服器的消息。這時候就只需要一套公鑰和私鑰客戶端和服務端就可以通信了。

Q：那客戶端如何驗證服務端下發的證書和公鑰是正確的呢？
A：先換個概念，將證書裡面的公鑰假設為一串數據。要驗證這個數據，只需要提供這串數據的簽名以及加密這段數據的簽名的私鑰對應的公鑰就可以了，如下圖框框所示。

Q：那這樣子又有另外的一個問題產生了怎麼去驗證 這段數據的簽名的私鑰對應的公鑰 了？
A：同樣的，也是需要提供對應的簽名和對應簽名的私鑰對應的公鑰。

Q：但是這樣子下去就會變成一個循環了，怎麼辦？
其實在這里還會有一個場景問題：第三方簽發機構不可能只給你一家公司製作證書，它也可能會給中間人這樣有壞心思的公司發放證書。這樣的，中間人就有機會對你的證書進行調包，客戶端在這種情況下是無法分辨出是接收的是你的證書，還是中間人的。因為不論中間人，還是你的證書，都能使用第三方簽發機構的公鑰進行解密。

A：是的，為處理這個問題，就需要講一個根證書的東西。先舉個例子：假設你是HR，你手上拿到候選人的學歷證書，證書上寫了持證人，頒發機構，頒發時間等等，同時證書上，還寫有一個最重要的：證書編號！我們怎麼鑒別這張證書是的真偽呢？只要拿著這個證書編號上相關機構去查，如果證書上的持證人與現實的這個候選人一致，同時證書編號也能對應上，那麼就說明這個證書是真實的。同樣的，Https請求驗證時，會用到手機操作系統內置的根證書去驗證這個證書的真偽的。

到這里就簡要分析完了證書的驗證過程。證書會包含很多信息，包括伺服器公鑰，伺服器名字，伺服器地區等等信息。這個是沒法篡改的。其中對Https連接來說最重要的就是伺服器的公鑰。

之前學習完TCP的連接過程，現在我們開始來嘮嘮Https連接。什麼是Https連接呢？准確來說就是SSL/TLS加解密層的連接。

大致的建立流程：

詳細的建立流程：

客戶端MAC secret，服務端MAC secret的主要作用：用來認證這個消息是正確的，完整的，解決對稱加密方式沒法驗證消息的缺點。

至此完整的Https在TLS層連接過程分析完畢。

如果覺得我的文章對你有幫助，請隨意贊賞。您的支持將鼓勵我繼續創作！

C. 每日一問(二十)Android網路數據的加密方式

對稱加密行扮：加密和解密數據都是使用同一個key，這方面的演算法有DES。

非對稱加密：加密和解密是使用不同的key。發氏帶畢送數據之前要先和服務端約定生成公鑰和私鑰，使用公鑰加密的數據可以用私鑰解密，反之。這方面的演算法有RSA。ssh 和 ssl都是典殲芹型的非對稱加密。

D. Android 的幾種加密方式

Android 中的最常用得到有三種加密方式：MD5,AES,RSA.

1.MD5

MD5本質是一種散列函數，用以提供消息的完整性保護。

特點：

1.壓縮性：任意長度的數據，算出的MD5值長度都是固定的；

2.容易計算：從原數據計算出MD5值很容易；

3.抗修改性：對原數據進行任何改動，哪怕只修改一個位元組，所得到的MD5值都有很大的區別

4.強抗碰撞：已知原數據和其MD5值，想找到一個具有相同MD5值的數據（及偽造數據）是非常困難的；

2.RSA加密

RSA加密演算法是一種非對稱加密演算法，非對稱加密演算法需要兩個密鑰：公共密鑰和私有密鑰。公鑰和私鑰是配對的，用公鑰加密的數據只有配對的私鑰才能解密。

RSA對加密數據的長度有限制，一般為密鑰的長度值-11，要加密較長的數據，可以採用數據截取的方法，分段加密。

3.AES加密

AES加密是一種高級加密的標准，是一種區塊加密標准。它是一個對稱密碼，就是說加密和解密用相同的密鑰。WPA/WPA2經常用的加密方式就是AES加密演算法。

E. 安卓網路請求數據時如何保證數據的完整性和安全性使用哪種加密

通過網路傳輸數據，需要保證數據的完整性、保密性，以及能夠對數據的發送者進行身份驗證。這些都需要通過一些加密演算法實現。

對稱加密：
加密和解密使用同一個密鑰，特點：保證了數據的保密性。局限性：無法解決密鑰交換問題。常用的演算法有：DES,3DES,AES;

公鑰加密：
生成一個密鑰對（私鑰和公鑰），加密時用私鑰加密，解密時用公鑰解密，特點：解決了密鑰交換問題。局限性：對大的數據加密速度慢。

單向加密：
提取數據的特徵碼，特點：定長輸出，不可逆，可檢驗數據的完整性。局限性：無法保證數據的保密性。常用演算法：MD5、SHA1、CRC-32。

三種加密方法各有優缺點，在時實際應用中，數據從發送方到達接收方，通常是這樣應用的：

1) 首先對要發送的數據做單向加密，獲取數據的特徵碼；

2) 對特徵碼用發送方的私鑰進行加密生成S1；

3) 然後對S1和數據進行對稱加密生成S2；

4) 最後將S2和對稱加密的密碼使用接收方的公鑰進行加密。

這樣一來數據在傳輸過程中的完整性、保密性以及對發送方身份的驗證都能得到保障。

當數據到達接收方時，接收方先用自己的私鑰對接收到的數據進行解密，得到密碼和加密的數據；使用密碼對加密數據解密，得到加密的特徵碼和數據；用發送方的公鑰解密特徵碼，如果能解密，則說明該數據是由發送方所發；反之則不是，這便實現了身份驗證；最後計算數據的特徵碼和解密出來的特徵碼做對比，如果一樣，則該數據沒有被修改；反之則數據被修改過了。

F. android 介面數據如何加密

方法步驟如下：

1.選擇要發布的項目，右鍵如下：

7.點擊Finish完成發布，在相應的位置生成兩個文件為：

XX.apk和步驟4所起的文件名。

G. Android Okhttp/Retrofit網路請求加解密實現方案

比較安全的方案應該是AES+RSA的加密方式。具體如下圖所示。

為什麼要這樣做呢？
1、RSA是非對稱加密，公鑰和私鑰分開，且公鑰可以公開，很適合網路數據傳輸場景。但RSA加密比較慢，據說比AES慢100倍，且對加密的數據長度也有限制。
2、AES是對稱加密，加密速度快，安全性高，但密鑰的保存是個問題，在網路數據傳輸的場景就很容易由於密鑰泄露造成安全隱患
3、所以，AES+RSA結合才更好，AES加密數據，且密鑰隨機生成，RSA用對方（伺服器）的公鑰加密隨機生成的AES密鑰。傳輸時要把密文，加密的AES密鑰和自己的公鑰傳給對方（伺服器）。對方（伺服器）接到數據後，用自己的私鑰解密AES密鑰，再拿AES密鑰解密數據得到明文。這樣就綜合了兩種加密體系的優點。
4、除上面說的外，還可以加簽名，即對傳輸的數據（加密前）先做個哈希，然後用自己的RSA私鑰對哈希簽名（對方拿到自己的公鑰可以驗簽），這樣可以驗證傳輸內容有沒有被修改過。

就java來說，加密的輸入和輸出都是位元組數組類型的，也就是二進制數據，網路傳輸或本地保存都需要重新編碼為字元串。推薦使用Base64。Android 有自帶的Base64實現，flag要選Base64.NO_WRAP，不然末尾會有換行影響服務端解碼。
Android中Base64加密

總而言之，這些不同語言都有實現庫，調用即可，關鍵是參數要一致，具體還需要和後台聯調一下。
rsa加解密的內容超長的問題解決

現在說到網路框架，應該毫無疑問是Retrofit了。上面說的加密方案說到底還是要在網路請求框架內加上，怎麼做入侵最小，怎麼做最方便才是重點。
1、坑定不能直接在介面調用層做加密，加參數，這樣每個介面都要修改，這是不可能的。
2、ConverterFactory處理，這也是網上可以搜到的很多文章的寫法，但我覺得還是有入侵。而且有點麻煩。
3、OkHttp添加攔截器，這種方法入侵最小（可以說沒有），實現呢也非常優雅。
下面的實現，網上也找不到多少可以參考的文章，但不得不說，OkHttp的封裝和設計真的很好用，所見即所得。看下源碼，就知道該怎麼用了，連文檔都不用查。

主要注意點：
0、和介面無關的新加的數據放在請求頭里。
1、該close的要close，不然會內存泄漏。
2、新舊Request和Response要區分好，新的要替換舊的去傳遞或返回。
3、要對response.code()做處理，只有在和後台約定好的返回碼下才走解密的邏輯，具體看自己的需求，不一定都是200。

H. Android網路請求加密機制

密碼學的三大作用：加密（ Encryption）、認證（Authentication），鑒定（Identification）

加密 ：防止壞人獲取你的數據。 

鑒權 ：防止壞人假冒你的身份。

認證 ：防止壞人修改了你的數據而你卻並沒有發現。

1. URLEncode和URLDecoder 作用：URLEncode就是將URL中特殊部分進行編碼。URLDecoder就是對特殊部分進行解碼。

為什麼URL要encode原因呢？

url轉義其實也只是為了符合url的規范而已。因為在標準的url規范中 中文和很多的字元 是不允許出現在url中的。

2. Base64編碼

為什麼要進行Base64編碼？

在計算機中任何數據都是按ascii碼存儲的，而ascii碼的128～255之間的值是不可見字元。而在網路上交換數據時，比如攔薯枝說從A地傳到B地，往往要經過多個路由設備，由於手腔不同的設備對字元的處理方式有一些不同，這樣那些不可見字元就有可能被處理錯誤，這是不利於傳輸的。所以簡敏就先把數據先做一個Base64編碼，統統變成可見字元，這樣出錯的可能性就大降低了。

應用場景：主要是對於二進制數據進行編碼，（文件、圖片、加密後的二進制數據）

3. 消息認證演算法

要確保加密的消息不是別人偽造的，需要提供一個消息認證碼（MAC，Message authentication code） 。 

消息認證碼是帶密鑰的hash函數，基於密鑰和hash函數(單向散列函數）。

密鑰雙方事先約定，不能讓第三方知道。

消息發送者使用MAC演算法計算出消息的MAC值，追加到消息後面一起發送給接收者。 

接收者收到消息後，用相同的MAC演算法計算接收到消息MAC值，並與接收到的MAC值對比是否一樣。

消息認證碼的作用：檢查某段消息的完整性，以及作身份驗證。

防止重放 攻擊可以有 3 種方法：

序號

每條消息都增加一個遞增的序號，並且在計算 MAC 值的時候把序號也包含在消息中。這樣攻擊者如果不破解消息認證碼就無法計算出正確的 MAC 值。這個方法的弊端是每條消息都需要多記錄最後一個消息的序號。

時間戳

發送消息的時候包含當前時間，如果收到的時間與當前的不符，即便 MAC 值正確也認為是錯誤消息直接丟棄。這樣也可以防禦重放攻擊。這個方法的弊端是，發送方和接收方的時鍾必須一致，考慮到消息的延遲，所以需要在時間上留下一定的緩沖餘地。這個緩沖之間還是會造成重放攻擊的可趁之機。

nonce

在通信之前，接收者先向發送者發送一個一次性的隨機數 nonce。發送者在消息中包含這個 nonce 並計算 MAC 值。由於每次 nonce 都會變化，因此無法進行重放攻擊。這個方法的缺點會導致通信的數據量增加。

4. 對稱加密演算法

特點：加解密只有一個密鑰。優點：速度快、效率高。缺點：密鑰交換問題。演算法：AES(256位元組,主流）、DES（8位元組，淘汰）。

密鑰交換問題如何解決，MAC同樣也有這個問題，可以使用非對稱加密傳輸，或者私下約定，密鑰管理中心。

5. 非對稱加密

非對稱加密演算法需要兩個密鑰：公開密鑰（publickey）和私有密鑰（privatekey）。公開密鑰與私有密鑰是一對，如果用公開密鑰對數據進行加密，只有用對應的私有密鑰才能解密；如果用私有密鑰對數據進行加密，那麼只有用對應的公開密鑰才能解密（這個過程可以做數字簽名） 。 非對稱加密主要使用的是RSA演算法。

特點：公/私鑰機制。優點：只需要交換公鑰，安全。缺點：加解密速度慢，特別是解密。演算法：RSA。應用：數字簽名。

數字簽名 ：

簡單解釋：

A：將明文進行摘要運算後得到摘要（消息完整性），再將摘要用A的私鑰加密（身份認證），得到數字簽名，將密文和數字簽名一塊發給B。

B：收到A的消息後，先將密文用自己的私鑰解密，得到明文。將數字簽名用A的公鑰進行解密後，得到正確的摘要（解密成功說明A的身份被認證了）。

數字證書 ：

6. Android端 AES+RSA結合實踐

基本流程

Android端

伺服器端

基本上如下圖所示的流程：

I. Android使用RSA加密和解密

1.data是要加密的數據，如果是字元串則getBytes。publicKey是公鑰，privateKey是私鑰。自定義密鑰對測試

2.從文件中讀取公鑰

當加密的數據過長時，會出現javax.crypto.IllegalBlockSizeException: Data must not be longer than 117 bytes的異常。rsa演算法規定一次加密的數據不能超過生成密鑰對時的keyLength/8-11，keyLength一般是1024個位元組，則加密的數據不能超過117個位元組

測試分段加密和解密

生成公鑰和私鑰後，用base64編碼

一、android加密的數據伺服器上無法解密？
android的rsa加密方式是RSA/ECB/NoPadding，而標准jdk是RSA/ECB/PKCS1Padding，所以加密時要設置標准jdk的加密方式

二、base64編碼。因為不同的設備對字元的處理方式不同，字元有可能處理出錯，不利於傳輸。所以先把數據做base64編碼，變成可見字元，減少出錯
官方提供的base64類，Base64.encode編碼，Base64.decode解碼。用這個會有換行符，需要自定義

三、rsa是非對稱加密演算法。依賴於大數計算，加密速度比des慢，通常只用於加密少量數據或密鑰

四、公鑰加密比私鑰加密塊，公鑰解密比私鑰解密慢。加密後的數據大概是加密前的1.5倍

J. Android加密演算法總結

1.概念：
Base64是一種用64個字元(+/)來表示二進制數據的方法，只是一種編碼方式，所以不建議使用Base64來進行加密數據。

2.由來：
為什麼會有Base64編碼呢？因為計算機中數據是按ascii碼存儲的，而ascii碼的128～255之間的值是不可見字元。在網路上交換數據時，比如圖片二進制流的每個位元組不可能全部都是可見字元，所以就傳送不了。最好的方法就是在不改變傳統協議的情況下，做一種擴展方案來支持二進制文件的傳送，把不可列印的字元也能用可列印字元來表示，所以就先把數據先做一個Base64編碼，統統變成可見字元，降低錯誤率。

3.示例：

加密和解密用到的密鑰是相同的，這種加密方式加密速度非常快，適合經常發送數據的場合。缺點是密鑰的傳輸比較麻煩。

1.DES
DES全稱為Data Encryption Standard，即數據加密標准，是一種使用 密鑰加密 的塊演算法。
DES演算法把64位的明文輸入塊變為64位的密文輸出塊，它所使用的密鑰也是64位，密鑰事實上是56位參與DES運算（第8、16、24、32、40、48、56、64位是校驗位，使得每個密鑰都有奇數個1）分組後的明文組和56位的密鑰按位替代或交換的方法形成密文組的加密方法。

2.3DES
3DES（或稱為Triple DES）是三重 數據加密演算法 （TDEA，Triple Data Encryption Algorithm）塊密碼的通稱。是DES向AES過渡的加密演算法，它使用3條56位的密鑰對數據進行三次加密。是DES的一個更安全的變形。它以DES為基本模塊，通過組合分組方法設計出分組加密演算法。比起最初的DES，3DES更為安全。

3.AES
AES全稱Advanced Encryption Standard，即高級加密標准，當今最流行的對稱加密演算法之一，是DES的替代者。支持三種長度的密鑰：128位，192位，256位。

AES演算法是把明文拆分成一個個獨立的明文塊，每一個明文塊長128bit。這些明文塊經過AES加密器的復雜處理，生成一個個獨立的密文塊，這些密文塊拼接在一起，就是最終的AES加密結果。
但是這里涉及到一個問題：假如一段明文長度是192bit，如果按每128bit一個明文塊來拆分的話，第二個明文塊只有64bit，不足128bit。這時候怎麼辦呢？就需要對明文塊進行填充（Padding）：

AES的工作模式，體現在把明文塊加密成密文塊的處理過程中。

加密和解密用的密鑰是不同的，這種加密方式是用數學上的難解問題構造的，通常加密解密的速度比較慢，適合偶爾發送數據的場合。優點是密鑰傳輸方便。

1.SHA
安全散列演算法（英語：Secure Hash Algorithm，縮寫為SHA）是一個密碼散列函數家族，是FIPS所認證的安全散列演算法。能計算出一個數字消息所對應到的，長度固定的字元串（又稱消息摘要）的演算法，且若輸入的消息不同，它們對應到不同字元串的機率很高。
SHA分為SHA-1、SHA-224、SHA-256、SHA-384，和SHA-512五種演算法，後四者有時並稱為SHA-2。SHA-1在許多安全協定中廣為使用，包括TLS和SSL、PGP、SSH、S/MIME和IPsec，曾被視為是MD5（更早之前被廣為使用的雜湊函數）的後繼者。但SHA-1的安全性如今被密碼學家嚴重質疑；雖然至今尚未出現對SHA-2有效的攻擊，它的演算法跟SHA-1基本上仍然相似；因此有些人開始發展其他替代的雜湊演算法。

2.RSA
RSA演算法1978年出現，是第一個既能用於數據加密也能用於數字簽名的演算法，易於理解和操作。
RSA基於一個數論事實：將兩個大素數相乘十分容易，但想要對其乘積進行因式分解卻極其困難，因此可以將乘積公開作為加密密鑰，即公鑰，而兩個大素數組合成私鑰。公鑰是可提供給任何人使用，私鑰則為自己所有，供解密之用。

3.MD5
MD5信息摘要演算法 （英語：MD5 Message-Digest Algorithm），一種被廣泛使用的密碼散列函數，可以產生出一個128位（16位元組）的散列值，用於確保信息傳輸完整一致。具有如下優點：

XOR：異或加密，既將某個字元或者數值 x 與一個數值 m 進行異或運算得到 y ，則再用 y 與 m 進行異或運算就可還原為 x。
使用場景：
（1）兩個變數的互換（不藉助第三個變數）；
（2）數據的簡單加密解密。