初始向量加密

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