| 为什么RSA公钥每次加密得到的结果都不一样？ | 您所在的位置：网站首页 › 为什么数据比对不成功 › 为什么RSA公钥每次加密得到的结果都不一样？ |
为什么RSA公钥每次加密得到的结果都不一样？
|
《OpenSSL和Python实现RSA Key公钥加密私钥解密》中提到，发现使用RSA公钥对同一数据加密，每次的结果都不一样。百度一下，很多人都有这个疑问，但并没有看到详细的分析解答，即使有人说是因为padding填充的原因，也都是一带而过。 为什么私钥对同一数据进行签名加密的结果是一样的，使用公钥进行加密就不一样了呢？ 是的，这个问题跟对数据的padding即填充有关，详细说来，是跟PKCS #1 v1.5指定的padding方式有关，下面对这个问题进行详细的说明。 1. 问题的来源重复下这个问题的来源： 1.1 准备测试数据将字符串"I Love China!"保存到msg.bin作为测试数据 $ echo -n "I Love China!" > msg.bin $ hexdump -Cv msg.bin 00000000 49 20 4c 6f 76 65 20 43 68 69 6e 61 21 |I Love China!| 0000000d随机生成测试用的私钥key.pem，并导出公钥key_pub.pem： $ openssl genrsa -out key.pem -f4 2048 Generating RSA private key, 2048 bit long modulus ........+++ .......+++ e is 65537 (0x10001) $ openssl rsa -in key.pem -pubout -out key_pub.pem writing RSA key 1.2 使用私钥对同一数据签名使用私钥key.pem对msg.bin进行两次签名，签名结果分别为msg.bin.sig1和msg.bin.sig2： $ openssl dgst -sha256 -out msg.bin.sig1 -sign key.pem msg.bin $ openssl dgst -sha256 -out msg.bin.sig2 -sign key.pem msg.bin $ md5sum msg.bin.sig1 msg.bin.sig2 4d10a2163f92f90f114126de2371deb8 msg.bin.sig1 4d10a2163f92f90f114126de2371deb8 msg.bin.sig2从签名数据的md5校验和看，msg.bin.sig1和msg.bin.sig2的md5值一样，其内容显然是一样的。 1.3 使用公钥对同一数据加密使用公钥key_pub.pem对msg.bin进行两次加密，加密结果分别为msg.bin.enc1和msg.bin.enc2： $ openssl rsautl -in msg.bin -out msg.bin.enc1 -inkey key_pub.pem -pubin -encrypt $ openssl rsautl -in msg.bin -out msg.bin.enc2 -inkey key_pub.pem -pubin -encrypt $ md5sum msg.bin.enc1 msg.bin.enc2 19c3bf692e94eaf87770001181c5eb10 msg.bin.enc1 f576f31a796332fcd3c4d3627ef4ad5d msg.bin.enc2显然msg.bin.enc1与msg.bin.enc2的md5不一样，二者的内容也不一样，也就是说，使用同一个RSA公钥对同一段数据加密，两次加密的结果不一样。 2. PKCS #1 v1.5指定的填充方式除了PKCS #1 v1.5指定的填充方式外，后续版本对填充方式进行了更新： PKCS #1 v2.0 指定了针对加密使用的OAEP填充方式PKCS #1 v2.1 又进一步指定了针对签名使用的PSS填充方式这里只讨论早期PKCS #1 v1.5指定的简单的填充方式，也是目前最常见的填充方式。 RSA建议，为提高安全性，在新的应用中应逐步采用OAEP和PSS方式的进行填充。 2.1 填充方式的描述不管是使用RSA私钥进行签名还是公钥进行加密，操作中都需要对待处理的数据先进行填充，然后再对填充后的数据进行加密处理。针对如何对内容进行填充，"[RFC2313] PKCS #1: RSA Encryption Version 1.5"的"8.1 Encryption-block formatting"节提供了详细的说明，原文如下： 8.1 Encryption-block formatting A block type BT, a padding string PS, and the data D shall be formatted into an octet string EB, the encryption block. EB = 00 || BT || PS || 00 || D . (1) The block type BT shall be a single octet indicating the structure of the encryption block. For this version of the document it shall have value 00, 01, or 02. For a private- key operation, the block type shall be 00 or 01. For a public-key operation, it shall be 02. The padding string PS shall consist of k-3-||D|| octets. For block type 00, the octets shall have value 00; for block type 01, they shall have value FF; and for block type 02, they shall be pseudorandomly generated and nonzero. This makes the length of the encryption block EB equal to k.由于篇幅的原因，这里没有列出针对这段话的"Notes"部分，可以通过点击原文链接查看。 简单说来，PKCS #1 v1.5规定的填充格式为： EB = 00 || BT || PS || 00 || D其中： D: data （指待处理数据，即填充前的原始数据） PS: padding string （填充字符串） BT: block type （数据块类型） EB: encryption block （待加密的数据块，经过填充后结果） ||: 表示连接操作 （X||Y表示将X和Y的内容连接到一起）所以： "填充后数据" = "00" + "数据块类型" + "填充字符串" + "00" + "原始数据""填充块类型"BT决定了紧挨着的"填充字符串"PS的内容。 BT的可能取值包括00, 01和02： 针对私钥处理的数据，BT取值为00或01; BT取值为00时，PS为全00的字符串BT取值为01时，PS为全FF的字符串，通过填充得到的整数会足够大，可以阻止某些攻击，因此也是推荐的填充方式 针对公钥处理的数据，BT取值为02； 使用伪随机的16进制字符串填充PS，而且每次操作进行填充的伪随机书都是独立的重点来了，针对公钥处理的数据，其填充内容为伪随机的16进制字符串，每次操作的填充内容都不一样。这就是为什么每次使用公钥加密数据得到的结果都不一样了。 下面还是以本文开始的公钥加密数据进行说明。 2.2 检查公钥加密的填充数据第1节中，使用公钥key_pub.pem对数据msg.bin进行了加密，我们使用私钥key.pem解密看看加密前填充的数据。 2.2.1 解密msg.bin.enc1到msg.bin.enc1.dec $ openssl rsautl -in msg.bin.enc1 -out msg.bin.enc1.dec -inkey key.pem -decrypt -raw为了显示填充结构，这里用UltraEdit打开解密后的数据： 为了显示填充结构，这里用UltraEdit打开解密后的数据： 上面两张图都是对数据msg.bin进行填充后，并且在使用公钥key_pub.pem加密前的内容： 两个绿色部分是指定的“00”填充；紫色部分指定BT为02, 说明后续使用公钥处理的数据；灰色部分为PS，其根据BT=02，填充了伪随机数；橙色部分为原始数据。可见，两次填充的伪随机数是不一样，这样在使用公钥加密后其结果自然就不一样了。 我看网上有帖子说JAVA下可以通过设置，使每次填充生成同样的内容，但这样似乎不够安全。 我在openssl工具下没有找到相应的针对公钥操作时数据的填充设置选项。 2.3 检查私钥加密的填充数据在第1节的签名例子中，使用私钥签名时，会先对数据计算SHA256编码，然后对SHA256哈希进行BER编码，再进行填充。 我们可以通过对签名数据使用公钥解密后，看看填充数据的内容： $ openssl rsautl -in msg.bin.sig1 -out msg.bin.sig1.dec -inkey key_pub.pem -pubin -verify -raw注意：这里针对openssl rsault 命令使用-raw选项显示原始的数据结构，否则只会显示数据部分，而不会显示填充的内容 按照惯例，为了显示填充结构，这里用UltraEdit打开解密后的签名数据：
再来假设下BT为00的情况： 当BT为00时，此时填充的内容PS部分为全00，又由于填充格式中指定了两个“00”的分隔符，如果此时原始数据又是以“00”开始的话，如何划分填充数据和原始数据呢？ 显然此时是无法进行区分的，除非你知道原始数据由多长。幸运的是，我们基本上不会采用BT=00的填充方式，所以这种情况几乎不会发生。 3. 一个"openssl rsautl"的bug最后，以我发现的一个"openssl rsautl"命令的bug来结束本文。 在进行RSA公钥加密私钥解密时，如果加密的原始数据为全00，解密时通过-hexdump选项，无法正确在控制台显示原始数据，问题的复现步骤如下： 生成16字节全0数据： $ dd if=/dev/zero of=data.bin bs=1 count=32 32+0 records in 32+0 records out 32 bytes (32 B) copied, 0.000227422 s, 141 kB/s $ hexdump -Cv data.bin 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020使用公钥key.pem对全0数据data.bin进行加密： $ openssl rsautl -in data.bin -out data.bin.enc -inkey key_pub.pem -pubin -encrypt使用私钥解密数据，并直接在控制台显示： $ openssl rsautl -in data.bin.enc -inkey key.pem -decrypt -hexdump 0020 - $ openssl rsautl -in data.bin.enc -inkey key.pem -decrypt -hexdump -raw 0000 - 00 02 49 d0 3d 94 b6 90-8b 4e 40 e7 e4 d1 e2 90 ..I.=....N@..... 0010 - e8 18 29 7f cf 5c c7 4a-bd cc 11 97 81 b3 a7 2b ..)..\.J.......+ 0020 - c3 83 43 60 6d f9 d5 1d-e9 29 ab 51 d1 98 58 49 ..C`m....).Q..XI 0030 - 22 5b ae d2 27 d4 da bd-2b 0d ba 54 7e 04 10 b1 "[..'...+..T~... 0040 - 3b c7 a1 7d 57 02 d8 1c-53 41 91 52 2d ac 0b da ;..}W...SA.R-... 0050 - 1e 0e 0b 94 b3 90 0d 20-49 2c 94 84 22 87 30 c1 ....... I,..".0. 0060 - 31 36 6e 18 e0 52 5e ec-59 f9 36 47 37 c6 45 1e 16n..R^.Y.6G7.E. 0070 - 24 db dc 9a e4 d8 4e dc-b6 0b b2 57 f4 27 a9 56 $.....N....W.'.V 0080 - 05 11 2d 03 75 75 64 58-87 b8 86 8d 4c 3d d5 f4 ..-.uudX....L=.. 0090 - 10 34 9d 24 ab 48 b4 27-58 59 f7 27 3b 9b 39 5a .4.$.H.'XY.';.9Z 00a0 - b4 ed 2e fb 1f 6e 1f 13-b3 cd 67 78 5f ec f5 63 .....n....gx_..c 00b0 - ae 46 a7 17 87 f7 10 09-32 6d 30 dc 0e 1b 48 2a .F......2m0...H* 00c0 - 2c 27 09 bc 42 32 38 22-8c 76 c9 cb 8c e9 0d f9 ,'..B28".v...... 00d0 - 5e d0 c3 a8 af 8f cd 68-b6 96 3c 94 5c 3c d1 ^......h.. |
上图中是对SHA256数据进行BER编码填充，使用私钥key.pem加密前的内容：【本文地址】