初始向量加密

1. 對於加密的總結（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也涉及到了填充方式，所以對接的時候也要問清楚

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

官方文檔說明：

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

2. 分組密碼加密模式選擇有哪些

分組密碼工作模式的應用背景：多次使用相同的密鑰對多個分組加密，會引發許多安全問題。為了應對不同場合，因而需要開發出不同的工作模式來增強密碼演算法的安全性。ECB特別適合數據較少的情況，對於很長的信息或者具有特定結構的信息，其大量重復的信息或固定的字元開頭將給密碼分析者提供大量的已知明密文對。若明文不是完整的分組，ECB需要進行填充。CBC（Cipher Block Chaining）由於加密演算法的每次輸入和本明文組沒有固定的關系，因此就算有重復的明文組，加密後也看不出來了。為了配合演算法的需要，有一個初始向量（IV）。與ECB一樣有填充機制以保證完整的分組。CFB（Cipher Feedback）和OFB，CTR模式一樣，均可將分組密碼當做流密碼（實際是將分組大小任意縮減）使用。

3. AES GCM加密模式的初始向量IV怎麼確定

(IV) 對數據執行加密轉換.對於給定的私鑰 k,一個不使用初始化向量的簡單類是隨機數生成器演算法的實現.

4. PHP常用加密解密方法

作者/上善若水

1.md5(string $str,bool $flag = false);

$flag = false 默認返回32位的16進至數據散列值

$flag = true  返回原始流數據

2.sha1($string,$flag = false)

$flag = false 默認返回40位的16進至數據散列值

true  返回原始流數據

3.hash(string $algo,srting $str,bool $flag);

$algo : 演算法名稱，可通過hash_algos()函數獲取所有hash加密的演算法

如：md5,sha1等，採用md5,sha1加密所得結果和1,2兩種方式結 果相同。

$flag = false 默認返回16進至的數據散列值，具體長度根據演算法不同

而不同。

true  返回原始流數據。

4.crypt(string $str,$string $salt)；

函數返回使用 DES、Blowfish 或 MD5 演算法加密的字元串。

具體演算法依賴於PHP檢查之後支持的演算法和$salt的格式和長度，當 然具體結果也和操作系統有關。比較結果採用 hash_equals($crypted,crypt($input,$salt));//且salt值相同

Password_verify($str,$crypted);

5.password_hash ( string $str, integer $algo [, array $options ] )

函數返回哈希加密後的密碼字元串， password_hash() 是crypt()的 一個簡單封裝

$algo : 演算法 PASSWORD_DEFAULT ，PASSWORD_BCRYPT

$options = [

「cost」=>10，//指明演算法遞歸的層數,

「salt」=>「xxadasdsad」//加密鹽值，即將被遺 棄，採用系統自動隨機生成安全性更高

]；

使用的演算法、cost 和鹽值作為哈希的一部分返回

Password_verify($str,$hashed);

6.base64_encode(string $str)

設計此種編碼是為了使二進制數據可以通過非純 8-bit 的傳輸層 傳輸，例如電子郵件的主體。base64_decode(string $encoded)

可以進行解碼;

7.mcrypt_encrypt ( string $cipher , string $key , string $data ,

string $mode [, string $iv ] )

mcrypt_decrypt ( string $cipher , string $key , string $crypted ,

string $mode [, string $iv ] )

$ciper:加密演算法，mcrypt_list_algorithms()可以獲取該函數所有支持的演算法

如MCRYPT_DES(「des」),MCRYPT_RIJNDAEL_128(「rijndael-128」);

$mode : 加密模式 ，mcrypt_list_modes()獲取所有支持的加密模式，ecb,cbc

$key: 加密的秘鑰，mcrypt_get_key_size ( string $cipher , string $mode )

獲取指定的演算法和模式所需的密鑰長度。$key要滿足這個長度，如果長 度無效會報出警告。

$iv : 加密的初始向量，可通過mcrypt_create_iv ( int $size [, int $source = MCRYPT_DEV_URANDOM ] )，

Iv的參數size：

通過mcrypt_get_iv_size ( string $cipher , string $mode )獲取

Iv 的參數source：

初始向量數據來源。可選值有： MCRYPT_RAND （系統隨機數生成 器）, MCRYPT_DEV_RANDOM （從 /dev/random 文件讀取數據） 和  MCRYPT_DEV_URANDOM （從 /dev/urandom 文件讀取數據）。 在 Windows 平台，PHP 5.3.0 之前的版本中，僅支持 MCRYPT_RAND。

請注意，在 PHP 5.6.0 之前的版本中， 此參數的默認值 為 MCRYPT_DEV_RANDOM。

Note: 需要注意的是，如果沒有更多可用的用來產生隨機數據的信息， 那麼 MCRYPT_DEV_RANDOM 可能進入阻塞狀態。

$data : 要加密的字元串數據

5. 關於AES加解密中CBC模式的IV初始化向量的安全性問題

前段時間，在研究HLS的AES加密，由於一個地方電視台的HLS流有AES加密，在查看了相關的加解密方案後發現使用的是簡單的AES的CBC模式，在CBC的模式下，會設置一個IV，初始化向量。但是我在解密的時候，使用了一個由於理解錯誤而產生的一個錯誤IV居然也能解密視頻並進行播放，於是就有了這篇張文章。

雖然有五種加密，但是常用的還是CBC，CBC的全稱Cipher Block Chaining ，有點類似於區塊鏈哈，我們先來看下加密方式

上面的圖片從左往右看，初始化IV只有在第一個塊加密的時候才會用到，而第N個塊的加密IV則是用的N-1(N>1)個加密後的二進制數組。

CBC的解密則也是從左往右看，但是加密時IV在解密時候，只會用於對第一個塊進行解密，其他塊的解密則是使用上一塊的加密二進製作為IV進行解密操作。

通過上面的分析就能知道，加密的時候，iv會影響所有數據的加密結果，而解密時，iv只會影響第一個加密塊的解密結果，其他塊的解密可以直接通過分隔加密數據獲取正確是N-1塊的IV。

這也就印證了為什麼ff能播放我用錯誤的iv解密出來的視頻流數據，因為第一塊的大小存儲大概是id3 的數據，ff直接丟掉id3的數據，直接解碼後面的視頻數據 ，ff 應該是識別h264編碼頭開始解碼視頻。

那麼從這點可以看出，在使用了key的情況下，IV對整個數據的保密性沒有太大的作用。

再來說說我是怎麼發現這個問題，因為錯誤的IV只會影響第一個塊的數據，我在第一次嘗試解密後，直接用ff進行播放，ff能夠解碼並且播放成功，但是相對於其他未加密的HLS流來說，播放我解密後的數據會有3-5s的延時，這讓我很是頭疼，後來我就通過 ffplay -v trace 列印播放解密的日誌，發現視頻數據的id3信息丟失了，那麼出問題出在第一個塊。然後再次研究m3u8加解密IV的賦值方法，後發來經過多次試驗，正確賦值IV，解密出來的數據能夠及時播放。再後來，就出現了這篇文章的來由。

由此帶來的延展，針對iv在CBC模式下的弱用，AES提供了更多的模式可供選擇，詳細的可以到wiki上了解。

https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation