区别

用

"SHA256withRSA"

"RSA"

"NONEwithRSA"

DigestInfo

DigestInfo ::= SEQUENCE {    digestAlgorithm DigestAlgorithm,    digest OCTET STRING}

在填充之前先进行加密，然后再加密；在后一种情况下，将对裸露的SHA256哈希值进行填充和加密。

如果它们不同，是否有办法修改方法2，使两个方法给出相同的输出？

首先，您必须

DigestInfo

"NONEwithRSA"

RFC 3447第9.2节通过在注释1中指出

1. For the six hash functions mentioned in Appendix B.1, the DER   encoding T of the DigestInfo value is equal to the following:   ...   SHA-256: (0x)30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00     04 20 || H.

使它工作

针对以上部分，OP使用更新的代码更新了他的问题。但是，不幸的是，它对他还没有起作用。从而，

OP的代码

我执行了OP的代码（SignInSteps.java）。由于他没有提供私钥，因此我使用了自己的测试密钥（demo-
rsa2048.p12）。结果：

GreenhandOriginal:1B9557B6A076226FA4C26A9370A0E9E91B627F14204D427B03294EC4BFC346FDEEFB3A483B1E5A0593F26E9DE87F9202E1064F4D75B24B8FA355B23A560AF263361BB94B2339C3A01952C447CAC862AA9DCAB64B09ABAA0AD50232CDB299D1E4B5F7138F448A87ED32BFF4B5B66F35FFA08F13FD98DFCEC7114710282E463245311DA7A56CBEA958D88137A8B507D8601464535978EFE36EE37EF721260DB7112484F244409F0BD64C823ACFB13D06ABA84A9A0C5AB207E19231D6A71CC80F07FDA2A9654F0F609C2C3396D6DFFBBB10EF4C3D4B5ADFC72EACC044E81F252B699F095CFEF8630B284B1F6BD7201367BD5FDF2BB4C20BD07B9CC20B214D86C7294B9ECA6DD47C1B230D972E7DA026165F1CE743EC96825E4C13DFE2C6437FE673A13CA622047EE7D2F7C5280198D81550A1CBD17F8E8A3C4C2D53A746FA6464AA5194FC2782527B014F017008D89BB2C80B7FA367C74FE01369986B56BCE7DC573A11ED884511F0CB12160CA5E42D488451AA8961BF5A9F71E6A5E89F19BC8EFAC26DDE989A0369667EE74372F6E558887FE2561EA926B441AB8F0FD3DEDD608A671011313372084B059CAD7E4807AC852C0873C57F216349422771C089678BAC3021D054C4427EADE70219E251617B83E68640DD7D03C3F99E47F79EB71C124F59EDEA724496A4552F2E9E1F90DDE550745E85483D823F146982C6D2008FE9AAGreenhandUpdated:method 1: 4B9ECA6DD47C1B230D972E7DA026165F1CE743EC96825E4C13DFE2C6437FE673A13CA622047EE7D2F7C5280198D81550A1CBD17F8E8A3C4C2D53A746FA6464AA5194FC2782527B014F017008D89BB2C80B7FA367C74FE01369986B56BCE7DC573A11ED884511F0CB12160CA5E42D488451AA8961BF5A9F71E6A5E89F19BC8EFAC26DDE989A0369667EE74372F6E558887FE2561EA926B441AB8F0FD3DEDD608A671011313372084B059CAD7E4807AC852C0873C57F216349422771C089678BAC3021D054C4427EADE70219E251617B83E68640DD7D03C3F99E47F79EB71C124F59EDEA724496A4552F2E9E1F90DDE550745E85483D823F146982C6D2008FE9AAmethod 2: 4B9ECA6DD47C1B230D972E7DA026165F1CE743EC96825E4C13DFE2C6437FE673A13CA622047EE7D2F7C5280198D81550A1CBD17F8E8A3C4C2D53A746FA6464AA5194FC2782527B014F017008D89BB2C80B7FA367C74FE01369986B56BCE7DC573A11ED884511F0CB12160CA5E42D488451AA8961BF5A9F71E6A5E89F19BC8EFAC26DDE989A0369667EE74372F6E558887FE2561EA926B441AB8F0FD3DEDD608A671011313372084B059CAD7E4807AC852C0873C57F216349422771C089678BAC3021D054C4427EADE70219E251617B83E68640DD7D03C3F99E47F79EB71C124F59EDEA724496A4552F2E9E1F90DDE550745E85483D823F146982C6D2008FE9AA

因此，与OP的观察相反，在更新代码的情况下，签名相等。

不承担复制和粘贴错误，可能还会涉及其他差异。

环境

我使用Java 8（1.8.0_20）添加了无限管辖权文件，并使用BouncyCastle 1.52、1.49和1.46（由于BC
API更改而对测试代码进行了少量修改）进行了测试。

OP在评论中提到：

Java是JRE 8更新66。BouncyCastle是bcprov-jdk15on-153.jar。

因此我更新了Java，仍然没有区别。

然后，我将BouncyCastle更新为1.53。实际上，突然之间结果有所不同：

GreenhandOriginal:1B9557B6A076226FA4C26A9370A0E9E91B627F14204D427B03294EC4BFC346FDEEFB3A483B1E5A0593F26E9DE87F9202E1064F4D75B24B8FA355B23A560AF263361BB94B2339C3A01952C447CAC862AA9DCAB64B09ABAA0AD50232CDB299D1E4B5F7138F448A87ED32BFF4B5B66F35FFA08F13FD98DFCEC7114710282E463245311DA7A56CBEA958D88137A8B507D8601464535978EFE36EE37EF721260DB7112484F244409F0BD64C823ACFB13D06ABA84A9A0C5AB207E19231D6A71CC80F07FDA2A9654F0F609C2C3396D6DFFBBB10EF4C3D4B5ADFC72EACC044E81F252B699F095CFEF8630B284B1F6BD7201367BD5FDF2BB4C20BD07B9CC20B214D86C7294B9ECA6DD47C1B230D972E7DA026165F1CE743EC96825E4C13DFE2C6437FE673A13CA622047EE7D2F7C5280198D81550A1CBD17F8E8A3C4C2D53A746FA6464AA5194FC2782527B014F017008D89BB2C80B7FA367C74FE01369986B56BCE7DC573A11ED884511F0CB12160CA5E42D488451AA8961BF5A9F71E6A5E89F19BC8EFAC26DDE989A0369667EE74372F6E558887FE2561EA926B441AB8F0FD3DEDD608A671011313372084B059CAD7E4807AC852C0873C57F216349422771C089678BAC3021D054C4427EADE70219E251617B83E68640DD7D03C3F99E47F79EB71C124F59EDEA724496A4552F2E9E1F90DDE550745E85483D823F146982C6D2008FE9AAGreenhandUpdated:method 1: 6BAAAC1060B6D0D56AD7D45A1BEECE82391088FF47A8D8179EFBBEB0925C4AC6C9DFC56F672E99F4A6E3C106A866B70513C25AE11B267286C584A136FBC20C4D1E7B10697352DF020BA5D67029A6EF890B2674F02C496CB1F1EBB0D4DBB580EB045DBB0FA0D7D73B418FF63F345658C6C73DA742FE260C9639C94967A928F74F61DACA03310B9986C32D83CAB8C7FC13E80612CCFC0B7E3E35BEA04EAEBDAA55FB8837B4661DC71499B4A0B1D36E1D23D9927CDB55C237D5AB2E5C088F29C6FAFAD9FE64DD4851CEC113560864E9923D485D0C6E092C8EBE82D29C312E5835B38EE9BD6B8B4BCC753EF4EE4D0977B2E781B391839E3EC31C36E5B1AA0CE90227method 2: 4B9ECA6DD47C1B230D972E7DA026165F1CE743EC96825E4C13DFE2C6437FE673A13CA622047EE7D2F7C5280198D81550A1CBD17F8E8A3C4C2D53A746FA6464AA5194FC2782527B014F017008D89BB2C80B7FA367C74FE01369986B56BCE7DC573A11ED884511F0CB12160CA5E42D488451AA8961BF5A9F71E6A5E89F19BC8EFAC26DDE989A0369667EE74372F6E558887FE2561EA926B441AB8F0FD3DEDD608A671011313372084B059CAD7E4807AC852C0873C57F216349422771C089678BAC3021D054C4427EADE70219E251617B83E68640DD7D03C3F99E47F79EB71C124F59EDEA724496A4552F2E9E1F90DDE550745E85483D823F146982C6D2008FE9AA

有趣的是，仅更新后的代码中方法1的值有所不同。因此，在这种情况下，我研究了中介对象

[BC 1.52]hash: 03AC674216F3E15C761EE1A5E255F067953623C8B388B4459E13F978D7C846F4algo: 2.16.840.1.101.3.4.2.1info: 3031300D06096086480165030402010500042003AC674216F3E15C761EE1A5E255F067953623C8B388B4459E13F978D7C846F4[BC 1.53]hash: 03AC674216F3E15C761EE1A5E255F067953623C8B388B4459E13F978D7C846F4algo: 2.16.840.1.101.3.4.2.1info: 302F300B0609608648016503040201042003AC674216F3E15C761EE1A5E255F067953623C8B388B4459E13F978D7C846F4

因此，BouncyCastle 1.53对DigestInfo对象的编码方式不同！1.52（及以下）中的编码是RFC
3447第9.2节所期望的编码。

查看ASN.1转储，您会发现BC 1.52将AlgorithmIdentifier编码为

 2  13:   SEQUENCE {   <06 09> 4   9:     OBJECT IDENTIFIER sha-256 (2 16 840 1 101 3 4 2 1)      :       (NIST Algorithm)   <05 00>15   0:     NULL      :     }

而BC 1.53创造了

 2  11:   SEQUENCE {   <06 09> 4   9:     OBJECT IDENTIFIER sha-256 (2 16 840 1 101 3 4 2 1)      :       (NIST Algorithm)      :     }

因此在1.53中，算法参数完全丢失。这建议更改线

AlgorithmIdentifier sha256Aid = new AlgorithmIdentifier(NISTObjectIdentifiers.id_sha256, null);

至

AlgorithmIdentifier sha256Aid = new AlgorithmIdentifier(NISTObjectIdentifiers.id_sha256, DERNull.INSTANCE);

突然之间，它也可以与BouncyCastle 1.53一起使用，方法1和方法2的值一致！;）

TL; DR

null

AlgorithmIdentifier

DERNull.INSTANCE

我怎么

OP在评论中表示他想进一步了解

1. 您如何检查BouncyCastle的中间对象和
2. 您如何产生ASN.1转储。
   

所以…

…检查中间物体

非常简单。首先我把线分开

rsaSignature.update(di.toASN1Primitive().getEnpred());

在更新的代码中

byte[] enpredDigestInfo = di.toASN1Primitive().getEnpred();rsaSignature.update(enpredDigestInfo);

然后添加控制台输出

System.out.println("    hash: " + bytesToHex(outputDigest));System.out.println("    algo: " + sha256Aid.getAlgorithm());System.out.println("    info: " + bytesToHex(enpredDigestInfo));

最后，我使用不同的BouncyCastle版本执行了代码。

…产生ASN.1转储

彼得·古特曼（Peter
Gutmann）有一个著名的实用程序dumpasn1，它已成为许多用于创建和显示ASN.1转储的命令行和GUI工具的内核。我目前正巧使用GUIdumpASN-
ng。

在当前情况下，我将的内容保存

byte[]enpredDigestInfo

Files.write