aes js 加盐值 解密_AES加密: GCM和CBC模式的区别

时间:2024-09-30 20:50:00

 AES加密: GCM和CBC模式的区别

Difference between GCM and CBC

导语 

项目代码的构建扫描结果中,Sonarsource Rule 中建议用 AES - GCM 来替代 AES-CBC,这两者究竟有什么区别呢?可以按照建议替换掉么?趁着这个机会,学习了一下常用的AES算法基础概念,以及CBC模式和GCM模式,并使用了JMH做了benchmark ~

背景

一,主要区别

  • AES-GCM可以并行加密解密,AES-CBC的模式决定了它只能串行地进行加密。因为加密是耗时较久的步骤,且加密的方式是相同的,所以并行地实现AES-GCM算法的时候,其效率是高于AES-CBC的;

  • AES-GCM提供了GMAC信息校验码,用以校验密文的完整性。AES-CBC没有,无法有效地校验密文的完整性;

  • AES-GCM是流加密的模式,不需要对明文进行填充。AES-CBC是块加密的模式,需要对明文进行填充。(AES-GCM中进行AES加密的是counter,AES-CBC中进行AES加密的是明文块);

  • 由于AES-CBC中必须要用到padding,导致最后一个明文块与其他密文块不同,因此可能会受到padding Oracle attacks,从而可以直接通过初始向量IV和密码,即可得到明文。

二,ASE介绍

AES属于对称加密算法。在实际中,一般是通过RSA加密AES密钥,进行密钥的传输。以下将简要地介绍AES加密的一些概念和主要步骤。

分组密码

AES为分组密码,即将明文分成一组一组的,每组长度相等。在AES的标准规范中,分组的长度是128位。密钥的长度可以为128位,192位或256位。密钥的长度不同,推荐的加密轮数也不同:

加密模式

因为AES是分组加密,分组加密只能加密固定长度的分组,而实际需要加密的明文可能超过分组长度,此时就需要加密模式,以完成对整个明文的加密。常见的加密模式如下:

初始向量

初始向量IV的作用和MD5的加盐类似,目的是防止同样的明文块,始终加密成同样的密文块。以CBC模式为例如下:

CBC模式在每一个明文块加密前,会让明文块和一个值先做异或操作。IV作为初始化向量,参与第一个明文块的异或。后续的每一个明文块和它前一个明文块所加密出的密文块相异或,从而保证加密出的密文块都不同

填充方式

由于AES加密只能对固定长度的输入数据进行处理,而数据长度通常是可变的,因此需要对最后一个数据块做填充处理。在加密前,对数据进行填充。填充的模式有PKCS5, PKCS7, NOPADDING。

AES总体流程

AES加密的整个过程是在一个4*4的字节矩阵State上进行的。这个字节矩阵是由当前的明文块处理得到的。同样,加密密钥也需要做同样的变换得到拓展密钥的矩阵。
AES算法主要有四种操作处理:1-密钥加法AddRoundKey,2-字节替换SubByte,3-行位移层ShiftRows,4-列混淆层MixColumn。解密的时候,按照流程进行相应的逆运算即可。AES算法的四个操作处理都是在GF(Galois Field)域上进行运算的。

AddRoundKey

即是将当前的矩阵State和拓展密钥进行按位异或。

SubBytes

字节变换即是将矩阵State中的每一个字节,查找其在变换数组S_box中的对应值,替换成新字节即可。解密的时候有对应的逆S_box。

S盒和逆S盒实现的是下述流程:

ShiftRows

MixColumn

列混淆操作是AES中主要的扩散元素,它混淆了输入矩阵的每一列,使得输入的每个字节都会影响到4个输出字节。

密钥拓展

密钥拓展中主要使用了一个G函数,可以增强密钥编排中的非线性,并消除AES中的对称性,从而更好地抵抗某些分组密码攻击。

三,CBC模式

CBC模式介绍

上图为CBC模式。AES-CBC中block cipher encryption即是使用了AES加密。CBC使用了一个初始向量IV,和明文块进行异或,用以加盐。后续每一个明文块,都与上一个生成的密文块进行异或,从而避免相同的明文块加密出的内容是相同的。
对当前密文块进行解密的时候,需要先对当前密文块进行AES解密得到A,因为已知上一个密文块B,此时只需要A异或B,即可得到当前密文块的明文C。
从上面的图可知,CBC模式只能进行串行加密,因为每一个明文块的加密,都依赖于上一个明文块的加密结果。解密的过程是可以并行进行的。
同时因为使用了密码块当作盐,所以如果有某一块加密错误,则会造成错误传播的现象。
CBC中必须填充,从而造成了最后一个明文块与其他明文块的不同。给攻击造成了机会。因此CBC模式是可能受到padding oracle attacks的。

四,GCM模式

GCM(GMAC Counter Mode),使用了Counter的模式,并且带有GMAC消息认证码。

CTR模式

因为GCM是基于CTR(Counter Mode)的,所以以下介绍CTR Mode。

从上图可知,在CTR模式中,不再对明文进行加密,而是对一个逐次累加的计数器进行加密,用加密后得到的比特序列与明文分组进行异或,得到每一个明文块的密文。计数器的初始值,是依据于一个nonce的。
因为计数器是递增的,所以加密得到的比特序列是不同的,再与明文进行异或,可以避免相同的明文块被加密成一样的密文块。
因为每一个明文块的加密都是独立的,不依赖于其他明文块,所以CTR模式的AES加密是可以并行地对明文块进行加密的,并且不会有错误传播的现象。
以下为CTR解密模式:

CTR的解密也是较为直接的。直接对计数器进行加密,得到比特序列,再和对应的密文块进行异或,就可以得到相应的明文块。
因为CTR模式下的AES加密是针对计数器进行加密的,所以CTR模式是不需要padding的。

MAC和GMAC

CBC和CTR模式都不能校验消息的完整性。依据普通hash不能保证消息的完整性,因为篡改者截获原始密文消息时,先篡改密文,而后计算篡改后密文的hash,替换原有的hash。这时,消息的接收者依然没有办法发现对源密文的篡改。所以依靠单向散列函数计算hash值仍然不能解决消息完整性校验的问题。

MAC

MAC(Message Authentication Code, 消息验证码),MAC是一种与密钥相关的单向散列函数,从而解决了普通hash的问题。密文的收发双方需要提前共享一个密钥,密文的发送者将密文的MAC值跟随密文一起发送,密文的接收者通过共享密钥计算收到的密文的MAC值,与附加的MAC值进行对比,就可以对收到的密文进行完整性校验。篡改者因为没有共享密钥,所以降低了被篡改的概率。
在Mode需要初始向量,或nonce, 或counter等情况下,需要将其作为附加消息一起计算MAC值。

GMAC

GMAC(Galois MAC) 是利用GF(Galois) 域的乘法运算来计算消息的MAC值的

GCM

以下为GCM模式。其中Ek为加密算法,AES-GCM中即为AES加密算法。Mh是将输入和密钥h在有限域GF上做乘法。

GCM即是将CTR计数器模式,和GMAC验证码结合。这样即可以并行地进行加密过程,又可以对信息的完整性进行校验。
同时因为计数器模式属于流加密模式,而非块加密模式。因此GCM中明文不需要进行padding。

实践

JMH, Java Microbenchmark Harness, 是专门用于进行代码的微基准的一套测试API。在AES-GCM和AES-CBC的benchmark中,使用了JMH来进行性能的测试。

Demo

加密一般是作为工具类存在的。因此在encrypt和decrypt方法中,进行了Cipher实例的创建。代码中抽出创建Cipher实例的部分,同时比较了一下两种模式Cipher实例创建的时间。实际进行工具类code撰写的时候,应进行优化。AES:AES加密解密工具类,提供CBC模式和GCM模式

MyTest: 使用JMH来做benchmark

Benchmark

Test Result 1

测试数据:长度32的字符串。
测试方法:一轮迭代时长为5s,每个需要测试的函数预热三轮,迭代15轮计算每次操作的平均耗时。

Test Result 2

测试数据:1109字中文文章。
测试方法:同上。

Test Result 3

由于单独的CBC是不包括GMAC,GCM包含了GMAC的计算,所以比较CBC+GMAC和GCM是比较合理的方式,Test 1和 Test 2中没有在CBC中另外加上GMAC。另外算法的具体实现方式也是影响其表现的。以下是其他参考的benchmark数据。

OpenSSL 2017/04

AES CBC+HMAC and GCM performance benchmarks for Java JCE, Bouncy Castle, Commons Crypto and Clojure Buddy.

总结

从Test1和Test2可以看出,一般应用加密解密场景中CBC和GCM性能差距不大。从其他的benchmark数据来看,总体上GCM的效果是好于CBC的。
从算法和模式设计上来说,GCM的可并行加密且具有验证位,CBC因为padding可能会收到攻击。因此GCM的安全性更高。
因此Sonarsource推荐使用AES-GCM来替换AES-CBC还是很有道理的。

TDTP留声机

留下我们奋斗的声音

三人行 必有我师焉.....