Kesalahan BouncyCastle AES saat memutakhirkan ke 1,45

Baru-baru ini ditingkatkan dari BC 1.34 menjadi 1.45. Saya mendekode beberapa data yang dikodekan sebelumnya dengan yang berikut:

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

Saat menggunakan BC 1.45 saya mendapatkan pengecualian ini:

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: Lebih lanjut tentang masalah ini. Saya menggunakan yang berikut ini untuk menghasilkan kunci mentah dari frasa sandi:

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

Apa yang saya temukan adalah ini menghasilkan dua nilai berbeda untuk BC 1.34 vs 1.45.

Ini mungkin juga tidak terkait dengan BouncyCastle (Saya menguji pada Android 2.3)


android java bouncycastle cryptography
person sehugg    schedule 10.12.2010    source sumber

Jawaban (3)


arrow_upward
6
arrow_downward

Saya baru saja selesai melacaknya. Itu karena perbaikan bug pada baris 320 (dalam sumber Gingerbread) dari SHA1PRNG_SecureRandomImpl.java dalam metode engineNextBytes() di mana

bits = seedLength << 3 + 64;

diubah menjadi

bits = (seedLength << 3) + 64;

Jelas ini adalah bug yang telah diperbaiki, tetapi itu berarti dengan seed yang sama, SecureRandom akan menghasilkan data yang berbeda sebelum dan sesudah gingerbread.

Saya punya "perbaikan" untuk itu. Saya mencuri cukup banyak kode dari Android-7 untuk dapat menghasilkan byte acak dengan cara yang sama seperti yang dilakukan SecureRandom. Saya mencoba mendekripsi informasi saya dan jika gagal, gunakan SecureRandom saya yang telah didongkrak untuk mendekripsinya. Kemudian saya jelas dapat mengenkripsi ulangnya menggunakan SecureRandom yang lebih baru, meskipun saya berpikir untuk menjauh dari SecureRandom sepenuhnya...

person Ben Demboski    schedule 18.03.2011
comment
Saya mencoba menerapkan hal yang sama... Bagaimana Anda membuat Penyedia? - person William Melani; 01.07.2011
comment
@Ben Demboski bisakah Anda memposting solusinya? itu akan sangat berguna - person pandre; 18.11.2012

arrow_upward
3
arrow_downward

Sepertinya masalahnya adalah SecureRandom tidak dapat dibawa-bawa melintasi batas Froyo-Gingerbread. Posting ini menjelaskan masalah serupa:

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

Saya tidak yakin apa sebenarnya yang berubah di SecureRandom, tetapi satu-satunya cara yang saya temukan untuk memperbaikinya adalah dengan mengenkripsi ulang data dengan kunci yang dihasilkan menggunakan metode portabel.

person sehugg    schedule 10.12.2010
comment
Anda benar. Kontrak untuk SecureRandom tidak menjanjikan bahwa seed yang Anda berikan secara manual akan menjadi satu-satunya seed yang digunakan. Ini akan menggunakan sumber lain, seperti /dev/random di linux/bsd. - person President James K. Polk; 11.12.2010
comment
Untuk pembaca selanjutnya: Dengan kata lain, gunakan metode derivasi kunci yang sudah dikenal, seperti PBKDF2. - person Maarten Bodewes; 14.02.2012

arrow_upward
0
arrow_downward

Menurut catatan rilis, perbaikan ini disertakan dalam versi 1.40:

Validasi PKCS7Padding tidak akan gagal jika panjang pad adalah 0. Ini telah diperbaiki.

Sepertinya ini relevan.

person caf    schedule 10.12.2010