Недавно обновлен от 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)
EDIT: Подробнее об этой проблеме. Для генерации необработанных ключей из кодовой фразы я использую следующее:
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)
Я только что закончил отслеживать это. Это связано с исправлением ошибки в строке 320 (в источнике Gingerbread) SHA1PRNG_SecureRandomImpl.java в методе engineNextBytes (), где
bits = seedLength << 3 + 64;
Был изменен на
bits = (seedLength << 3) + 64;
Очевидно, что это была ошибка, которая была исправлена, но это означает, что при использовании одного и того же семестра SecureRandom будет генерировать разные данные до и после пряников.
У меня есть «исправление». Я украл достаточно кода от android-7, чтобы иметь возможность генерировать случайные байты так же, как это сделал SecureRandom. Я пытаюсь расшифровать мою информацию, и если она не удалась, используйте мою поддержку SecureRandom для ее расшифровки. Тогда я могу, очевидно, повторно зашифровать его, используя новый SecureRandom, хотя я как бы подумываю о том, чтобы полностью отойти от SecureRandom …
Похоже, что проблема SecureRandom не переносима по границе Froyo-Gingerbread. Эта статья описывает аналогичную проблему:
http://groups.google.com/group/android-security-discuss/browse_thread/thread/6ec015a33784b925
Я не уверен, что именно изменилось в SecureRandom, но единственный способ, которым я решил исправить это, – это перекодировать данные с помощью ключей, сгенерированных с помощью переносного метода.
Согласно примечаниям к выпуску , это исправление было включено в версию 1.40:
Проверка PKCS7Padding не сработает, если длина прокладки равна 0. Это было исправлено.
Похоже, это может быть уместно.