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

　　關鍵詞：核心期刊論文發表代理,SunJCE,Cipher,加密模式,填充

　　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 引 言

　　對網絡中傳輸的信息進行加密，可以有效地保護重要信息和敏感信息的安全。但是在計算機軟件開發中，編程語言種類繁多，雖然都提供標準算法的支持，但如果沒有統一加密算法中的參數，不同語言環境下的通信雙方往往不能正確解密。一般情況下，使用不同語言開發的雙方只有約定加密模式和明文填充方式，保證字節序列相同，保證密鑰的生成方式與編碼相同，使用相同字符編解碼方式等，才可以保證加解密雙方的互通。本文主要結合Sun公司的Java加密擴展(Java Cryptography Extension，SunJCE)服務提供的加密類―Cipher，對加密模式和明文填充方式這兩個重要參數的進行了深入分析，為加解密參數約定提供參考。

　　1 加密類Cipher參數分析

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

　　static Cipher getInstance(String transformation， String provider)

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

　　2 填充方式

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

　　表1 SunJCE Provider支持的Cipher的詳細信息

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

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

　　(1) 填充數據為填充字節序列的長度

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

　　原文數據1：FF FF FF FF FF FF FF FF FF

　　填充后數據1：FF FF FF FF FF FF FF FF FF 07 07 07 07 07 07 07

　　原文數據2：FF FF FF FF FF FF FF FF

　　填充后數據2：FF FF FF FF FF FF FF FF 08 08 08 08 08 08 08 08

　　(2) 填充數據為0x80后加0x00

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

　　原文數據1：FF FF FF FF FF FF FF FF FF

　　填充后數據1：FF FF FF FF FF FF FF FF FF 80 00 00 00 00 00 00

　　原文數據2：FF FF FF FF FF FF FF FF

　　填充后數據2：FF FF FF FF FF FF FF FF 80 00 00 00 00 00 00 00

　　(3) 填充數據的最后一個字節為填充字節序列的長度

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

　　原文數據1：FF FF FF FF FF FF FF FF FF

　　填充后數據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

　　原文數據2：FF FF FF FF FF FF FF FF

　　填充后數據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) 填充數據為空格

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

　　原文數據1：FF FF FF FF FF FF FF FF FF

　　填充后數據1：FF FF FF FF FF FF FF FF FF 20 20 20 20 20 20 20

　　原文數據2：FF FF FF FF FF FF FF FF

　　填充后數據2：FF FF FF FF FF FF FF FF 20 20 20 20 20 20 20 20

　　(5) 填充數據為0x00

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

　　原文數據1：FF FF FF FF FF FF FF FF FF

　　填充后數據1：FF FF FF FF FF FF FF FF FF 00 00 00 00 00 00 00

　　原文數據2：FF FF FF FF FF FF FF FF

　　填充后數據2：FF FF FF FF FF FF FF FF 00 00 00 00 00 00 00 00

　　在填充方式(4)和方式(5)中，由于缺少填充數據長度的標識信息，如果原文數據的后幾個字節本身包括空格或0，將不能夠準確移去填充的數據。

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

　　2.2 SunJCE支持的填充方式

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

　　(1) ISO10126Padding

　　ISO10126Padding填充方式在W3C推薦標準“XML Encryption Syntax and Processing”中有詳細描述[4]。它與2.1節填充方式(3)相對應。

　　(2) PKCS5Padding

　　PKCS5Padding或PKCS7Padding是RSA公司的公鑰密碼學標準[5]――PKCS #5文檔中定義的填充方式。它與2.1節填充方式(1)相對應。

　　(3) PKCS1Padding

　　PKCS1Padding是RSA公司的公鑰密碼學標準――PKCS #1 (v1.5)[6]文檔中定義的填充方式，它是RSA算法實現加解密操作時常使用的一種填充。

　　PKCS #1(v1.5)文檔中描述了PKCS1Padding的實現過程。加密塊是一個8位字節串EB，它由塊標記BT，填充塊PS和數據D組成，即EB = 00 || BT || PS || 00 || D。其中，塊標記BT是一個標記字節，表示加密塊的結構。BT有三個取值00，01，或02值，其中私鑰操作為00或01，公鑰操作為02。|| PS ||為填充的數據，對于00型，填充串為0x00;對于01型，填充串為0xFF;對于02型，填充串為假散列生成的非0值。 　　PKCS #1(v1.5)中規定當RSA的密鑰長度是1 024 b，如果使用PKCS1Padding填充，則原文數據長度必須小于117 B，即至少有8 B需要填充。

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

　　原文數據：

　　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型，填充后數據：

　　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型，填充后數據：

　　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型，填充后數據：

　　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

　　……

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

　　(4) OAEPWithAndPadding

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

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

　　①M1=Mask(H(P))‖PS‖01‖M)，S)，

　　②M2=Mask(S，M1)，

　　③MP=00‖M2‖M1。

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

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

　　原文數據：

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

　　填充后數據：

　　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參數中的填充方式，就能夠在Java環境下選擇和確定加解密時傳入的參數。Java環境下，常用對稱加密算法常使用ECB或CBC模式、PKCS5Padding(或PKCS7Padding)填充方式;對于非對稱加密算法RSA，則經常使用ECB或NONE無模式、PKCS1Padding填充方式。對Java環境下使用RSA公鑰實現加密，C環境下使用RSA私鑰實現解密進行了測試。測試中，約定了加密模式為 ECB、填充方式為PKCS #1中定義的方式。 　　原始明文數據：

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

　　填充后的數據：

　　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

　　加密后的數據：

　　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

　　解密后的數據：

　　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

　　去填充后的數據：

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

　　從測試數據可以看到，Java環境下的服務端使用公鑰加密后，通過網絡將密文傳輸到C環境下的客戶端，客戶端使用私鑰和指定加密模式對數據進行解密，再利用PKCS1Padding的填充原理將填充部分移去，即可獲得正確的原文。

　　3 結 語

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

　　參考文獻

　　[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.