升级到 1.45 时 BouncyCastle AES 错误
最近从 BC 1.34 升级到 1.45。我正在使用以下内容解码一些先前编码的数据:
SecretKeySpec skeySpec = new SecretKeySpec(raw, "AES");
Cipher cipher = Cipher.getInstance("AES");
cipher.init(Cipher.DECRYPT_MODE, skeySpec);
byte[] decrypted = cipher.doFinal(encrypted);
当使用 BC 1.45 时,我收到此异常:
javax.crypto.BadPaddingException: pad block corrupted
at org.bouncycastle.jce.provider.JCEBlockCipher.engineDoFinal(JCEBlockCipher.java:715)
at javax.crypto.Cipher.doFinal(Cipher.java:1090)
编辑:有关此问题的更多信息。我使用以下内容从密码短语生成原始密钥:
KeyGenerator kgen = KeyGenerator.getInstance("AES", "BC");
SecureRandom sr = SecureRandom.getInstance("SHA1PRNG", "Crypto");
sr.setSeed(seed);
kgen.init(128, sr);
SecretKey skey = kgen.generateKey();
byte[] raw = skey.getEncoded();
我发现这会导致 BC 1.34 与 1.45 产生两个不同的值。
它也可能与 BouncyCastle 无关(我正在 Android 2.3 上进行测试)
Recently upgraded from BC 1.34 to 1.45. I'm decoding some previously-encoded data with the following:
SecretKeySpec skeySpec = new SecretKeySpec(raw, "AES");
Cipher cipher = Cipher.getInstance("AES");
cipher.init(Cipher.DECRYPT_MODE, skeySpec);
byte[] decrypted = cipher.doFinal(encrypted);
When using BC 1.45 I get this exception:
javax.crypto.BadPaddingException: pad block corrupted
at org.bouncycastle.jce.provider.JCEBlockCipher.engineDoFinal(JCEBlockCipher.java:715)
at javax.crypto.Cipher.doFinal(Cipher.java:1090)
EDIT: More about this issue. I am using the following to generate raw keys from a passphrase:
KeyGenerator kgen = KeyGenerator.getInstance("AES", "BC");
SecureRandom sr = SecureRandom.getInstance("SHA1PRNG", "Crypto");
sr.setSeed(seed);
kgen.init(128, sr);
SecretKey skey = kgen.generateKey();
byte[] raw = skey.getEncoded();
What I have found is that this results in two different values for BC 1.34 vs 1.45.
It might also not be BouncyCastle-related (I am testing on Android 2.3)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我刚刚完成追踪。这是因为在 engineNextBytes() 方法中 SHA1PRNG_SecureRandomImpl.java 第 320 行(在 Gingerbread 源代码中)的错误修复
被更改为
显然这是一个已修复的错误,但这意味着给定相同的种子,SecureRandom 将生成不同的种子姜饼前后的数据。
我有一个“修复”方法。我从 android-7 中窃取了足够的代码,以便能够以与 SecureRandom 相同的方式生成随机字节。我尝试解密我的信息,如果失败,请使用我的 SecureRandom 来解密它。然后我显然可以使用较新的 SecureRandom 重新加密它,尽管我有点想完全放弃 SecureRandom...
I just finished tracking this down. It's because of a bug fix on line 320 (in Gingerbread source) of SHA1PRNG_SecureRandomImpl.java in the engineNextBytes() method where
was changed to
Clearly it was a bug that was fixed, but it means that given the same seed, SecureRandom will generate different data pre- and post-gingerbread.
I have a "fix" for it. I stole enough code from android-7 to be able to generate random bytes in the same way that SecureRandom did. I try to decrypt my information and if it fails, use my jacked up SecureRandom to decrypt it. Then I can obviously reencrypt it using the newer SecureRandom, although I'm kind of thinking of moving away from SecureRandom entirely...
看起来问题是 SecureRandom 无法跨 Froyo-Gingerbread 边界移植。这篇文章描述了类似的问题:
http://groups.google。 com/group/android-security-discuss/browse_thread/thread/6ec015a33784b925
我不确定 SecureRandom 中到底发生了什么变化,但我发现修复它的唯一方法是使用便携式方法生成的密钥重新加密数据。
Looks like the problem is SecureRandom not being portable across the Froyo-Gingerbread boundary. This post describes a similar problem:
http://groups.google.com/group/android-security-discuss/browse_thread/thread/6ec015a33784b925
I am not sure what exactly changed in SecureRandom, but the only way I found to fix it was to reencrypt the data with keys generated using a portable method.
根据发行说明,此修复已包含在版本 1.40 中:
这听起来可能是相关的。
According to the release notes, this fix was included in version 1.40:
This sounds like it may be pertinent.