Erreur AES BouncyCastle lors de la mise à niveau vers 1.45

Question

Récemment amélioré de BC 1.34 à 1.45. Je décodage des données précédemment codées avec les éléments suivants:

SecretKeySpec skeySpec = new SecretKeySpec(raw, "AES"); 
    Cipher cipher = Cipher.getInstance("AES"); 
    cipher.init(Cipher.DECRYPT_MODE, skeySpec); 
    byte[] decrypted = cipher.doFinal(encrypted); 

Lorsque vous utilisez BC 1,45 Je reçois cette 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: En savoir plus sur cette question. J'utilise les éléments suivants pour générer des clés brutes à partir d'un mot de passe:

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(); 

Ce que j'ai trouvé est que cela se traduit par deux valeurs différentes pour la Colombie-Britannique 1,34 vs 1,45.

Il pourrait également ne pas être lié BouncyCastle (je teste sur Android 2.3)

Answer 1

On dirait que le problème est que SecureRandom n'est pas portable sur la frontière Froyo-Gingerbread. Cet article décrit un problème similaire:

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

Je ne sais pas quoi exactement changé en SecureRandom, mais la seule manière que je trouvais de le réparer était recrypter les données avec les clés générées en utilisant une méthode portable.

Answer 2

Selon le release notes, ce correctif a été inclus dans la version 1.40:

validation de PKCS7Padding ne manquerait pas si pad la longueur était 0. Cela a été corrigé.

Cela semble être pertinent.

Answer 3

Je viens de terminer le suivi. Il est à cause d'une correction de bug sur la ligne 320 (dans la source pain d'épice) de SHA1PRNG_SecureRandomImpl.java dans la méthode engineNextBytes() où

bits = seedLength << 3 + 64; 

a été changé pour

bits = (seedLength << 3) + 64; 

Il est clair qu'il était un bug qui a été corrigé , mais cela signifie que donné la même graine, SecureRandom va générer des données différentes pré- et post-pain d'épice.

J'ai un "correctif" pour cela. J'ai volé assez de code d'android-7 pour pouvoir générer des octets aléatoires de la même manière que SecureRandom. J'essaie de déchiffrer mes informations et si cela échoue, utilisez mon SecureRandom pour le décrypter. Ensuite, je peux évidemment le recréer en utilisant le nouveau SecureRandom, bien que je pense en quelque sorte à quitter complètement SecureRandom ...