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

　　關(guān)鍵詞：核心期刊論文發(fā)表代理,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 引 言

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

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

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

　　static Cipher getInstance(String transformation， String provider)

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

　　2 填充方式

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

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

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

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

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

　　這種填充方式中，填充字符串由一個(gè)字節(jié)序列組成，每個(gè)字節(jié)填充該字節(jié)序列的長(zhǎng)度。假定塊長(zhǎng)度為8，原文數(shù)據(jù)長(zhǎng)度為9，則填充字節(jié)數(shù)等于0x07;如果明文數(shù)據(jù)長(zhǎng)度為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

　　這種填充方式中，填充字符串的第一個(gè)字節(jié)數(shù)是0x80，后面的每個(gè)字節(jié)是0x00。假定塊長(zhǎng)度為8，原文數(shù)據(jù)長(zhǎng)度為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ù)的最后一個(gè)字節(jié)為填充字節(jié)序列的長(zhǎng)度

　　這種填充方式中，填充字符串的最后一個(gè)字節(jié)為該字節(jié)序列的長(zhǎng)度，而前面的字節(jié)可以是0x00，也可以是隨機(jī)的字節(jié)序列。假定塊長(zhǎng)度為8，原文數(shù)據(jù)長(zhǎng)度為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ù)為空格

　　這種填充方式中，填充字符串的每個(gè)字節(jié)為空格對(duì)應(yīng)的字節(jié)數(shù)0x20。假定塊長(zhǎng)度為8，原文數(shù)據(jù)長(zhǎng)度為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

　　這種填充方式中，填充字符串的每個(gè)字節(jié)為0x00。假定塊長(zhǎng)度為8，原文數(shù)據(jù)長(zhǎng)度為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ù)長(zhǎng)度的標(biāo)識(shí)信息，如果原文數(shù)據(jù)的后幾個(gè)字節(jié)本身包括空格或0，將不能夠準(zhǔn)確移去填充的數(shù)據(jù)。

　　因此使用這樣的填充方式時(shí)，對(duì)原文數(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)相對(duì)應(yīng)。

　　(2) PKCS5Padding

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

　　(3) PKCS1Padding

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

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

　　如果原文不滿足長(zhǎng)度要求，則在加密前需要進(jìn)行填充。假定原文數(shù)據(jù)長(zhǎng)度為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ù)可以看出，對(duì)于00型的私鑰操作，要求原文數(shù)據(jù)必須不能包含0x00，或者知曉數(shù)據(jù)長(zhǎng)度，否則將不能準(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)加解密操作時(shí)可以使用的一種填充，相對(duì)于PKCS1Padding，它生成的原文數(shù)據(jù)進(jìn)行加密比較安全，但加密速度比較慢。

　　PKCS #1(v2.1)文檔中描述了OAEPWithAndPadding的實(shí)現(xiàn)過(guò)程。生成加密塊的過(guò)程可以分為以下三步[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í)為空字符串);函數(shù)H()為哈希運(yùn)算;函數(shù)Mask()為掩模生成函數(shù);PKCS #1(v2.1)文檔中定義該函數(shù)為MGF1;S為隨機(jī)種子;PS為填充字符串，每個(gè)字節(jié)0x00;MP為最終生成的加密塊。

　　如果使用OAEPWithAndPadding，則原文數(shù)據(jù)的最大長(zhǎng)度為Maxlen=Klen-zhlen-2 ，其中Klen表示密鑰的長(zhǎng)度，hlen表示摘要運(yùn)算后數(shù)據(jù)的長(zhǎng)度。假如密鑰長(zhǎng)度為128 B，為SHA1，則原文數(shù)據(jù)最大為86 B。該填充方式只能用在公鑰加密、私鑰解密的操作中。假定原文長(zhǎng)度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支持的加密類(lèi)Cipher參數(shù)中的填充方式，就能夠在Java環(huán)境下選擇和確定加解密時(shí)傳入的參數(shù)。Java環(huán)境下，常用對(duì)稱加密算法常使用ECB或CBC模式、PKCS5Padding(或PKCS7Padding)填充方式;對(duì)于非對(duì)稱加密算法RSA，則經(jīng)常使用ECB或NONE無(wú)模式、PKCS1Padding填充方式。對(duì)Java環(huán)境下使用RSA公鑰實(shí)現(xiàn)加密，C環(huán)境下使用RSA私鑰實(shí)現(xiàn)解密進(jìn)行了測(cè)試。測(cè)試中，約定了加密模式為 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

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

　　3 結(jié) 語(yǔ)

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