it-swarm-id.com

Hitung kunci enkripsi AES yang diberikan plaintext dan ciphertext-nya?

Saya bertugas membuat tabel database di Oracle yang berisi string terenkripsi (mis., Kolomnya adalah RAW). String dienkripsi oleh aplikasi (menggunakan AES, kunci 128-bit) dan disimpan di Oracle, kemudian diambil dari Oracle dan didekripsi (mis., Oracle sendiri tidak pernah melihat string yang tidak terenkripsi).

Saya telah menemukan kolom satu ini yang akan menjadi salah satu dari dua string. Saya khawatir bahwa seseorang akan memperhatikan dan mungkin mencari tahu apa dua nilai itu untuk mencari kunci AES.

Misalnya, jika seseorang melihat kolom tersebut adalah Ciphertext # 1 atau # 2:

  • Ciphertext # 1:

    BF,4F,8B,FE, 60,D8,33,56, 1B,F2,35,72, 49,20,DE,C6.
    
  • Ciphertext # 2:

    BC,E8,54,BD, F4,B3,36,3B, DD,70,76,45, 29,28,50,07.
    

dan tahu Plaintext yang sesuai:

  • Plaintext # 1 ("Detroit"):

    44,00,65,00, 74,00,72,00, 6F,00,69,00, 74,00,00,00.
    
  • Plaintext # 2 ("Chicago"):

    43,00,68,00, 69,00,63,00, 61,00,67,00, 6F,00,00,00.
    

dapatkah dia menyimpulkan bahwa kunci enkripsi adalah "Kerbau"?

42,00,75,00, 66,00,66,00, 61,00,6C,00, 6F,00,00,00.

Saya berpikir bahwa seharusnya hanya ada satu kunci 128-bit yang dapat mengubah Plaintext # 1 menjadi Ciphertext # 1. Apakah ini berarti saya harus pergi ke kunci 192-bit atau 256-bit sebagai gantinya, atau menemukan beberapa solusi lain?

(Sebagai tambahan, berikut adalah dua ciphertext lainnya untuk plaintext yang sama tetapi dengan kunci yang berbeda.)

  • Ciphertext # 1 A ("Detroit"):

    E4,28,29,E3, 6E,C2,64,FA, A1,F4,F4,96, FC,18,4A,C5.
    
  • Ciphertext # 2 A ("Chicago"):

     EA,87,30,F0, AC,44,5D,ED, FD,EB,A8,79, 83,59,53,B7.
    

[Pertanyaan terkait: Saat menggunakan AES dan CBC, dapatkah IV menjadi hash dari plaintext? ]

31

Saya menambahkan jawaban sebagai wiki komunitas karena saya percaya bahwa jawaban yang diterima adalah sangat menyesatkan . Inilah alasan saya:

Pertanyaannya adalah bertanya tentang apakah bisa mendapatkan kunci AES. Sehubungan dengan itu, jawaban yang diterima adalah benar: yang disebut Serangan dikenal-plaintext , dan AES tahan terhadap serangan semacam itu. Jadi penyerang tidak akan dapat memanfaatkan ini untuk mendapatkan kunci dan kabur dengan seluruh database.

Tapi ada serangan lain yang berpotensi berbahaya yang dimainkan di sini: a Ciphertext Indistinguishablity Attack . Dari Wikipedia:

Ciphertext indistinguishability adalah properti dari banyak skema enkripsi. Secara intuitif, jika suatu cryptosystem memiliki sifat tidak dapat dibedakan, maka musuh tidak akan dapat membedakan pasangan ciphertext berdasarkan pesan yang mereka enkripsi.

OP menunjukkan kepada kita bahwa kolom ini memiliki salah satu dari dua nilai yang mungkin, dan karena enkripsi bersifat deterministik (yaitu tidak menggunakan IV acak), dan penyerang dapat melihat baris mana yang memiliki nilai yang sama satu sama lain. Yang harus dilakukan penyerang adalah mencari tahu plaintext untuk kolom tersebut untuk satu baris, dan mereka telah memecahkan enkripsi pada seluruh kolom. Berita buruk jika Anda ingin data itu tetap rahasia - yang saya asumsikan adalah alasan mengapa Anda mengenkripsi data tersebut di tempat pertama.

Mitigasi: Untuk melindungi dari ini, buat enkripsi Anda non-deterministik (atau paling tidak tampak non-deterministik kepada penyerang) sehingga enkripsi berulang yang sama plaintext menghasilkan teks sandi yang berbeda. Misalnya Anda dapat melakukan ini dengan menggunakan AES dalam mode Cipher Block Chaining (CBC) dengan acak Vektor Inisialisasi (IV) . Gunakan generator nomor acak aman untuk menghasilkan IV baru untuk setiap baris dan menyimpan IV dalam tabel. Dengan cara ini, tanpa kunci, penyerang tidak dapat menentukan baris mana yang cocok dengan plaintext.

45
Mike Ounsworth

Untuk cipher blok dengan n - kunci bit, jika, diberi blok plaintext dan ciphertext yang sesuai, kuncinya dapat ditebak dalam waktu kurang dari 2n-1 langkah rata-rata, maka cipher blok itu akan dikatakan "rusak" dan cryptographers akan membuat titik tidak menggunakannya. AES belum rusak (belum). Jadi, jangan khawatir.

Namun, beberapa hal masih dapat dikatakan:

  • Memiliki plaintext dan ciphertext yang sesuai memungkinkan penyerang untuk memverifikasi nilai kunci potensial.
  • The 2n-1 nilai sebenarnya setengah dari ukuran ruang kunci. Idenya adalah bahwa penyerang dapat mencoba semua kunci yang mungkin, sampai satu cocok. Rata-rata, ia harus mencoba setengah kunci sebelum mengenai yang benar. Ini mengasumsikan bahwa ruang kunci memiliki ukuran 2n. Anda masih memiliki kemungkinan untuk mengurangi ruang kunci: mis., Jika Anda memutuskan bahwa kunci Anda adalah nama kota AS, maka jumlah kunci yang mungkin sangat jauh lebih rendah (tidak boleh ada lebih dari 100.000 kota di AS) . Oleh karena itu, Anda mendapatkan keamanan 128-bit yang dijanjikan hanya jika proses pembuatan kunci Anda memang dapat menghasilkan kunci 128-bit.
  • Anda tampaknya mengenkripsi setiap nilai dengan memasukkannya langsung ke inti AES. AES bersifat deterministik, ini berarti bahwa dua sel dengan nilai yang sama akan menghasilkan blok terenkripsi yang sama, dan setiap penyerang mungkin memperhatikan hal itu. Dengan kata lain, Anda membocorkan informasi tentang sel mana yang sama satu sama lain. Tergantung pada situasi Anda, ini mungkin atau mungkin tidak menjadi masalah; Anda harus menyadarinya.
  • Anda tidak mengatakan bagaimana Anda menangani nilai lebih dari 16 byte. Ini bukan masalah sederhana. Secara umum, ini memerlukan chaining mode seperti CBC, dan Inisialisasi Vektor (tergantung pada mode; untuk CBC, nilai acak 16 byte - IV baru untuk masing-masing nilai terenkripsi) (ini juga dapat memperbaiki kebocoran informasi dari titik sebelumnya).
15
Thomas Pornin

Jawabannya: Tidak, kunci AES tidak dapat dipulihkan dalam skenario ini. AES aman terhadap serangan plaintext yang dikenal. Ini berarti bahwa, bahkan jika penyerang mengetahui plaintext dan ciphertext yang sesuai (enkripsi di bawah beberapa kunci AES yang tidak diketahui), maka penyerang tidak dapat memulihkan kunci AES. Secara khusus, penyerang tidak dapat memulihkan kunci AES lebih cepat daripada hanya mencoba kunci yang mungkin satu demi satu - yang merupakan proses yang akan memakan waktu lebih lama dari masa hidup peradaban kita, dengan asumsi bahwa kunci AES dipilih secara acak.

P.S. Saya perhatikan bahwa apa pun yang Anda gunakan untuk enkripsi sepertinya tidak menggunakan infus. Ini adalah risiko keamanan. Saya tidak tahu mode operasi apa yang Anda gunakan, tetapi Anda harus menggunakan mode enkripsi yang dianggap baik (mis., Enkripsi mode CBC, enkripsi mode CTR) dengan IV acak. Fakta bahwa mengenkripsi pesan yang sama beberapa kali selalu memberi Anda ciphertext yang sama setiap kali adalah kebocoran keamanan yang lebih baik untuk dihindari. Anda dapat menghindari kebocoran ini dengan menggunakan mode operasi standar dengan IV yang sesuai. (Anda mungkin juga harus menggunakan kode otentikasi pesan (MAC) untuk mengotentikasi ciphertext dan mencegah modifikasi terhadapnya.)

5
D.W.

Garam enkripsi Anda.

Dengan begitu tidak akan ada patters dalam enkripsi Anda. (Ada manfaat lain juga!)

https://stackoverflow.com/questions/5051007/what-is-the-purpose-of-salt

3
Morons

AES tidak semudah membangun meja Rainbow. Hal pertama yang harus Anda sadari adalah tabel membutuhkan vektor inisialisasi. Selama Anda mengubah ini secara semi-teratur, membangun tabel Rainbow (yang tidak terlalu realistis) akan membutuhkan waktu yang sangat lama. Pesanan besarnya panjang. Karena tabel Rainbow yang khas pada dasarnya adalah 2 dimensi, Anda pada dasarnya membutuhkan kubus set hasil untuk mengetahui IV dan kunci.

Jika Anda membaca posting Thomas Pornin, ia masuk ke detail yang sangat bagus tentang apa artinya ini, dalam hal kekerasan memaksa hasilnya.

Kekhawatiran realistis adalah bahwa seseorang dengan akses ke database akan dapat menyuntikkan string dari bidang lain (mungkin karena Anda tidak menggunakan nilai padding acak di kolom per elemen. Atau seeding.)

Jika Anda menyemai nilai, Anda tidak akan mengalami masalah ini, dan satu-satunya serangan (realistis) pada teks-sandi itu sendiri menjadi jauh lebih sulit.

2
Ori