開發中經常會存在不同系統之間的資料共享，那麼通過介面方式傳輸資料就是一件很方便的方式了。現在還有很多公司是用的http傳輸的資料，那麼資料是不安全的存在著資料在傳輸過程中發生洩漏的風險，所以現在資料傳輸常用的就是加密和加簽的方式來保證資料的安全。
加密和加籤中用到了非對稱性加密（rsa）,而非對稱性加密需要兩個秘鈅來進行加密和解密，這兩個秘鑰是公鑰(publickey)和私鑰(privatekey)。公鑰一般都是給別人的，自己留著私鑰，這樣即使別人知道了公鑰沒有私鑰，所以加強了資料的安全性。
首先我們要明白什麼是秘鑰，秘鑰是由rsa(公鑰+模值)、(私鑰+模值)分組分發的，單獨發公鑰或者私鑰匙沒有用的，所以我們俗話說的「金鑰」其實是他們兩者中的其中一組。但我們說的「金鑰長度」一般只是指模值的位長度。目前主流可選值：1024,、2048、3047。模值有專門的工具素數生成器，給他幾個數，告訴他多少位的素數他就會幫你自動生成。素數生成器有時候也會是1023也會是1024 自己要看好。
明文長度和密文長度，1024對應的明文長度是128字元，但因為考慮到自適應所以要用到rsa的padding模式，padding模式要佔11字元，所以實際上的明文長度就是128-11=117字元。密文長度就是明文加密後的長度。
資料加簽：
首先我們需要我們導個包，sadk
這個jar包裡有
seckeyencrypt:使用公鑰對資料進行加密
seckeydecrypt:使用私鑰對資料進行解密
seckeyrawverify:使用公鑰 對數字簽名和資料進行驗證，以確認該資料的**合法性。
seckeyrawsign:使用私鑰對資料進行摘要並生成數字簽名
rsa演算法有2個作用乙個是加密乙個是加簽。從這幾個函式中，我們可以看到，我們第一種是使用公鑰能在客戶端：資料加密，以及伺服器端用私鑰解密。
··第二個就是用私鑰在客戶端加簽，然後用公鑰在伺服器端使用公鑰解籤。第一種完全是為了加密，第二種是為了防抵賴，就是為了防止別人模仿我們的客戶端來攻擊我們的伺服器，導致癱瘓。
publiccertfilepath：公鑰
encpfxfilepath：私鑰
encpfxfilepwd：私鑰密碼
下面是具體的**：
我們可以看到這個方法是為了對內容進行加簽的，
urldecoder.decode這個api的目的是對私鑰進行utf-8格式的字串解碼，指定字符集。
我們通過呼叫sadk包中的方法，對加密進行初始化，通過獲取私鑰的方法:getprivatekeyfrompfx,我們得到了私鑰prikey。
通過signature類的p1signmessage方法來對內容進行加簽並將位元組數組裝換成字串，mechanism.sha1_rsa是模值。
獲取公鑰裡的內容轉換成流，x.509
數字證書生成及驗證的國際標準。
base64.decode 將string轉成位元組陣列
加簽：
keygenerator是aes演算法秘鑰生成器類， 然後初始化秘鑰生成器並規定秘鑰大小128位元組，生成乙個秘鑰sercretkey，
返回乙個基本編碼的字元陣列，key是乙個通過aes加密後的秘鑰。這裡的aes是對稱性加密。
基本流程和加簽是差不多的。
cipher建立密碼器 ，然後初始化，通過cipher.dofinal來對內容進行加密，base64.encode返回位元組陣列，base64是一種編碼方式，加密演算法輸出都是byte 統一base64避免出現亂碼。
總結;很多人在開始的時候，能夠理解加簽和解籤是什麼意思，但對加密不是很了解會走入誤區，我舉個例子：
我用通過aes對稱加密對內容進行了加密，這是個鎖，但我們想要讓別人開啟這個鎖，就需要通過私鑰進行加密，生成乙個鑰匙。別人當獲取到這鑰匙的時候就可以對你加密的內容知道怎麼解密了。
------ 越努力越幸運 每日一部落格
LeetCode（一）關於GrayCode的實現
在leetcode上面有一道題，是關於gray code的實現的。graycode是這樣一種編碼 1 位gray code 0 12 位gray code 先新增乙個映象，如下 011 0然後，在原來的編碼前面新增 0 在映象碼前面新增 1 如下 00 0111 10而從2位變化到3位的gray c...
網路請求中常見的加密機制和加密演算法理解
請求安全性 伺服器端在接收到請求的時候，要主動鑑別該請求是否有效，是否可接受。token 已登陸使用者的識別碼 解決的問題 使用者呼叫介面時，不用每次都帶上使用者名稱和密碼，避免了頻繁在網路中傳輸密碼被截獲的風險。使用場景 使用者登入系統時傳入使用者名稱和密碼，伺服器校驗成功之後，根據uuid等引數...
關於網路傳輸的幾點理解
關於網路傳輸的幾點理解 寫這篇短文心裡很難過的說，多個節點之間怎樣快速傳輸資料，當時面對這個問題一時語塞，只是從資料傳送這個角度進行了優化，實在是可惜，如果再給我一次機會。閒話少說，回過頭來，想到以下幾點 首先，盡量提高並行度，每個節點並行地給其他當前沒有資料的節點傳輸 當時沒有點明這個，估計被人家...