这是我的code的AES。

This is my code for AES.

在姜饼我得到加密的数据2.2，然后试图解密在2.3后出现以下错误：

Under Gingerbread I get following error after encrypting the data on 2.2 then trying to decrypt on 2.3:

 Caused by: javax.crypto.BadPaddingException: pad block corrupted
        at org.bouncycastle.jce.provider.JCEBlockCipher.engineDoFinal(JCEBlockCipher.java:715)
        at javax.crypto.Cipher.doFinal(Cipher.java:1090)
        at com.citc.wallet.util.security.SimpleCrypto.decrypt(SimpleCrypto.java:63)
        ... 21 more

我已经发现了一些帖子说的SecureRandom 正在生产在不同的系统不同的结果：

I have found some posts saying that SecureRandom is producing different results under different systems:

BouncyCastle升级到1.45 当AES误差

我如何避免在2.3？这个问题 我能以某种方式迫使2.3使用相同的SecureRandom类？ 我是否需要使用一些便携式的加密方法，如果是的话是什么？

How do I avoid this problem on 2.3? Can I somehow force 2.3 to use the same SecureRandom class? Do I need to use some portable encryption method and if so what?

推荐答案

答案是，你应该不是真的做你正在做什么的。这里是罪魁祸首：

The answer is that you shouldn't really be doing what you are doing at all. Here is the culprit:

sr.setSeed(seed);
kgen.init(128, sr); // 192 and 256 bits may not be available
SecretKey skey = kgen.generateKey();

您永远不应该垫有一些非predictable随机值的关键，因为您将需要重新创建完全相同的键以后。下面是从Android文档中的一些关键行

You should never pad your key with some un-predictable random value because you will need to recreate this same exact key later on. Here are some key lines from the android docs

播种SecureRandom的可能是不安全的

"Seeding SecureRandom may be insecure"

虽然通常的做法是对种子   随机与当前时间，也就是   危险与自认为的SecureRandom   值是predictable给攻击者   ，不适合用于安全使用。

Although it is common practice to seed Random with the current time, that is dangerous with SecureRandom since that value is predictable to an attacker and not appropriate for secure use.

不管怎样，我知道你的论点将是你只是填充的关键和你在做什么不是什么大不了的安全性。

Anyway, I know your argument will be that you are just "padding" the key and the security of what you are doing is not a big deal.

如果你要接受128位为192或256位密钥的实现，则必须实现扩张的关键，192或256位的可重复的方法。您甚至可以添加全部为0的关键，如果你想，但关键真的是，它必须以某种方式，你可以在每个系统上重复进行。

If you are going to accept keys of 128 bits for 192 or 256 bit implementations, then you must implement a repeatable method of expanding the key to 192 or 256 bits. You can even add all 0's to the key if you wanted to, but the key really is that it must be done in some way that you can repeat it on every system.

在任何情况下，你可能还需要考虑，你在做什么，可以在系统比Android等使用。在这些情况下，使用更便携式方法来扩大一个关键应选择

In any case, you may also want to consider that what you are doing may be used on systems other than Android. In those cases, using a more "portable" method to expand a key should be chosen.