並行加密

❶ 最簡人機交互-加解密

上學時遞小紙條，尤其是需要中間人傳遞時，是不是使用過一套約定的符號代替普通的文字？特別有必要！
圖
廣義來講，保護信息的各種方式都屬於加密范疇，而保護的形式、角度、等級和目標是多種多樣的。

電視劇里，經常有材料被情敵偷偷修改然後蒙冤的場景。何解？
策略：讓內容中每一個位元組都參與一項運算得出一個結果記錄下來，如果計算結果變了，說明內容被修改過。

這里運算得出的結果叫做摘要，這個演算法叫消息摘要演算法，也叫單向散列函數。演算法的科學性很重要，常見的演算法有：MD5、SHA1、SHA256、SHA512、HmacMD5、HmacSHA1、HmacSHA256 等。

這個，只能說難免會被別人看到。
策略：使用密鑰變換內容，讓別人看到也不知道為何物，通過密鑰才可還原內容。

這種通過相同的密鑰來加密和解密的演算法，叫對稱加密演算法。常見演算法DES、3DES（TripleDES）和AES（Advanced Encryption Standard）等。AES 根據密鑰長度不同又分為AES-128 AES-192 AES-256 對應16 24 32 位元組。

這些演算法，通常是按塊來進行加密的，如 16 個位元組為一塊。當最後一塊不夠 16 個位元組時，通常是採用補齊的策略，補齊的方式也有不同講究。
策略一，數據長度不對齊時使用0填充，否則不填充，但補的0解密後無法區分是補的還是原本就有的，只適合以\0結尾的字元串加密，此謂之 ZeroPadding。
策略二，補充的位元組值設定為補充的數量，如要補充5個位元組，則這5個位元組的值都為 5，這樣根據最後一個位元組可得到填充數據的長度，在解密後可以准確刪除填充的數據。但如果剛好整塊無需補充，為了仍然滿足最後一個位元組表示填充的數據長度，填充一整塊，值為塊長度。此種方式有 PKCS7Padding，它假設數據長度需要填充n(n>0)個位元組才對齊，那麼填充n個位元組，每個位元組都是n；如果數據本身就已經對齊了，則填充一塊長度為塊大小的數據，每個位元組都是塊大小。PKCS5Padding，PKCS7Padding的子集，塊大小固定為8位元組。

分塊加密時，每塊採用完成相同的加密過程，則可以並行加密再拼接，但當內容中有多塊相同的內容時加密結果會一樣，而這種重復會為破解提供線索，於是多種加密模式被提出。以下是兩種最常見的模式。

Electronic Code Book(ECB)
電子密碼本模式
最基本的加密模式，也就是通常理虧洞解的加密，相同的明文將永遠加密成相同的密文，無初始向量，容易受到密碼本重放攻擊，一般情況下很少用。

Cipher Block Chaining(CBC)
密碼分組鏈接模式
明文被加密前要與前面的密文進行異或運算後再加密，因此只要選擇不同的初始向量，相同的密文加密後會形成不同的密文，這是目前應用最廣泛的模式。CBC加密銷飢枯後的密文是上下文相關的，但明文的錯誤不會傳遞到後續分組，但如果一個分組丟失，後面的分組將全部作廢(同步錯誤)。

對稱加密中，接收方需要知道密鑰，這個密鑰本身的保密就成為了問題。密鑰泄漏，意味著正確解密的消息也變得不可靠，也許是偽造的。

策略：公開密鑰，即發給我的消息，使用公開密鑰加密，我收到之後只可用我的私有密鑰解密。

此謂之非對稱加密演算法，一種強大的密鑰保密方法。這離不開理論上的研究成果。

非對稱加密演算法需要兩個密鑰：公開密鑰（publickey:簡稱公鑰）和私有密鑰（privatekey:簡稱私鑰）。公鑰與私鑰是一對，如果用公鑰對數據進行加密，只有用對應的私鑰才能解密。

為了驗證是不是對的人，可以要求發送放對內容提取摘要，並使用其私鑰加密，將結果附在後邊作為簽名一並發送。這樣，就可以使用發送放的公鑰來解密這個簽名並驗證其一致性，如果一致說明是對的人發過來的。此過程謂之簽名驗簽。

使用最廣泛的是RSA演算法。

很多常見的加密演算法在 CryptoJS 中有實現，首先，在控制台引入擴展腳本。肢讓

加密結果 U2FsdGVkX1//4p9CUaZpnBxvOKT
解密過程

加密的內容為16進制數據時，可以利用以下方式將16進制字元串轉換成位元組數組。

計算結果

CryptoJS 當前尚未支持 RSA，可以引入以下 JS 擴展。

使用公鑰加密

/hTwEJsz+/TkaF5UKG+H+RrjpbHHQVe3mWWlDsX9bZ/m8lP3izntwKHdklH+2vfeOlSJ3+PK3O6ILWvaVM4PVCzVo9lPiN7NkIE=

使用私鑰解密

反過來使用私鑰加密公鑰解密也是可以的，只是一般的工具方法，只會提供私密生成簽名，公鑰驗證簽名，但這足夠了。
更詳細用法，請參考 https://github.com/travist/jsencrypt/

直接來看看二戰期間的故事，以下內容引用自 https://..com/question/13366735.html

❷ 只有USB口的手提電腦怎麼接並行口的「加密狗」

如果該機器沒有並口的擴展卡或者底座，那就沒辦法了

❸ 如何查看並行加密狗埠是否工作

插上加密狗只能控制某早念基個程序的埠，但必須要跟加密狗對應的程序埠 ， 是點對點控制。

加密狗不能直接控制電腦上應用程序的埠，只能編寫一個程序監控80這個埠同時監控是否插入加密狗，如果已經插入狗，就放行http協議的數據，否則阻止。

設置一個監控埠的陸謹進程，也就是高滲說一共有3個進程一個是開啟一個是關閉，一個是監控服務狀態。

❹ 利用usb口和計算機並行口實現對數據加密屬於硬體加密嗎

屬於硬體加密，就必須要考慮計算機介面的問題。計算機的介面有許多種，如傳統的串口和並口。串口的出現是在1980年前後，數據傳輸率是115～230kb/s，一般用來連接滑鼠和外置Modem;並口的數據傳輸率比串口快8倍，標准並口的數據傳輸率為IMb/s左右，一般用來連接列印機、掃描儀等。早期的軟體狗類加密硬體基本上都是使用並口的，不但極易與列印機沖突，而且容易被破解。要想設計出更可靠更完善的加密硬體，必須採用新的計算機介面。而近年來發展快速的USB介面技術為硬體加密提供了一條很好的道路。
1 總體方案的提出
設計系統原則是在實用、可靠、經濟的原則基礎上，保證系統不僅能滿足應用需要，而且要有靈活性、可擴展性和通用性。該系統有EDA技術、USB 匯流排協議、加密演算法優化組合而成，系統的構成如圖1所示。FPGA的作用之一是和PDIUSBD12進行通信，實現USB協議，從PDIUSBD12中獲取數據並根據主機的要求發送數據。第二個作用就是加密演算法的實現，完成傳送數據的加密。
2 USB協議的實現
2.1 PDIUSBD12簡介
PDIUSBD12是Philips公司的一款較新型的專用USB通信控制晶元，符合USBI.1規范，是一款高性能USB介面器件，集成了SIE，FIFO存儲器，收發器以及電壓調整器。可與任何外部微控制器/微處理器實現高速並行介面（2 MB/5），在批量模式和同步模式下均可實現IMB/5的數據傳輸速率以及完全自治的直接內存存取DMA操作。

❺ 並行口加密狗換945主板不能用

這個應該是加密狗的兼容性不好，尤其是年代攜蘆毀久辯備遠的加密狗，你嘩前可以試試安裝加密狗的最新驅動，也許會解決你的問題，如果是在搞它不定，就看看這里的介紹http://hi..com/nusbm

❻ 在CBC模式里有可能對多個明文分組進行並行加密嗎解密呢

加密不行，但是解密可以

❼ AES加密演算法原理

一般的加密通常都是塊加密，如果要加密超過塊大小的數據，就需要涉及填充和鏈加密模式，本文對對稱加密和分組加密中的幾種種模式進行一一分析(ECB、CBC、CFB、OFB,CTR)

這種模式是將整個明文分成若干段相同的小段，然後對每一小段進行加密。

優點:

這種模式是先將明文切分成若干小段，然後每一小段與初始塊或者上一段的密文段進行異或運算後，再與密鑰進行加密。

優點：

計算器模式不常見，在CTR模式中， 有一個自增的運算元，這個運算元用密鑰加密之後的輸出和明文異或的結果得到密文，相當於一次一密。這種加密方式簡單快速，安全可靠，而且可以並行加密，但是 在計算器不能維持很長的情況下，密鑰只能使用一次 。CTR的示意圖如下所示：

優點：

優點：

優點：

❽ 我們應該使用 TLS1.3 嗎

SSL（Socket Layer Security）和 TLS（Transport Layer Security） 都是屬於安全協議，主要作用是保證客戶端和服務端之間能安全通訊。SSL是較早的協議，TLS 是 SSL的替代者。

SSL 版本 1.0、2.0 和 3.0，TLS 版本 1.0、1.2 和 1.3。SSL協議和TLS1.0 由於已過時被禁用，目前TLS 1.3 是互聯網上部署最多的安全協議，它是TLS最新版本 ，它增強了過時的安全性，並增加了更多的觸控性。通過下面幾點可以有個簡單認識：

現代瀏覽器支持 TLS 1.2 和 TLS 1.3 協議，但 1.3 版本要好得多。 TLS 1.3 對早期版本進行了多項改進，最明顯的是簡化了TLS握手操作，使得握手時間變短、網站性能得以提升、改善了用戶體驗，另外支持的密碼套件更安全和簡單。

密碼套件

TLS/SSL 使用一種或多種密碼套件。 密碼套件是身份驗證、加密和消息身份驗證的演算法組合。TLS 1.2 版使用的演算法存在一些弱點和安全漏洞。在 TLS 1.3 中刪除了這些演算法：

另外一個很重要的更新是TLS1.3 支持 perfect-forward-secrecy （PFS）演算法。

向前保密 （PFS）是特定密鑰協商協議的一項功能，如果一個長周期的會話密鑰被泄露，黑客就會截獲大量數據，我們可以為每個會話生成唯一的會話密鑰，單個會話密鑰的泄露不會影響該會話之外的任何數據。

TLS在早期版本的握手期間可以使用兩種機制之一交換密鑰：靜態 RSA密鑰和 Diffie-Hellman 密鑰。 在 TLS1.3 中，RSA 以及所有靜態（非 PFS）密鑰交換已被刪除，只保留了DHE、ECDHE

可以查看網站的安全詳情來確認它是否使用"ECDHE"或"DHE"。

AES (Advanced Encryption Standard) 對稱加密，它是 高級加密 標准。早期的加密標准DES(Data Encryption Standard) 已被棄用。

AES選擇合適的 加密模式 很重要，應用比較多的兩種模式 CBC 和 GCM。

CBC 密碼分組鏈接模式

明文分塊，第一個塊使用初始化向量，後面的每個明文塊在加密前與前一個密文塊進行異或運算。

這種模式存在的問題：

CTR 計數模式

明文分塊按順序編號，通過加密"計數器"的連續值來生成下一個密鑰流塊。CTR 模式非常適合在多核處理器上運行，明文塊可以並行加密。

GCM 伽羅瓦/計數器模式

GCM = CTR + Authentication。其加密過程，明文塊是按順序編號的，然後這個塊號與初始向量 組合並使用塊密碼E加密，然後將此加密的結果與明文進行異或以生成密文。

簡單來說，GCM 是 CTR 身份驗證的組合，它更快、更安全。它將接受流水線和並行化實現，並具有最小的計算延遲，所以它的應用更加廣泛。

客戶端最低版本

客戶端最低版本

一般建議同時兼容1.2和1.3

測試是否支持 TLS 1.2

測試是否支持 TLS 1.3

❾ 對於加密的總結（AES,RSA）

跟第三方聯調的時候會碰到各種加密演算法，所以總結一下。

AES不是將拿到的明文一次性加密，而是分組加密，就是先將明文切分成長度相等的塊，每塊大小128bit，再對每一小塊進行加密。那麼問題就來了，並不是所有的原始明文串能被等分成128bit，例如原串大小200bit，那麼第二個塊只有72bit，所以就需要對第二個塊進行填充處理，讓第二個塊的大小達到128bit。常見的填充模式有

不進行填充，要求原始加密串大小必須是128bit的整數倍；

假設塊大小8位元組，如果這個塊跟8位元組還差n個位元組，那麼就在原始塊填充n，直到滿8位元組。例：塊{1,2,3}，跟8位元組差了5個位元組，那麼補全後的結果{1,2,3,5,5,5,5,5}後面是五個5，塊{1,2,3,..7}跟8位元組差了1個位元組，那麼補全後就是{1,2,3,...,7,1},就是補了一個1。

如果恰好8位元組又選擇了PKCS5Padding填充方式呢？塊{1,2,3...8}填充後變成{1,2,3...8,8...8}，原串後面被補了8個8，這樣做的原因是方便解密，只需要看最後一位就能算出原塊的大小是多少。

跟PKCS5Padding的填充方式一樣，不同的是，PKCS5Padding只是對8位元組的進行填充，PKCS7Padding可以對1~256位元組大小的block進行填充。openssl里aes的默認填充方式就是PKCS7Padding

AES有多種加密模式，包括：ECB,CBC,CTR,OCF,CFB,最常見的還是ECB和CBC模式。

最簡單的一種加密模式，每個塊進行獨立加密，塊與塊之間加密互不影響，這樣就能並行，效率高。
雖然這樣加密很簡單，但是不安全，如果兩個塊的明文一模一樣，那麼加密出來的東西也一模一樣。

openssl的相關函數：

CBC模式中引入了一個新的概念，初始向量iv。iv的作用就是為了防止同樣的明文塊被加密成同樣的內容。原理是第一個明文塊跟初始向量做異或後加密，第二個塊跟第一個密文塊做異或再加密，依次類推，避免了同樣的塊被加密成同樣的內容。

openssl相關函數：

敲黑板！！ 所以跟第三方對接的時候，如果對面說他們用aes加密，務必對他們發起靈魂三問：

簽名的作用是讓接受方驗證你傳過去的數據沒有被篡改；加密的作用是保證數據不被竊取。

原理：你有一個需要被驗簽的原串A。

步驟一：選擇hash演算法將A進行hash得到hash_a；

步驟二：將hash_a進行加密，得到加密值encrypt_a；

步驟三：將原串A和加密的encrypt_a發給第三方，第三方進行驗簽。第三方先解密encrypt_a，得到一個hash值hash_a1，然後對原串A使用同樣的hash演算法進行hash，得到的即為加密前的hash_a,如果hash_a = hash_a1, 那麼驗簽成功。

rsa使用私鑰對信息加密來做簽名，使用公鑰解密去驗簽。
openssl相關函數：

注意：兩個函數中的m，是原串hash後的值，type表示生成m的演算法，例如NID_sha256表示使用sha256對原串進行的hash，返回1為簽名成功或者驗簽成功，-1位為失敗。

再次敲黑板！！ 所以如果第三方說使用rsa驗簽，要讓對方告知他們的hash演算法。

首先明確，私鑰加密不等於簽名。加密的時候，使用使用公鑰加密，第三方使用你的私鑰進行解密。
openssl里公鑰加密函數為RSA_public_encrypt，私鑰解密函數為RSA_private_decrypt，具體的可以自己去查看下官方文檔。

rsa也涉及到了填充方式，所以對接的時候也要問清楚

在使用公鑰進行加密時，會發現每次加密出的結果都不一樣，但使用私鑰加密時，每次的結果都一樣，網上查了一圈，說是因為填充方式的原因。

官方文檔說明：

那麼為什麼一定要使用私鑰做簽名，公鑰做加密，而不是公鑰做簽名，私鑰做加密呢？
舉個栗子：

❿ AES加解密使用總結

AES, 高級加密標准, 是採用區塊加密的一種標准, 又稱Rijndael加密法. 嚴格上來講, AES和Rijndael又不是完全一樣, AES的區塊長度固定為128比特, 秘鑰長度可以是128, 192或者256. Rijndael加密法可以支持更大范圍的區塊和密鑰長度, Rijndael使用的密鑰和區塊長度均可以是128，192或256比特. AES是對稱加密最流行的演算法之一.

我們不去討論具體的AES的實現, 因為其中要運用到大量的高等數學知識, 單純的了解AES流程其實也沒什麼意義(沒有數學基礎難以理解), 所以我們今天著重來總結一些使用過程中的小點.

當然了分組密碼的加密模式不僅僅是ECB和CBC這兩種, 其他的我們暫不涉及.

上面說的AES是一種區塊加密的標准, 那加密模式其實可以理解為處理不同區塊的方式和聯系.

ECB可以看做最簡單的模式, 需要加密的數據按照區塊的大小分為N個塊, 並對每個塊獨立的進行加密

此種方法的缺點在於同樣的明文塊會被加密成相同的密文塊, 因此, 在某些場合, 這種方法不能提供嚴格的數據保密性. 通過下面圖示例子大家就很容易明白了

我們的項目中使用的就是這種模式, 在CBC模式中, 每個明文塊與前一個塊的加密結果進行異或後, 在進行加密, 所以每個塊的加密都依賴前面塊的加密結果的, 同時為了保證第一個塊的加密, 在第一個塊中需要引入初始化向量iv.

CBC是最常用的模式. 他的缺點是加密過程只能是串列的, 無法並行, 因為每個塊的加密要依賴到前一個塊的加密結果, 同時在加密的時候明文中的細微改變, 會導致後面所有的密文塊都發生變化. 但此種模式也是有優點的, 在解密的過程中, 每個塊的解密依賴上一個塊的加密結果, 所以我們要解密一個塊的時候, 只需要把他前面一個塊也一起讀取, 就可以完成本塊的解密, 所以這個過程是可以並行操作的.

AES加密每個塊blockSize是128比特, 那如果我們要加密的數據不是128比特的倍數, 就會存在最後一個分塊不足128比特, 那這個塊怎麼處理, 就用到了填充模式. 下面是常用的填充模式.

PKCS7可用於填充的塊大小為1-255比特, 填充方式也很容易理解, 使用需填充長度的數值paddingSize 所表示的ASCII碼 paddingChar = chr(paddingSize)對數據進行冗餘填充. (後面有解釋)

PKCS5隻能用來填充8位元組的塊

我們以AES(128)為例, 數據塊長度為128比特, 16位元組, 使用PKCS7填充時, 填充長度為1-16. 注意, 當加密長度是16整數倍時, 反而填充長度是最大的, 要填充16位元組. 原因是 "PKCS7" 拆包時會按協議取最後一個位元組所表徵的數值長度作為數據填充長度, 如果因真實數據長度恰好為16的整數倍而不進行填充, 則拆包時會導致真實數據丟失.

舉一個blockSize為8位元組的例子

第二個塊中不足8位元組, 差4個位元組, 所以用4個4來填充

嚴格來講 PKCS5不能用於AES, 因為AES最小是128比特(16位元組), 只有在使用DES此類blockSize為64比特演算法時, 考慮使用PKCS5

我們的項目最開始加解密庫使用了CryptoSwift, 後來發現有性能問題, 就改為使用IDZSwiftCommonCrypto.

這里咱們結合項目中邊下邊播邊解密來提一個點, 具體的可以參考之前寫的 邊下邊播的總結 . 因為播放器支持拖動, 所以我們在拖拽到一個點, 去網路拉取對應數據時, 應做好range的修正, 一般我們都會以range的start和end為基準, 向前後找到包含這個range的所有塊范圍. 打比方說我們需要的range時10-20, 這是我們應該修正range為0-31, 因為起點10在0-15中, 20 在16-31中. 這是常規的range修正.(第一步 找16倍數點).

但是在實際中, 我們請求一段數據時, 還涉及到解密器的初始化問題, 如果我們是請求的0-31的數據, 因為是從0開始, 所以我們的解密器只需要用key和初始的iv來進行初始化, 那如果經過了第一步的基本range修正後, 我們請求的數據不是從0開始, 那我們則還需要繼續往前讀取16個位元組的數據, 舉個例子, 經過第一步修正後的range為16-31, 那我們應該再往前讀取16位元組, 應該是要0-31 這32個位元組數據, 拿到數據後,使用前16個位元組(上一個塊的密文)當做iv來初始化解密器.

還有一個要注意的點是, 數據解密的過程中, 還有可能會吞掉後面16個位元組的數據, 我暫時沒看源碼, 不知道具體因為什麼, 所以保險起見, 我們的range最好是再向後讀取6個位元組.

感謝閱讀

參考資料

https://zh.wikipedia.org/zh-cn/%E9%AB%98%E7%BA%A7%E5%8A%A0%E5%AF%86%E6%A0%87%E5%87%86
https://segmentfault.com/a/1190000019793040
https://ithelp.ithome.com.tw/articles/10250386