Question

我有一些JDK 1.6代码，我正在移植到Android，它的行为方式不同。

// decode public key
pubk = KeyFactory.getInstance("RSA").generatePublic(
    new X509EncodedKeySpec(X)
);
// decode symmetric key
cipher = Cipher.getInstance("RSA");
cipher.init(Cipher.UNWRAP_MODE, pubk);
skey = (SecretKey)cipher.unwrap(key1, "AES", Cipher.SECRET_KEY);

pubk是2048位RSA密钥，但使用不同的表示形式（Sun或OpenSSL）。
key1是2048位字节数组。

问题是：我对skey有不同的结果。在Sun JRE上它是128位AES密钥，在Android上它是2048位阵列，包含以下字节：
[1，-1，-1 ...，-1,0，（这里是实际的密钥字节）]

原始包装按以下方式完成：

        // generate symmetric key
        kgen = KeyGenerator.getInstance("AES");
        kgen.init(128, SecureRandom.getInstance("SHA1PRNG"));
        skey = kgen.generateKey();

        // create Cipher
        cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
        cipher.init(Cipher.ENCRYPT_MODE, skey);

        // decode private key
        privk = KeyFactory.getInstance("RSA").generatePrivate(
            new PKCS8EncodedKeySpec(X)
        );

        // wrap symmetric key
        cipher = Cipher.getInstance("RSA");
        cipher.init(Cipher.WRAP_MODE, privk);
        skey_buffer = cipher.wrap(skey);

在换行期间（在Sun JRE中）skey为128位，结果skey_buffer为2048位

~~我认为这与Sun对128位密钥长度的限制有关。~~ 现在我想它与填充有关。但是，我如何将这些限制应用于BouncyCastle实现，以获得相同的解包键输出？当然我可以硬编码在解码数组的开头删除-1，但也许有一些（填充）参数可以获得原始的128位文本？

更新：我没有注意，错过了解开的事实skey不是256位，而是2048位。更新了问题。

Answer 1

二进制数据的大小 - AES密钥 - 在解密期间确定。

加密明文数据的大小由Sun提供程序中的PKCS＃1 v1.5 unpadding机制确定（使用私钥进行模幂运算后获得，这是解密的第一步）。换句话说，Sun提供程序默认为"RSA/ECB/PKCS1Padding"。

然而，在Android提供程序中，未执行PKCS＃1 v1.5 unpadding，而是默认为"RSA/ECB/NoPadding"。这就是为什么你在结果中看到所有-1值的原因;这是填充的一部分。这也意味着使用用于签名生成的填充机制而不是用于加密的填充机制。这是因为您使用私钥而非公钥来执行加密。

因此，您应该明确指定"RSA/ECB/PKCS1Padding"并使用RSA公钥进行包装（如果每个人都可以解密您的AES密钥，那么它没用！）。尝试使用OAEP加密（在Java中为"RSA/ECB/OAEPWithSHA1AndMGF1Padding"）。 PCKS＃1填充易受某些攻击。

Cipher.unwrap（）密钥长度Sun - BouncyCastle兼容性

1 个答案: