Google Tink 04：對稱加密的安全實(shí)現(xiàn)

還記得 Tink 的第一個(gè)演示么臂寝？回頭可以再看一下势就，在代碼中有一行用來生成新的 KeysetHandle，如下：

kh, err := keyset.NewHandle(aead.AES256GCMKeyTemplate())

其中谴分，我們提到了 aead.AES256GCMKeyTemplate() 創(chuàng)建了一個(gè)密鑰模板啡直，該模板是定義如何生成加解密數(shù)據(jù)所使用的密鑰烁涌，這類模板中包含加解密算法、密鑰長度酒觅、IV 長度等值撮执。

這篇文章主要就用來分析還有哪一些常用的 KeyTemplate。

KeyTemplate

目前的 Tink 中阐滩，用于生成 KeyTemplate 的方法二打，按照加密算法和加密模式的不同，可以分為以下的三大類掂榔，它們被定義在 go/aead/aead_key_templates.go 文件中：

使用 AES 算法，并采用 GCM 模式的 KeyTemplate 有：

AES128GCMKeyTemplate()：使用 128 位密鑰長度的基于 GCM 的 AES 算法症杏；
AES256GCMKeyTemplate()：使用 256 位密鑰長度的基于 GCM 的 AES 算法装获；

使用 AES 算法，并采用 CTR 模式的 KeyTemplate 有：

AES128CTRHMACSHA256KeyTemplate()：
AES256CTRHMACSHA256KeyTemplate()：

注意采用 CTR 模式需要對密文進(jìn)行認(rèn)證厉颤，所以需要使用 HMACSHA256 算法穴豫，而 GCM 模式自帶 GMAC 功能對消息進(jìn)行認(rèn)證。

使用 ChaCha20 算法，并采用 Poly1305 消息認(rèn)證碼算法有：

ChaCha20Poly1305KeyTemplate()：
XChaCha20Poly1305KeyTemplate()：

上面所有的方法精肃，返回的都是 *tinkpb.KeyTemplate 類型秤涩，它是一個(gè)通過 ProtoBuf 協(xié)議定義的結(jié)構(gòu)體類型。

KeyTemplate 結(jié)構(gòu)體

在 go/proto/tink_go_proto/tink.pd.go 文件中司抱，定義了 KeyTemplate 結(jié)構(gòu)體筐眷，熟悉 Go 的同學(xué)都知道，這種 .pd.go 后綴的文件习柠，都是通過 .proto 文件自動(dòng)生成的匀谣。

下面是 tink.pd.go 中的 KeyTemplate 結(jié)構(gòu)體和它的定義文件 tink.proto 中定義的 message KeyTemplate類型。

type KeyTemplate struct {
    // Required.
    TypeUrl string `protobuf:"bytes,1,opt,name=type_url,json=typeUrl,proto3" json:"type_url,omitempty"`
    // Optional.
    // If missing, it means the key type doesn't require a *KeyFormat proto.
    Value []byte `protobuf:"bytes,2,opt,name=value,proto3" json:"value,omitempty"`
    // Optional.
    // If missing, uses OutputPrefixType.TINK.
    OutputPrefixType     OutputPrefixType `protobuf:"varint,3,opt,name=output_prefix_type,json=outputPrefixType,proto3,enum=google.crypto.tink.OutputPrefixType" json:"output_prefix_type,omitempty"`
    ......
}

提示：OutputPrefixType 是 int32 的別名资溃，它定義的是密文的輸出前綴武翎。

定義 KeyTemplate 結(jié)構(gòu)體類型的文件 proto/tink.proto 中，有這個(gè)結(jié)構(gòu)體的定義：

message KeyTemplate {
  // Required.
  string type_url = 1;  // in format type.googleapis.com/packagename.messagename
  // Optional.
  // If missing, it means the key type doesn't require a *KeyFormat proto.
  bytes value = 2;  // contains specific serialized *KeyFormat proto
  // Optional.
  // If missing, uses OutputPrefixType.TINK.
  OutputPrefixType output_prefix_type = 3;
}

根據(jù)生成的 tink.pd.go 文件中 KeyTemplate 的內(nèi)容溶锭，該結(jié)構(gòu)體內(nèi)的主要字段用途為：

TypeUrl：代表使用的密碼算法的類型宝恶，它以 URL 的形式顯示；
Value：不同類型的密碼算法結(jié)構(gòu)體序列化后的字節(jié)數(shù)組趴捅，最主要就參數(shù)就是密鑰長度垫毙；
OutputPrefixType：輸出的前綴；

TypeUrl

按照使用密碼算法模板的不同驻售，TypeUrl 為：

AES GCM："type.googleapis.com/google.crypto.tink.AesGcmKey"
AES CTR："type.googleapis.com/google.crypto.tink.AesCtrHmacAeadKey"
ChaCha20Poly1305："type.googleapis.com/google.crypto.tink.ChaCha20Poly1305Key"
xChaCha20Poly1305："type.googleapis.com/google.crypto.tink.XChaCha20Poly1305Key"

OutputPrefixType

而 OutputPrefixType 一般則固定為 OutputPrefixType = 1露久，一種 int32 的數(shù)據(jù)類型。這個(gè)前綴會(huì)在每一次輸出密文的時(shí)候輸出到最前面欺栗，所以我們可以發(fā)現(xiàn)毫痕，所有的密文都會(huì)以 01 開頭的原因了。

Vault

Value 中才會(huì)保存著生成與 Key 相關(guān)的信息迟几，對于 AES GCM 來說消请，Vault中保存的是 AesGcmKeyFormat 序列化之后的 []byte 數(shù)組，它的定義如下：

type AesGcmKeyFormat struct {
    KeySize              uint32   `protobuf:"varint,2,opt,name=key_size,json=keySize,proto3" json:"key_size,omitempty"`
    Version              uint32   `protobuf:"varint,3,opt,name=version,proto3" json:"version,omitempty"`
    ......
}

其中类腮，最重要的那個(gè)參數(shù)就是 KeySize臊泰，用來描述密鑰的長度。

AES GMC 實(shí)現(xiàn)

上面我們簡單介紹了蚜枢，AES GCM 按照密鑰的長度分為兩種缸逃，一種是 AES 128，另一種是 AES 256厂抽。而采用 AES GCM 模式自帶有密文簽名的功能需频，所以只需要實(shí)現(xiàn)加解密功能就可以了，簽名功能就不用另外寫代碼了筷凤。

上篇文章中我們介紹過昭殉，Tink 的使用上是不用我們管理密鑰的，它會(huì)隨機(jī)的為我們生成一個(gè)用來加密的密鑰，同時(shí)也會(huì)為這個(gè)密鑰分配一個(gè) ID 值挪丢，并將其記錄到 Keyset 中蹂风。解密的時(shí)候就通過這個(gè) ID 值去 Keyset 中查找對就在的密鑰去解密。

我們調(diào)用 AES GMC 實(shí)現(xiàn)的 AEAD 功能乾蓬，僅僅需要傳入明文和可選的額外數(shù)據(jù)就可以了惠啄。

密鑰的準(zhǔn)備流程

在 Tink 中，要實(shí)現(xiàn) AEAD 的加解密功能巢块，大致流程如下：

創(chuàng)建模板

密鑰的創(chuàng)建是要通過預(yù)先定義好的密鑰模板（KeyTemplate）的礁阁，假如想使用 AES GCM 加密算法，則是通過 AES128GCMKeyTemplate() 或 AES256GCMKeyTemplate() 來生成密鑰模板的族奢。

創(chuàng)建密鑰

創(chuàng)建密鑰的過程是通過 KeyManager 來完成的姥闭，它主要的功能就是生成隨機(jī)的 KeyID 和 Key，這里的 Key 就是用來加解密數(shù)據(jù)使用的越走。

創(chuàng)建 PrimitiveSet

創(chuàng)建的密鑰會(huì)被加入到 PrimitiveSet 中棚品，為什么有個(gè) Set 呢？這是因?yàn)槿绻阌卸鄠€(gè) Key 的話廊敌，加密是通過設(shè)置為 Primary 的 Key 來完成的铜跑，解密則會(huì)查找指定的 KeyID Key 來完成。

使用 Primitive

完成了上面的步驟之后骡澈，就可以通過調(diào)用 Primitive 的 Encrypt 或 Decrypt 來執(zhí)行加解密任務(wù)了锅纺。

上面的步驟，只需要通過兩行代碼就可以完成肋殴，也就是下面的這兩行：

kh, _ := keyset.NewHandle(aead.AES256CTRHMACSHA256KeyTemplate())
a, _ := aead.New(kh)

是不是相當(dāng)?shù)暮唵味陲保F(xiàn)在代碼中的 a 就是 Primitive，可以通過它實(shí)現(xiàn)加解密的操作护锤。

密文的構(gòu)成

通過對上面知識的介紹官地，現(xiàn)在我們能了解到 Tink 中一些關(guān)鍵的實(shí)現(xiàn)方法，大致就能推導(dǎo)出密文的組成方式烙懦。

比如驱入，前面的介紹中使用的加密示例，用來加密字符串 "this data needs to be encrypted"：

ct, err := a.Encrypt([]byte("this data needs to be encrypted"), []byte("associated data"))

運(yùn)行后氯析，輸出的密文結(jié)果就是亏较，它由 128 個(gè)十六進(jìn)制數(shù)組成：

0187574a607e5a6e321cd16ea125546ef145d0f9e250a7ae4ce5ef259a715a7025cacdeb8e004c1bb98b2db96de439ed9023e8c5636b05f462dd298c597789c7

那它的構(gòu)成是通過下面的內(nèi)容組合而成的：

prefix: 1 byte，使用 Tink 就默認(rèn)是 1掩缓；
key id: 4 byte宴杀，隨機(jī)生成的 32 位數(shù)字；
IV: 12 byte拾因，隨機(jī)生成的 iv，GCM 中應(yīng)該叫 nonce；
GCM tag: 16 byte绢记，GCM 生成的認(rèn)證數(shù)據(jù)扁达，將和明文混合；
ciphertext: 密文的長度蠢熄，它和明文擁有一樣的長度跪解，如何用 byte 統(tǒng)計(jì)，上面的 "this data needs to be encrypted" 長度為 31 byte签孔。

發(fā)現(xiàn)最終的結(jié)果就是 64 byte（1 + 4 + 12 + 16 + 31）叉讥，打印成十六進(jìn)制數(shù)就是 128 個(gè)，和上面的結(jié)果一致饥追。

一般情況下图仓，我們不需要去刻意的觀察它的長度，只需要知道使用 Tink AEAD 加密的內(nèi)容但绕，一般都會(huì)是以 01 開頭救崔，而它使用密鑰 ID 就是 01 后面的 8 個(gè)十六進(jìn)制數(shù)（4 字節(jié)），也就是上面密文中的 87574a60 這串?dāng)?shù)字來表示的捏顺。

AES CTR 實(shí)現(xiàn)

了解了 AES GCM 的實(shí)現(xiàn)后六孵，其它的加密模式就比較好理解了。

雖然 AES CTR 模式的實(shí)現(xiàn)比較復(fù)雜一點(diǎn)幅骄，那是因?yàn)?CTR 模式不帶有對密文進(jìn)行簽名的功能劫窒，所以就需要使用 HMAC 來對密文進(jìn)行簽名。舉個(gè) AES 256 CTR 模板的例子：

// AES256CTRHMACSHA256KeyTemplate is a KeyTemplate that generates an AES-CTR-HMAC-AEAD key with the following parameters:
//  - AES key size: 32 bytes
//  - AES CTR IV size: 16 bytes
//  - HMAC key size: 32 bytes
//  - HMAC tag size: 32 bytes
//  - HMAC hash function: SHA256
func AES256CTRHMACSHA256KeyTemplate() *tinkpb.KeyTemplate {
    return createAESCTRHMACAEADKeyTemplate(32, 16, 32, 32, commonpb.HashType_SHA256)
}

我們就可以看到 AES拆座、CTR主巍、HMAC256 分別代表著加密算法、加密模式懂拾、簽名算法煤禽，它們一起使用，就會(huì)帶來一大堆的參數(shù)了岖赋。通過簡單的推理也可以知道檬果，采用 AES256CTRHMACSHA256KeyTemplate 這個(gè) KeyTemplate 會(huì)比其它的兩種 KeyTemplate 產(chǎn)生更長的密文。

雖然看起來很復(fù)雜唐断，但通過 Tink 的封裝选脊，大量底層的邏輯操作都是通過 Primitive 提供的非常簡單的 Encrypt 和 Decrypt 接口來實(shí)現(xiàn)的，大大簡化心智負(fù)擔(dān)脸甘。這就相當(dāng)于現(xiàn)在和計(jì)算機(jī)溝通恳啥，只用通過使用高級編程語言來完成，不用來編寫二進(jìn)制來控制計(jì)算機(jī)是一樣的道理丹诀。

ChaCha20 和 XChaCha20 Poly1305 實(shí)現(xiàn)

ChaCha20 和 XChaCha20 它們使用的密鑰長度都是 32 byte 長钝的，而它們唯一的區(qū)別就是使用的 NonceSize 的長度不一樣翁垂，Chacha20 使用的 NonceSize 是 12 byte，而 XChaCha20 合適的 NonceSize 是 24 byte硝桩。

最關(guān)鍵的就是它們的加密實(shí)現(xiàn)中沿猜，也同時(shí)采用 Poly1305 簽名算法實(shí)現(xiàn)了簽名，所以就不用像 AES CTR 那樣碗脊，在加密完成之后再對密文簽名啼肩，大大的簡化了它的處理邏輯。

它密文的構(gòu)成方式和 AES GCM 是差不多的衙伶，是 1 字節(jié)的 prefix祈坠，4 字節(jié)的 KeyID，然后剩下的就是密文矢劲。這里的密文是 nonce （nonce 你可以理解為隨機(jī)字符）和密文拼接在一起形成的赦拘。

這兩個(gè)算法，一般選擇用在沒有對 AES 做過優(yōu)化的處理器平臺(tái)上卧须，比如嵌入式處理器另绩，而 armv8 之后，就做了對 AES 的優(yōu)化處理花嘶。

總結(jié)

由于 Tink 的封裝的特別好笋籽，所以作為使用者來說，這些底層的內(nèi)容是可以不用了解的椭员。但對于加解密這樣關(guān)鍵的操作來說车海，知道一些框架底層的原理還是大有好處的“鳎總比搞錯(cuò)了技術(shù)細(xì)節(jié)導(dǎo)致無法對密文解密花的時(shí)間和金錢上的損失少得多侍芝。

而且通過對 Tink 的學(xué)習(xí)，學(xué)可以掌握 Google 對代碼進(jìn)行封裝的能力埋同，可以將非常復(fù)雜的操作都封裝到低層來實(shí)現(xiàn)州叠，上層只需要調(diào)用簡單的幾個(gè) API 就可以了。這樣的寫代碼的抽象水平凶赁，可以好好的領(lǐng)悟下咧栗。

現(xiàn)在，我們知道了一些非常安全的實(shí)現(xiàn)對稱加密算法的方式虱肄，當(dāng)然也可以將其用到其它的地方致板，不至于犯一些低級的錯(cuò)誤，也不需要再考慮什么 CBC咏窿、ECB 等這樣的加密模式斟或，也不會(huì)忘記對密文進(jìn)行簽名。

這樣集嵌，會(huì)對以后開發(fā)加解密相關(guān)的功能更有信心萝挤。