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

Question

// 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);  

UPD：我没有注意，没有注意到这样一个事实：unwrappedskey不是256位，而是2048位。更新的问题。

Answer 1

二进制数据的大小--AES密钥--是在解密过程中确定的。

加密明文数据的大小由Sun提供程序中的PKCS#1 v1.5解填充机制确定（在解密的第一步，即用私钥进行模幂运算后得到）。换句话说，Sun提供程序默认为“rsa/ecb/pkcs1padding”。

然而，在Android提供程序中，并不执行PKCS#1 v1.5的解填充操作，相反，它似乎默认为“rsa/ecb/nopadding”。这就是为什么在结果中看到所有的-1值；这是填充物的一部分。这也意味着使用签名生成的填充机制而不是用于加密的填充机制。这是因为您使用私钥而不是公钥来执行加密。