Erro de bouncycastle aes ao atualizar para 1,45

Question

Recentemente atualizado do BC 1.34 para 1,45. Estou decodificando alguns dados codificados anteriormente com o seguinte:

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

Ao usar o BC 1.45, recebo esta exceção:

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: Mais sobre esta edição. Estou usando o seguinte para gerar teclas cruas de uma senha:

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

O que descobri é que isso resulta em dois valores diferentes para BC 1,34 vs 1,45.

Também pode não estar relacionado ao bouncycastle (estou testando no Android 2.3)

Answer 1

Parece que o problema é o SecureRandom não ser portátil através do limite Froyo-Gingerbread. Esta postagem descreve um problema semelhante:

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

Não sei ao certo o que exatamente mudou no SecureRandom, mas a única maneira de corrigi -lo foi reencrypty os dados com chaves geradas usando um método portátil.

Answer 2

Acabei de terminar de rastrear isso. É por causa de uma correção de bug na linha 320 (na fonte de gengibre) de sha1prng_securerandomimpl.java no método EnginenextBytes () onde

bits = seedLength << 3 + 64;

foi alterado para

bits = (seedLength << 3) + 64;

Claramente, foi um bug corrigido, mas significa que, dada a mesma semente, o SecureRandom gerará diferentes dados pré e pós-gentão.

Eu tenho uma "correção" para isso. Eu roubei código suficiente do Android-7 para poder gerar bytes aleatórios da mesma maneira que o SecureRandom. Eu tento descriptografar minhas informações e, se falhar, use meu SecureRandom para descriptografá -las. Então eu posso obviamente reencrigê -lo usando o mais novo SecureRandom, embora eu esteja meio que pensando em me afastar de SecureRandom inteiramente ...

Answer 3

De acordo com Notas de liberação, essa correção foi incluída na versão 1.40:

A validação do PKCS7Padding não falharia se o comprimento do painel fosse 0. Isso foi corrigido.

Parece que pode ser pertinente.