Ошибка BouncyCastle AES при обновлении до 1,45

Недавно обновлен от 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. Это было исправлено.

Похоже, это может быть уместно.

Intereting Posts
Класс мест удален из игровых сервисов android 9.2.0 Язык на основе JVM без языковой среды исполнения OnPress / onRelease в Android Как открыть файл в необработанной папке на Android Как узнать, существует ли Streetview, прежде чем запускать намерение Streetview Как программно изменить ширину и высоту Google Maps v2 (поддержка фрагмента)? Как установить значение по умолчанию Spinner равным null? Android: рисование холста в ImageView Уровень заряда батареи по телефонной трубке Проблемы с добавлением зависимостей на ткани к проекту, разработанному компанией cordova android Ошибка приложения в эмуляторе для запуска из-за тайм-аута Растровые изображения на Android Как исправить – «Эта версия приложения не настроена для выставления счетов на рынке»? Db-shm и db-wal в базах данных sqlite PathPattern для соответствия расширению файла не работает, если существует какой-либо период в другом месте имени файла?