Ошибка BouncyCastle AES при обновлении до 1.45 - PullRequest
Новая
       45

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

6 голосов
/ 10 декабря 2010

Недавно обновлено с 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)

Ответы [ 3 ]

6 голосов
/ 18 марта 2011

Я только что закончил отслеживать это. Это связано с исправлением ошибки в строке 320 (в источнике Gingerbread) файла SHA1PRNG_SecureRandomImpl.java в методе engineNextBytes (), где 

bits = seedLength << 3 + 64;

было изменено на 

bits = (seedLength << 3) + 64;

Очевидно, что это была исправленная ошибка, но это означает, что при одинаковом начальном уровне SecureRandom будет генерировать разные данные до и после имбирного пряника.

У меня есть "исправление" для этого. Я украл достаточно кода из Android-7, чтобы иметь возможность генерировать случайные байты так же, как это делал SecureRandom. Я пытаюсь расшифровать мою информацию, и если она не удалась, используйте мой защищенный протокол SecureRandom, чтобы расшифровать ее. Тогда я, очевидно, могу перешифровать его, используя более новый SecureRandom, хотя я думаю о том, чтобы полностью отказаться от SecureRandom ...

3 голосов
/ 11 декабря 2010

Похоже, проблема в том, что SecureRandom не переносится через границу Froyo-Gingerbread. Этот пост описывает похожую проблему:

http://groups.google.com/group/android-security-discuss/browse_thread/thread/6ec015a33784b925

Я не уверен, что именно изменилось в SecureRandom, но я нашел единственный способ исправить это - перешифровать данные с помощью ключей, сгенерированных переносимым методом.

0 голосов
/ 10 декабря 2010

Согласно примечаниям к выпуску это исправление было включено в версию 1.40:

Проверка PKCS7Padding не будет завершена, если длина пэда равна 0. Это было исправлено.

Похоже, что это уместно.

...