AES-GCM加密算法

AES是一種對稱加密算法,它的相關概念在此不贅述。

GCM ( Galois/Counter Mode) 指的是該對稱加密採用Counter模式,並帶有GMAC消息認證碼。

在詳細介紹AES-GCM之前,我們先了解一些相關概念。


下文中出現的符號:

Ek 使用祕鑰k對輸入做對稱加密運算
XOR 異或運算
Mh 將輸入與祕鑰h在有限域GF(2^128)上做乘法

ECB( Electronic Mode 電子密碼本模式)

當我們有一段明文,需要對其進行AES加密時,需要對明文進行分組,分組長度可爲128,256,或512bits。採用ECB模式的分組密碼算法加密過程如下圖:


由上圖可以看出,明文中重複的排列會反映在密文中。

並且,當密文被篡改時,解密後對應的明文分組也會出錯,且解密者察覺不到密文被篡改了。也就是說,ECB不能提供對密文的完整性校驗。
因此,在任何情況下都不推薦使用ECB模式。


CTR ( CounTeR 計數器模式)

在計數器模式下,我們不再對密文進行加密,而是對一個逐次累加的計數器進行加密,用加密後的比特序列與明文分組進行 XOR得到密文。過程如下圖:



計數器模式下,每次與明文分組進行XOR的比特序列是不同的,因此,計數器模式解決了ECB模式中,相同的明文會得到相同的密文的問題。CBC,CFB,OFB模式都能解決這個問題,但CTR的另兩個優點是:1)支持加解密並行計算,可事先進行加解密準備;2)錯誤密文中的對應比特只會影響明文中的對應比特等優點。
但CTR仍然不能提供密文消息完整性校驗的功能。
有的人可能會想到,如果將密文的hash值隨密文一起發送,密文接收者對收到的密文計算hash值,與收到的hash值進行比對,這樣是否就能校驗消息的完整性呢?

再仔細想想,就能發現這其中的漏洞。當篡改者截獲原始的密文消息時,先篡改密文,而後計算篡改後的密文hash, 替換掉原始消息中的密文hash。這樣,消息接收者仍然沒有辦法發現對源密文的篡改。可見,使用單向散列函數計算hash值仍然不能解決消息完整性校驗的問題。


MAC  ( Message Authentication Code, 消息驗證碼)

想要校驗消息的完整性,必須引入另一個概念:消息驗證碼。消息驗證碼是一種與祕鑰相關的單項散列函數。


密文的收發雙發需要提前共享一個祕鑰。密文發送者將密文的MAC值隨密文一起發送,密文接收者通過共享祕鑰計算收到密文的MAC值,這樣就可以對收到的密文做完整性校驗。當篡改者篡改密文後,沒有共享祕鑰,就無法計算出篡改後的密文的MAC值。

如果生成密文的加密模式是CTR,或者是其他有初始IV的加密模式,別忘了將初始的計時器或初始向量的值作爲附加消息與密文一起計算MAC。


GMAC ( Galois message authentication code mode, 伽羅瓦消息驗證碼 )

對應到上圖中的消息認證碼,GMAC就是利用伽羅華域(Galois Field,GF,有限域)乘法運算來計算消息的MAC值。假設祕鑰長度爲128bits, 當密文大於128bits時,需要將密文按128bits進行分組。應用流程如下圖:


GCM( Galois/Counter Mode ) 

GCM中的G就是指GMAC,C就是指CTR。

GCM可以提供對消息的加密和完整性校驗,另外,它還可以提供附加消息的完整性校驗。在實際應用場景中,有些信息是我們不需要保密,但信息的接收者需要確認它的真實性的,例如源IP,源端口,目的IP,IV,等等。因此,我們可以將這一部分作爲附加消息加入到MAC值的計算當中。下圖的Ek表示用對稱祕鑰k對輸入做AES運算。最後,密文接收者會收到密文、IV(計數器CTR的初始值)、MAC值。



發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章