繁体   English   中英

Java 使用 NodeJS 加密解密<rsa_pkcs1_oaep_padding>填充和<sha256> oepHash</sha256></rsa_pkcs1_oaep_padding>

[英]Java Decrypt with NodeJS Encrypt <RSA_PKCS1_OAEP_PADDING> padding and <sha256> oaepHash

我需要解密来自使用 NodeJS 构建的外部服务的一些信息。 该服务要求在 base64 中提供 pem 格式的 RSA (2048) 公钥,以加密信息。

我正在 Java 中创建密钥对:

    KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA");
    kpg.initialize(2048);
    KeyPair kp = kpg.generateKeyPair();
    PublicKey pubkey = kp.getPublic();
    PrivateKey privkey = kp.getPrivate();

    String pemPublicString = "-----BEGIN PUBLIC KEY-----\n";
    pemPublicString = pemPublicString+Base64.getEncoder().encodeToString(pubkey.getEncoded())+"\n";
    pemPublicString = pemPublicString+"-----END PUBLIC KEY-----\n";
    
    String pemPrivateString = "-----BEGIN RSA PRIVATE KEY-----\n";
    pemPrivateString = pemPrivateString+Base64.getEncoder().encodeToString(privkey.getEncoded())+"\n";
    pemPrivateString = pemPrivateString+"-----END RSA PRIVATE KEY-----\n";
    
    //Send to node js service
    String base64publickey = Base64.getEncoder().encodeToString(pemPublicString.getBytes());

    //Store for decrypting
    String base64privatekey = Base64.getEncoder().encodeToString(pemPrivateString.getBytes());

外部服务按如下方式加密信息并返回字节:

  crypto.publicEncrypt(
  {
    key: publicKey,
    padding: crypto.constants.RSA_PKCS1_OAEP_PADDING,
    oaepHash: "sha256",
  },
    dataToEncrypt
  );

我正在尝试解密 Java 中的信息如下:

    public String decrypt(String payload, String privateKey){
      byte [] ciphertext = payload.getBytes(StandardCharsets.UTF_8);
      Cipher oaepFromInit = Cipher.getInstance("RSA/ECB/OAEPPadding");
      OAEPParameterSpec oaepParams = new OAEPParameterSpec("SHA-256", "MGF1", new 
      MGF1ParameterSpec("SHA-1"), PSource.PSpecified.DEFAULT);
      oaepFromInit.init(Cipher.DECRYPT_MODE, getRSAPrivateKeyFrom(privateKey), oaepParams);
      byte[] pt = oaepFromInit.doFinal(ciphertext);
      return new String(pt, StandardCharsets.UTF_8);
    }

    private PrivateKey getRSAPrivateKeyFrom(String content) {
      byte[] decodedBytes = Base64.getDecoder().decode(content);
      String decodedString = new String(decodedBytes);
      Security.addProvider(new BouncyCastleProvider());
      PEMParser pemParser = new PEMParser(new StringReader(decodedString));
      JcaPEMKeyConverter converter = new JcaPEMKeyConverter().setProvider("BC");
      Object object = pemParser.readObject();
      PrivateKey k = converter.getPrivateKey((PrivateKeyInfo) object);
      return k;
   }

现在我得到一个 BadPadding 异常,知道可能是什么问题吗? 提前致谢。

发布的代码没有显示 NodeJS 代码如何导出密文。 Java 代码的decrypt()中的以下行:

 byte[] ciphertext = payload.getBytes(StandardCharsets.UTF_8);

表示您使用了 Utf-8 编码。 这是破坏密文的常见错误(参见此处)。 代替 Utf-8,应用二进制到文本编码,例如 Base64。

密文的导出将在 NodeJS 中完成:

var chiphertextBase64 = ciphertext.toString('base64');

以及 Java 中的导入:

import java.util.Base64;
...
byte[] ciphertext = Base64.getDecoder().decode(payload);  

在 NodeJS 代码中,OAEP ( RSAES-OAEP ) 被指定为填充。 crypto.publicEncrypt()使用参数oaepHash对 OAEP 和 MGF1 摘要应用相同的摘要。 oaepHash: "sha256"因此为两个摘要指定 SHA256。
相比之下,Java 允许单独(和不同)规范 OAEP 和 MGF1 摘要。 虽然 SHA256 用于decrypt()中的 OAEP 摘要,但 SHA1 用于 MGF1 摘要。 后者与NodeJS代码不一致,需要改为SHA256:

OAEPParameterSpec oaepParams = new OAEPParameterSpec("SHA-256", "MGF1", new MGF1ParameterSpec("SHA-256"), PSource.PSpecified.DEFAULT);

Maarten Bodewes 在第一条评论中已经怀疑这个错误。


在发布的代码中,PEM 编码的pemPublicStringpemPrivateString键分别为 Base64 编码为base64publickeybase64privatekey 这不是必需的,因为 PEM 编码密钥的主体已经是 Base64 编码,并且 header 和页脚由 ASCII 字符组成。 因此,第二次 Base64 编码没有带来任何好处,但缺点是密钥数据被不必要地放大(Base64 开销:33%,请参见此处)。 另一方面,如果服务需要双 Base64 编码的公钥,您必须遵守。

生成密钥时,发布的 Java 代码隐式使用 PKCS#8 格式的私钥。 您可以使用privkey.getFormat()验证这一点,它将 output PKCS#8 PKCS#8 的关联 header 是-----BEGIN PRIVATE KEY-----和 Footer -----END PRIVATE KEY----- 您当前使用的 header 和页脚都属于 PEM 编码的 PKCS#1 私钥,因此与密钥数据不一致。 Maarten Bodewes 在第二条评论中已经解决了这个问题。

顺便说一句,PKCS#8 密钥可以在没有BouncyCastle的情况下使用PKCS8EncodedKeySpec轻松导入。 为此,仅 header,必须删除页脚和换行符,并且 rest 必须进行 Base64 解码(DER 编码),请参见此处

暂无
暂无

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM