BouncyCastle Error AES al actualizar a 1.45

Question

Recientemente actualizado de BC 1.34 a 1.45. Estoy decodificar algunos datos codificados previamente con lo siguiente:

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

Al usar BC 1,45 me sale esta excepción:

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: Más sobre este tema. Estoy utilizando el siguiente para generar claves primas a partir de una frase de contraseña:

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

Lo que he encontrado es que esto da lugar a dos valores diferentes para BC 1,34 vs 1,45.

Puede que no también estar relacionada-BouncyCastle (estoy probando en Android 2,3)

Answer 1

Parece que el problema es que SecureRandom no se puede transportar a través del límite de Froyo-Gingerbread. Este post describe un problema similar:

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

No estoy seguro de qué es exactamente lo cambió en SecureRandom, pero la única manera que encontré para solucionarlo era repetición de cifrado de los datos con claves generadas usando un método portátil.

Answer 2

De acuerdo con la release notes, esta revisión se incluyó en la versión 1.40:

validación PKCS7Padding no fallaría si la almohadilla la longitud fue 0. Esto ha sido arreglado.

Parece que puede ser pertinente.

Answer 3

Acabo de rastrear esto. Es a causa de un método de corrección de errores en la línea 320 (en fuente de pan de jengibre) de SHA1PRNG_SecureRandomImpl.java en los engineNextBytes() donde

bits = seedLength << 3 + 64; 

se cambió a

bits = (seedLength << 3) + 64; 

claro que era un error que se fijó , pero significa que, dada la misma semilla, SecureRandom generará diferentes datos antes y después de pan de jengibre.

Tengo una "solución" para ello. Robé suficiente código de android-7 para poder generar bytes aleatorios de la misma manera que lo hizo SecureRandom. Intento descifrar mi información y, si falla, uso mi SecureRandom jacked para descifrarla. Entonces, obviamente, puedo volver a cifrarlo usando el nuevo SecureRandom, aunque estoy pensando en alejarme de SecureRandom por completo ...