關(guān)于加密數(shù)據(jù)的填充方式的研究

樊志英

摘要： 針對不同平臺環(huán)境下加解密的互通問題，結(jié)合Java平臺下密碼擴(kuò)展服務(wù)SunJCE提供的加密類函數(shù)Cipher，對加密算法中使用到的明文填充方式進(jìn)行闡述。詳細(xì)介紹加密時明文數(shù)據(jù)的常用填充規(guī)則，并比較數(shù)據(jù)填充前后的區(qū)別，深入分析SunJCE支持的填充方式與常用填充規(guī)則的對應(yīng)性，并對RSA算法的加解密互通進(jìn)行了測試。加密數(shù)據(jù)填充方式的研究，為Java平臺與其他平臺之間加解密參數(shù)的約定提供了依據(jù)。雙方只有遵循相同的填充和去填充規(guī)則，才能實(shí)現(xiàn)有效的解密。

關(guān)鍵詞： SunJCE； Cipher； 加密模式； 填充

中圖分類號： TN911?34 文獻(xiàn)標(biāo)識碼： A 文章編號： 1004?373X（2014）22?0020?04

Study on mode and padding in encryption algorithm

FAN Zhi?ying

（The First Research Institute of Ministry of Public Security of P.R.C， Beijing 100048， China）

Abstract： Aiming at the interoperability of encryption and decryption in different platform environment， the two important parameters which are encryption mode and padding method used in encryption algorithm are elaborated in combination with encryption function Cipher provided by the encryption extended service on the Java platform. The rules in the encryption mode are discussed in detail， and their advantages， disadvantages and application scope are compared. The difference between the plaintext data before and after padding is analyzed in depth， which can narrow the range of encryption and decryption parameters for Java and other platforms， and can effectively solve the interaction problem between encryption and decryption.

Keywords： SunJCE； Cipher； encryption mode； padding

0 引 言

對網(wǎng)絡(luò)中傳輸?shù)男畔⑦M(jìn)行加密，可以有效地保護(hù)重要信息和敏感信息的安全。但是在計算機(jī)軟件開發(fā)中，編程語言種類繁多，雖然都提供標(biāo)準(zhǔn)算法的支持，但如果沒有統(tǒng)一加密算法中的參數(shù)，不同語言環(huán)境下的通信雙方往往不能正確解密。一般情況下，使用不同語言開發(fā)的雙方只有約定加密模式和明文填充方式，保證字節(jié)序列相同，保證密鑰的生成方式與編碼相同，使用相同字符編解碼方式等，才可以保證加解密雙方的互通。本文主要結(jié)合Sun公司的Java加密擴(kuò)展（Java Cryptography Extension，SunJCE）服務(wù)提供的加密類—Cipher，對加密模式和明文填充方式這兩個重要參數(shù)的進(jìn)行了深入分析，為加解密參數(shù)約定提供參考。

1 加密類Cipher參數(shù)分析

使用Java編程實(shí)現(xiàn)時，SunJCE提供的加密類Cipher包含了多種公開的對稱和非對稱加密算法。為了創(chuàng)建Cipher對象，需要調(diào)用Cipher類的getInstance方法，并傳遞一個transformation參數(shù)。其中在獲取cipher實(shí)例的時候使用的API為：

static Cipher getInstance（String transformation， String provider）

其中provider的名稱是可選參數(shù)，默認(rèn)為SunJCE提供者。transformation的格式為：“algorithm/mode/padding”。表1詳細(xì)列出了transformation的參數(shù)，后節(jié)主要針對下表中的填充方式進(jìn)行深入分析[1]。

2 填充方式

從表1可以看出，SunJCE加密算法中提供的模式有：電子密碼本模式（ECB）、密碼分組鏈接模式（CBC）、密碼反饋模式（CFB）、輸出反饋模式（OFB）、計數(shù)器模式（CTR）、密碼文本盜用模式（CTS）、擴(kuò)散密碼分組鏈接模式（PCBC），還有一種模式為NONE，它表示在加解密過程中不使用任何模式。由于不同平臺和不同編程語言遵循的加密模式具有一致的定義，因此只要加解密雙方按照協(xié)商指定模式進(jìn)行加解密即可。

表1 SunJCE Provider支持的Cipher的詳細(xì)信息

而對數(shù)據(jù)在加密時進(jìn)行填充、解密時去除填充則是通信雙方需要重點(diǎn)考慮的因素。對原文進(jìn)行填充，主要基于以下原因：首先，考慮安全性。由于對原始數(shù)據(jù)進(jìn)行了填充，使原文能夠“偽裝”在填充后的數(shù)據(jù)中，使得攻擊者很難找到真正的原文位置。其次，由于塊加密算法要求原文數(shù)據(jù)長度為固定塊大小的整數(shù)倍，如果加密原文不滿足這個條件，則需要在加密前填充原文數(shù)據(jù)至固定塊大小的整數(shù)倍。另外，填充也為發(fā)送方與接收方提供了一種標(biāo)準(zhǔn)的形式以約束加密原文的大小[2]。只有加解密雙方知道填充方式，才可知道如何準(zhǔn)確移去填充的數(shù)據(jù)并進(jìn)行解密。

2.1 常用填充方式

常用的填充方式至少有5種[3]，不同編程語言實(shí)現(xiàn)加解密時用到的填充多數(shù)來自于這些方式或它們的變種方式。

（1） 填充數(shù)據(jù)為填充字節(jié)序列的長度

這種填充方式中，填充字符串由一個字節(jié)序列組成，每個字節(jié)填充該字節(jié)序列的長度。假定塊長度為8，原文數(shù)據(jù)長度為9，則填充字節(jié)數(shù)等于0x07；如果明文數(shù)據(jù)長度為8的整數(shù)倍，則填充字節(jié)數(shù)為0x08。填充字符串如下：

原文數(shù)據(jù)1：FF FF FF FF FF FF FF FF FF

填充后數(shù)據(jù)1：FF FF FF FF FF FF FF FF FF 07 07 07 07 07 07 07

原文數(shù)據(jù)2：FF FF FF FF FF FF FF FF

填充后數(shù)據(jù)2：FF FF FF FF FF FF FF FF 08 08 08 08 08 08 08 08

（2） 填充數(shù)據(jù)為0x80后加0x00

這種填充方式中，填充字符串的第一個字節(jié)數(shù)是0x80，后面的每個字節(jié)是0x00。假定塊長度為8，原文數(shù)據(jù)長度為9或者為8的整數(shù)倍，則填充字符串如下：

原文數(shù)據(jù)1：FF FF FF FF FF FF FF FF FF

填充后數(shù)據(jù)1：FF FF FF FF FF FF FF FF FF 80 00 00 00 00 00 00

原文數(shù)據(jù)2：FF FF FF FF FF FF FF FF

填充后數(shù)據(jù)2：FF FF FF FF FF FF FF FF 80 00 00 00 00 00 00 00

（3） 填充數(shù)據(jù)的最后一個字節(jié)為填充字節(jié)序列的長度

這種填充方式中，填充字符串的最后一個字節(jié)為該字節(jié)序列的長度，而前面的字節(jié)可以是0x00，也可以是隨機(jī)的字節(jié)序列。假定塊長度為8，原文數(shù)據(jù)長度為9或者為8的整數(shù)倍，則填充字符串如下：

原文數(shù)據(jù)1：FF FF FF FF FF FF FF FF FF

填充后數(shù)據(jù)1：FF FF FF FF FF FF FF FF FF 00 00 00 00 00 00 07或FF FF FF FF FF FF FF FF FF 58 B3 98 9B AD F4 07

原文數(shù)據(jù)2：FF FF FF FF FF FF FF FF

填充后數(shù)據(jù)2：FF FF FF FF FF FF FF FF 00 00 00 00 00 00 00 08或FF FF FF FF FF FF FF FF 32 58 B3 98 9B AD F4 08

（4） 填充數(shù)據(jù)為空格

這種填充方式中，填充字符串的每個字節(jié)為空格對應(yīng)的字節(jié)數(shù)0x20。假定塊長度為8，原文數(shù)據(jù)長度為9或者為8的整數(shù)倍，則填充字符串如下：

原文數(shù)據(jù)1：FF FF FF FF FF FF FF FF FF

填充后數(shù)據(jù)1：FF FF FF FF FF FF FF FF FF 20 20 20 20 20 20 20

原文數(shù)據(jù)2：FF FF FF FF FF FF FF FF

填充后數(shù)據(jù)2：FF FF FF FF FF FF FF FF 20 20 20 20 20 20 20 20

（5） 填充數(shù)據(jù)為0x00

這種填充方式中，填充字符串的每個字節(jié)為0x00。假定塊長度為8，原文數(shù)據(jù)長度為9或者為8的整數(shù)倍，則填充字符串如下：

原文數(shù)據(jù)1：FF FF FF FF FF FF FF FF FF

填充后數(shù)據(jù)1：FF FF FF FF FF FF FF FF FF 00 00 00 00 00 00 00

原文數(shù)據(jù)2：FF FF FF FF FF FF FF FF

填充后數(shù)據(jù)2：FF FF FF FF FF FF FF FF 00 00 00 00 00 00 00 00

在填充方式（4）和方式（5）中，由于缺少填充數(shù)據(jù)長度的標(biāo)識信息，如果原文數(shù)據(jù)的后幾個字節(jié)本身包括空格或0，將不能夠準(zhǔn)確移去填充的數(shù)據(jù)。

因此使用這樣的填充方式時，對原文數(shù)據(jù)有一定的要求。

2.2 SunJCE支持的填充方式

從表1可以看出，SunJCE Provider支持的填充方式有：ISO10126Padding，PKCS5Padding（或PKCS7Padding），PKCS1Padding，OAEPWithAndPadding。

（1） ISO10126Padding

ISO10126Padding填充方式在W3C推薦標(biāo)準(zhǔn)“XML Encryption Syntax and Processing”中有詳細(xì)描述[4]。它與2.1節(jié)填充方式（3）相對應(yīng)。

（2） PKCS5Padding

PKCS5Padding或PKCS7Padding是RSA公司的公鑰密碼學(xué)標(biāo)準(zhǔn)[5]——PKCS #5文檔中定義的填充方式。它與2.1節(jié)填充方式（1）相對應(yīng)。

（3） PKCS1Padding

PKCS1Padding是RSA公司的公鑰密碼學(xué)標(biāo)準(zhǔn)——PKCS #1 （v1.5）[6]文檔中定義的填充方式，它是RSA算法實(shí)現(xiàn)加解密操作時常使用的一種填充。

PKCS #1（v1.5）文檔中描述了PKCS1Padding的實(shí)現(xiàn)過程。加密塊是一個8位字節(jié)串EB，它由塊標(biāo)記BT，填充塊PS和數(shù)據(jù)D組成，即EB = 00 || BT || PS || 00 || D。其中，塊標(biāo)記BT是一個標(biāo)記字節(jié)，表示加密塊的結(jié)構(gòu)。BT有三個取值00，01，或02值，其中私鑰操作為00或01，公鑰操作為02。|| PS ||為填充的數(shù)據(jù)，對于00型，填充串為0x00；對于01型，填充串為0xFF；對于02型，填充串為假散列生成的非0值。

PKCS #1（v1.5）中規(guī)定當(dāng)RSA的密鑰長度是1 024 b，如果使用PKCS1Padding填充，則原文數(shù)據(jù)長度必須小于117 B，即至少有8 B需要填充。

如果原文不滿足長度要求，則在加密前需要進(jìn)行填充。假定原文數(shù)據(jù)長度為96 B，則填充處理后字符串分別如下：

原文數(shù)據(jù)：

61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70

71 72 73 74 75 76 77 78 79 7A 30 31 32 33 34 35

61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70

71 72 73 74 75 76 77 78 79 7A 30 31 32 33 34 35

61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70

71 72 73 74 75 76 77 78 79 7A 30 31 32 33 34 35

私鑰操作，00型，填充后數(shù)據(jù)：

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70

……

私鑰操作，01型，填充后數(shù)據(jù)：

00 01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00

61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70

……

公鑰操作，02型，填充后數(shù)據(jù)：

00 02 58 DE B9 E7 15 46 16 D9 74 9D EC BE C0 EA

B5 EC BB B5 0D C4 29 95 6C 18 17 BE 41 57 19 00

61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70

……

從填充后的數(shù)據(jù)可以看出，對于00型的私鑰操作，要求原文數(shù)據(jù)必須不能包含0x00，或者知曉數(shù)據(jù)長度，否則將不能準(zhǔn)確移去填充數(shù)據(jù)。因此在加解密操作中，常使用01型的私鑰操作和02型的公鑰操作。

（4） OAEPWithAndPadding

OAEPWithAndPadding是RSA公司的公鑰密碼學(xué)標(biāo)準(zhǔn)——PKCS #1（v2.1）[7]文檔中定義的填充方式，其中為數(shù)字摘要算法，為掩模生成函數(shù)。該填充方式也是RSA算法實(shí)現(xiàn)加解密操作時可以使用的一種填充，相對于PKCS1Padding，它生成的原文數(shù)據(jù)進(jìn)行加密比較安全，但加密速度比較慢。

PKCS #1（v2.1）文檔中描述了OAEPWithAndPadding的實(shí)現(xiàn)過程。生成加密塊的過程可以分為以下三步[8]：

①M(fèi)1=Mask（H（P））‖PS‖01‖M），S），

②M2=Mask（S，M1），

③MP=00‖M2‖M1。

其中：M為原文數(shù)據(jù)；P為給定字符串（默認(rèn)情況時為空字符串）；函數(shù)H（）為哈希運(yùn)算；函數(shù)Mask（）為掩模生成函數(shù)；PKCS #1（v2.1）文檔中定義該函數(shù)為MGF1；S為隨機(jī)種子；PS為填充字符串，每個字節(jié)0x00；MP為最終生成的加密塊。

如果使用OAEPWithAndPadding，則原文數(shù)據(jù)的最大長度為Maxlen=Klen-zhlen-2 ，其中Klen表示密鑰的長度，hlen表示摘要運(yùn)算后數(shù)據(jù)的長度。假如密鑰長度為128 B，為SHA1，則原文數(shù)據(jù)最大為86 B。該填充方式只能用在公鑰加密、私鑰解密的操作中。假定原文長度16 B，使用OAEPWithSHA1AndMGF1Padding填充處理后字符串如下：

原文數(shù)據(jù)：

61 62 63 64 65 66 30 31 32 33 34 35 36 37 38 39

填充后數(shù)據(jù)：

00 31 1E B5 65 F2 C2 BF D1 F9 49 AD 46 EE A3 80

DA 67 30 B8 17 99 9D 42 3F E8 7F EB 44 5A FF CD

82 B1 C7 D0 75 4D C7 3B 0C A0 B6 49 A4 F9 E8 D3

21 6F 68 D4 A6 EE 1A 34 DE A9 A2 90 84 B7 20 C8

68 B9 7B 36 E1 7F 83 5E B8 D2 1B 56 8C 24 01 9C

ED 33 4A C7 11 2E E4 65 83 D7 10 46 F7 27 7E E4

5C 9F 69 9D 86 8B FC 72 EB FA 70 A4 3C 88 76 AF

EC B6 D7 89 E3 98 F4 0E 68 24 EF 48 AE 37 85 5C

深入分析和理解SunJCE Provider支持的加密類Cipher參數(shù)中的填充方式，就能夠在Java環(huán)境下選擇和確定加解密時傳入的參數(shù)。Java環(huán)境下，常用對稱加密算法常使用ECB或CBC模式、PKCS5Padding（或PKCS7Padding）填充方式；對于非對稱加密算法RSA，則經(jīng)常使用ECB或NONE無模式、PKCS1Padding填充方式。對Java環(huán)境下使用RSA公鑰實(shí)現(xiàn)加密，C環(huán)境下使用RSA私鑰實(shí)現(xiàn)解密進(jìn)行了測試。測試中，約定了加密模式為ECB、填充方式為PKCS #1中定義的方式。

原始明文數(shù)據(jù)：

30 31 32 33 34 35 36 37 38 39 61 62 63 64 65

填充后的數(shù)據(jù)：

00 02 57 5B 7A 5F 93 B8 96 09 B7 5E 4D B0 4D 1E

D2 C7 2E 04 1C 60 A6 CF D2 E3 25 C9 ED 47 60 77

75 E3 47 82 6E 46 ED 76 2A B8 A0 B4 14 B7 0F 37

48 96 45 26 E0 67 51 58 45 27 1E 9F B4 2F 96 79

E9 89 E9 DE 29 72 B5 A8 C3 71 54 0D 75 53 59 9E

43 30 04 20 2C 4D B5 2A D4 45 7A FA FC 48 2F 52

1E 62 A0 1E A8 4A 5D 0B 34 52 D2 6F FF AA C4 E2

00 30 31 32 33 34 35 36 37 38 39 61 62 63 64 65

加密后的數(shù)據(jù)：

71 89 28 DC 9C 62 50 B1 9D 21 BC 26 AB A6 50 1B

80 7E BC FE CC A6 5E 9F BC 9A 8A 2E 69 B2 90 EE

8F F9 A0 F9 32 C2 C8 B7 D5 01 8D 73 3C 0C FA B5

FE 6E 2A 4F 19 0C 62 42 E4 66 45 8A DD CA AE 55

12 35 E0 6C F3 0F FC B4 95 BB B0 44 09 09 F9 5A

D9 DD F4 B2 B5 63 D6 C6 4F 8D 67 62 6D 69 7B 31

C2 17 A4 04 F8 67 A3 3F C4 6E 4D 94 8A 38 E5 BA

63 94 BB 17 41 15 27 48 33 34 90 79 1B 3A FD E4

解密后的數(shù)據(jù)：

00 02 57 5B 7A 5F 93 B8 96 09 B7 5E 4D B0 4D 1E

D2 C7 2E 04 1C 60 A6 CF D2 E3 25 C9 ED 47 60 77

75 E3 47 82 6E 46 ED 76 2A B8 A0 B4 14 B7 0F 37

48 96 45 26 E0 67 51 58 45 27 1E 9F B4 2F 96 79

E9 89 E9 DE 29 72 B5 A8 C3 71 54 0D 75 53 59 9E

43 30 04 20 2C 4D B5 2A D4 45 7A FA FC 48 2F 52

1E 62 A0 1E A8 4A 5D 0B 34 52 D2 6F FF AA C4 E2

00 30 31 32 33 34 35 36 37 38 39 61 62 63 64 65

去填充后的數(shù)據(jù)：

30 31 32 33 34 35 36 37 38 39 61 62 63 64 65

從測試數(shù)據(jù)可以看到，Java環(huán)境下的服務(wù)端使用公鑰加密后，通過網(wǎng)絡(luò)將密文傳輸?shù)紺環(huán)境下的客戶端，客戶端使用私鑰和指定加密模式對數(shù)據(jù)進(jìn)行解密，再利用PKCS1Padding的填充原理將填充部分移去，即可獲得正確的原文。

3 結(jié) 語

本文圍繞著Java編程環(huán)境下SunJCE提供的加密類——Cipher，對加密模式和填充方式展開了分析，并運(yùn)用實(shí)例對填充方式進(jìn)行了解釋。在不同語言環(huán)境下的通信雙方，根據(jù)傳輸信息的重要程度來協(xié)商加密的模式和填充方式。雙方不但能夠在通信中保護(hù)重要敏感的信息，還能夠利用模式與填充方式的原理，在接收信息時成功實(shí)現(xiàn)解密。

參考文獻(xiàn)

[1] Sun Microsystems. Java cryptography architecture Sun providers documentation for Java platform standard [M]. 6 ed. USA： Sun Microsystems， 2011.

[2] MEYERS R K， FRANK C E. Implementing your own cryptographic provider using the Java cryptography extension [R]. [S.l.]： [s.n.]， 2011.

[3] Anon. Using padding in encryption [EB/OL]. [2013?01?28]. http：//www.di?mgt.com.au/cryptopad.html.

[4] W3C. XML encryption syntax and processing [EB/OL]. [2002?12?10]. http：//www.w3.org/TR/2002/REC?xmlenc?core.

[5] RSA. PKCS #5： password?basedencryption standard， version 1.5 [S]. UK： RSA， 1993.

[6] RSA. PKCS #1： RSA encryption standard， version 1.5 [S]. UK： RSA， 1993.

[7] RSA. PKCS #1： RSA encryption standard， version 2.1 [S]. UK： RSA， 2002.

[8] HOOK David. Beginning cryptography with Java [M]. [S.l.]： [s.n.]， 2005.

[9] Sun Microsystems. Java cryptography extension reference guide 5.0 for the Java 2 platform standard edition development kit （JDK） 5.0 [R]. [2004?01?29]. http：// www. docs.oracle.com/j.

[10] SCHNEIER Bruce.應(yīng)用密碼學(xué)（協(xié)議算法與C源程序）[M].吳世忠，譯.北京：機(jī)械工業(yè)出版社，2000.