error BouncyCastle AES cuando se actualiza 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);

Cuando se utiliza BC 1,45 consigo 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 en bruto 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 AC 1,34 vs 1,45.

Puede ser que también no sea relacionado con BouncyCastle (estoy probando en Android 2.3)

Answer 1

Parece que el problema es SecureRandom no ser portable a través de la frontera Froyo-pan de jengibre. Este post describe un problema similar:

http://groups.google.com/group/ android-seguridad-discuss / browse_thread / hilo / 6ec015a33784b925

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

Answer 2

Me acaba de terminar el seguimiento de esto. Es a causa de una corrección de errores en la línea 320 (en fuente de pan de jengibre) de SHA1PRNG_SecureRandomImpl.java en los engineNextBytes () método donde

bits = seedLength << 3 + 64;

fue cambiado a

bits = (seedLength << 3) + 64;

Estaba claro que era un error que era fijo, sino que significa que, dada la misma semilla, SecureRandom generará datos diferentes antes y después del pan de jengibre.

Tengo una "solución" para ello. He ganado suficiente código de Android-7 para ser capaz de generar bytes aleatorios de la misma manera que lo hizo SecureRandom. Trato de descifrar la información de mi y si falla, uso mi jacked SecureRandom para descifrarlo. Entonces puedo obviamente reencrypt utilizando la nueva SecureRandom, aunque estoy tipo de pensamiento de alejarse de SecureRandom por completo ...

Answer 3

De acuerdo con la notas de la versión , esta corrección se incluyó en la versión 1.40:

  

PKCS7Padding validación no fallaría si la longitud de la almohadilla era 0. Esto se ha solucionado.

Esto suena como que pueden ser pertinentes.