【问题标题】:Cipher.unwrap() key length Sun - BouncyCastle compatibilityCipher.unwrap() 密钥长度 Sun - BouncyCastle 兼容性
【发布时间】:2015-03-25 04:36:07
【问题描述】:

我有一些 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 位字节数组。

问题是:我对@9​​87654324@ 有不同的结果。在 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 位的事实。更新问题。

【问题讨论】:

  • 我目前没有时间,所以我只是硬编码数组转换,但我会回到这个问题并尝试正确解决它。 RSA 填充规范似乎很有希望......

标签: java android encryption


【解决方案1】:

二进制数据(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 填充容易受到某些类型的攻击。

【讨论】:

  • 提供的加密数据是一样的;我添加了一段代码,剪掉了它的包装方式。我错误地检查了skey 的大小,纠正了这个问题。所以它不是包装不同的键,但似乎你对填充参数是正确的。如果我能理解他们的一些事情就好了:)
  • 啊,是的,修改后的答案。请记住:签名和解密的私钥,验证和加密的公钥。
猜你喜欢
  • 1970-01-01
  • 2014-07-19
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-07-16
  • 2012-10-20
  • 1970-01-01
相关资源
最近更新 更多