我有一些要移植到Android的JDK 1.6代码,并且行为方式有所不同。

// 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位文本?

Upd:我没有专心,却错过了skey不是256位而是2048位的事实。更新的问题。

最佳答案

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

加密的纯文本数据的大小由Sun提供程序中的PKCS#1 v1.5取消填充机制确定(在使用私钥进行模幂运算后,您将获得此密码,这是解密的第一步)。换句话说,Sun提供程序默认为"RSA/ECB/PKCS1Padding"

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

因此,您应该明确指定"RSA/ECB/PKCS1Padding"并使用RSA公钥进行包装(如果每个人都可以解密您的AES密钥是没有用的,对吗?)。尝试并使用OAEP加密(在Java中为"RSA/ECB/OAEPWithSHA1AndMGF1Padding")。 PCKS#1填充易受某些类型的攻击。

关于java - Cipher.unwrap() key 长度Sun-BouncyCaSTLe兼容性,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/28155639/

10-10 19:52