BLOGNYA anak indonesia: Blockwise Chosen Boundary Attack

Blockwise Chosen Boundary Attack – BEAST Attack

06.24

Indra , 0 Comments

Blockwise Chosen Boundary Attack – BEAST Attack

Pada September 2011 lalu dunia sempat dikejutkan dengan BEAST (Browser Exploit Against SSL/TLS) attack yang menyerang SSL/TLS oleh Thai Duong dan Juliano Rizzo. Serangan tersebut didemokan dalam Ekoparty 2011 dan dijelaskan dalam paper berjudul Here Comes the XOR Ninjas. Serangan ini practical dan terbukti efektif mencuri session ID yang disimpan dalam cookie website yang dilindungi dengan SSL/TLS (selanjutnya saya hanya menyebut SSL untuk SSL/TLS). Dalam tulisan ini saya akan membahas apa itu BEAST attack dan bagaimana cara kerjanya.

BEAST Attack

Bagi yang belum pernah mendengar BEAST attack silakan melihat dulu youtube, BEAST vs HTTPS yang mendemokan bagaimana BEAST attack bisa digunakan membajak akun Paypal korban. Dalam video tersebut terlihat bagaimana BEAST berhasil mendekrip paket SSL satu byte per satu byte sampai akhirnya seluruh cookie korban berhasil dicuri. Menakutkan bukan?

Gara-gara BEAST attack ini rame-rame situs pengguna SSL mengubah algoritma enkripsinya dari block cipher menjadi stream cipher (RC4). Lho kenapa kok sampai harus mengganti dari block cipher menjadi stream cipher ? Rupanya BEAST attack ini hanya menyerang SSL yang menggunakan algoritma block cipher (e.g AES/DES/3DES) dalam mode CBC (cipher block chaining). Dengan beralih ke stream cipher maka situs tersebut menjadi kebal dari serangan BEAST.

Mari kita bahas ada apa dengan SSL block cipher dan mode CBC sehingga bisa dieksploitasi sampai sedemikian fatalnya.

Block-Cipher dan SSL Record

Sebelumnya sebagai background saya akan menjelaskan sedikit mengenai enkripsi dengan block-cipher dalam SSL.

SSL pada dasarnya mirip dengan protokol pada transport layer seperti TCP yang memberikan layanan connection oriented communication dan menjamin reliability untuk layer di atasnya, hanya bedanya adalah data yang lewat SSL dalam bentuk terenkripsi.

Kalau dalam TCP ada yang namanya 3-way handshake untuk membentuk koneksi, dalam SSL ada negotiation. Dalam proses negosiasi akan disepakati algoritma (e.g encryption, key exchange,MAC) apa yang dipakai dan juga disepakati kunci simetris yang dipakai untuk mengenkripsi data.

Perlu diketahui SSL menggunakan algoritma simetris (e.g RC4, AES, DES) untuk mengenkripsi data karena lebih murah komputasinya dibanding algoritma asimetris (e.g RSA). Algoritma asimetris hanya dipakai selama proses negosiasi saja untuk mengamankan proses pertukaran kunci simetris, setelah session/channel/connection SSL terbentuk, algoritma asimetris tidak dipakai lagi, semua komunikasi dalam channel SSL menggunakan algoritma enkripsi simetris baik block-cipher maupun stream-cipher.

Dalam channel SSL data dikirim dalam bentuk record SSL yang berukuran maksimal 16 kB. Data yang dikirim adalah data yang ada pada layer di atasnya seperti request/response HTTP dalam HTTPS (HTTP over SSL).

Data yang dikirim melalui channel SSL akan dipecah menjadi satu atau lebih SSL record sebelum dikirimkan ke tujuan dan semua record dienkrip dengan kunci simetris yang sama (satu kunci untuk client ke server, dan satu kunci untuk server ke client).

Sebagai pengingat saja, dalam block cipher dalam mode opeasi CBC, setiap blok plaintext di-XOR dengan blok ciphertext sebelumnya untuk menghasilkan blok ciphertext. Khusus untuk blok pertama, blok plaintext di-XOR dengan IV.

Chained IV

Bagaimanakah cara mengenkripsi SSL record ? Data plaintext yang akan dienkrip dalam SSL record tentu terdiri dari satu atau lebih blok plaintext, P1, P2, P3,…, Pn yang akan dienkrip menjadi ciphertext C1, C2, C3,… ,Cn. Ingat dalam CBC mode, dibutuhkan IV untuk menghasilkan C1, nah yang menjadi pertanyaan adalah dari manakah IV atau C0 ini berasal ?

Dalam RFC 2246 tentang TLS 1.0 dijelaskan begini:

With block ciphers in CBC mode (Cipher Block Chaining) the initialization vector (IV) for the first record is generated with the other keys and secrets when the security parameters are set. The IV for subsequent records is the last ciphertext block from the previous record.

Ternyata IV untuk SSL record pertama ditentukan pada saat handshaking (negosiasi), sedangkan IV untuk record selanjutnya adalah block ciphertext terakhir dari record SSL sebelumnya. Menggunakan block ciphertext terakhir sebagai IV untuk record berikutnya disebut dengan chained IV.

Pada gambar di atas terlihat bahwa blok ciphertext terakhir dari record pertama (c4) menjadi C0 atau IV untuk record kedua. Begitu juga block ciphertext terakhir dari record kedua akan menjadi IV untuk record ketiga. Nanti bila ada record ke-4, block ciphertext terakhir dari record ke-3 akan berperan sebagai IV untuk record SSL ke-4.

Pada gambar di atas c0 digambarkan sebagai kotak bergaris putus-putus karena memang C0/IV bukan bagian dari record SSL. Dalam record SSL, block pertama ciphertext adalah C1 bukan C0 atau IV dengan kata lain pendekatan yang dipakai adalah implicit IV.

Pendekatan chained IV ini memandang semua blok ciphertext dari semua record SSL seolah-olah sebagai aliran blok ciphertext yang berurutan, C1, C2, C3….Cn. Pada gambar di atas terlihat record pertama adalah c1 || c2 || c3 || c4, dan 4 blok ciphertext pada record ke-2 bisa dianggap kelanjutan dari record sebelumnya, c5 || c6 || c7 || c8. Tiga blok ciphertext pada record ke-3 juga bisa dianggap sebagai kelanjutan dari blok ciphertext sebelumnya, c9 || c10 || c11.

Chained IV terbukti menjadi masalah keamanan serius karena seorang penyerang sudah tahu duluan IV untuk mengenkrip data berikutnya. Nanti akan saya jelaskan bagaimana chained IV ini bisa dieksploitasi.

Sebagai catatan: Kelemahan chained IV ini diperbaiki di TLS 1.1 dengan menggunakan explicit IV, setiap record menyertakan IV untuk record tersebut (IV menjadi bagian dari record sebagai c0).

Eksploitasi Chained IV

Sekarang akan saya bahas bagiamana chained IV bisa dieksploitasi. Kita akan asumsikan seorang penyerang sedang sniffing jaringan dan mendapatkan (encrypted) ssl record berisi ciphertext Ca = C1 || C2 || C3 || C4 || C5. Dalam BEAST attack ini penyerang memiliki privilege chosen plaintext, artinya dia bisa menentukan plaintext apa yang akan dienkrip dan mendapatkan hasil enkripsinya (ciphertext).

Penyerang tersebut ingin mengetahui apakah plaintext dari suatu blok ciphertext, misalkan C2 adalah G(uess). Bagaimana caranya?

Penyerang akan membuat plaintext P6 = C1 XOR C5 XOR G kemudian meminta sistem mengenkrip plaintext tersebut. Mari kita lihat bagaimana P6 dienkripsi menjadi C6. Ingat melakukan XOR dengan nilai yang sama dua kali akan meniadakan efeknya, karena ada XOR C5 dua kali, maka dua XOR C5 tersebut bisa dihapus.

C6 = E(P6 XOR C5) = E(C1 XOR C5 XOR G XOR C5) = E(C1 XOR G)
Apa artinya dari persamaan C6 = E(C1 XOR G) di atas? Perhatikan bahwa bila G = P2 (plaintext dari C2) maka yang terjadi adalah C6 = E(C1 XOR P2) = C2.

Okey, jadi jika G = P2, maka C6 = C2, lalu so what? apa istimewanya? Bagi yang belum menyadari potensi bahayanya, perhatikan bahwa hanya dengan melihat apakah C6 = C2, si penyerang bisa memastikan apakah G = P2. Bila si penyerang melihat bahwa C6 = C2 artinya bisa dipastikan bahwa G = P2, atau tebakannya benar.

Kini si penyerang memiliki cara untuk memastikan apakah tebakannya benar atau salah

Sudah mulai terbayang bukan cara mendekrip C2 ? Pertama penyerang akan memilih tebakan G’ dan meminta P6 = C1 XOR C5 XOR G’ untuk dienkrip (chosen plaintext). Kemudian penyerang akan melihat apakah hasil enkripsi P6, C6 = C2 atau tidak ?

Bila dilihat C6 tidak sama dengan C2, maka penyerang akan memilih tebakan baru G”. Ingat karena adanya chained IV, maka C6 tersebut menjadi IV untuk mengenkripsi P7 sehingga pada tebakan kedua, si penyerang memilih P7 = C1 XOR C6 XOR G”.

Penyerang juga akan melihat apakah C7 = C2 ? Bila masih salah, penyerang akan memilih tebakan baru, G”’. Sekali lagi karena adanya chined IV, C7 tersebut menjadi IV untu mengenkripsi P8 sehingga pada tebakan ke-3 si penyerang memilih P8 = C1 XOR C7 XOR G”’.

Bila kali ini penyerang melihat bahwa C8 = C2, maka penyerang yakin bahwa G”’ adalah P2 (plaintext dari C2). Namun bila masih salah, penyerang akan terus membuat tebakan baru sampai didapatkan hasil yang positif.

Dalam contoh di atas, plainteks yang dipilih selalu melibatkan C1 karena kita ingin mendekrip C2 (mencari P2). Secara umum bila yang ingin didekrip adalah Cn (mencari Pn), maka plainteks yang dipilih harus memakai Cn-1.

Chosen Boundary

Bagi yang jeli tentu akan melihat masih ada yang kurang dari cara ini. Ingat bahwa G adalah tebakan dari penyerang yang berukuran satu blok (AES berukuran 16 byte). Bagaimana cara menentukan G ? Mengingat G berukuran satu blok 16 byte sehingga kemungkinan G sangat banyak, tentu tidak mungkin kita memilih G sembarangan.

Lalu, bagaimana cara kita membuat “educated guess” atau “smart guess” untuk memilih G yang paling berpotensi benar ?

Memilih G yang tepat untuk menebak P2 sangat susah bila yang tidak diketahui adalah semuanya (16 byte). Tapi kalau kita yakin bahwa 15 byte pertama P2 adalah huruf ‘x’ sedangkan satu byte terakhir P2 tidak diketahui isinya, maka hanya ada 256 kemungkinan tebakan yang harus dicoba. Salah satu diantara 256 tebakan di bawah ini pasti ada yang benar kalau hanya 1 karakter terakhir yang tidak diketahui isinya.

Ga = xxxxxxxxxxxxxxxa
Gb = xxxxxxxxxxxxxxxb
Gc = xxxxxxxxxxxxxxxc
Gd = xxxxxxxxxxxxxxxd
Ge = xxxxxxxxxxxxxxxe
… dan seterusnya

Bagaimana kalau plaintextnya adalah teks “topsecret” dan penyerang tidak mengetahui satu byte pun isinya?

Dalam BEAST attack, selain privilege chosen plaintext, si penyerang punya satu privilege lagi, yaitu menyisipkan teks (prepend) di awal atau di tengah teks lain sebelum teks tersebut dienkripsi. Jadi bila si penyerang mengirimkan teks “abcd”, maka sistem akan mengenkripsi gabungan “abcd” dan “topsecret”.

Privilege penyisipan teks ini sangat penting dalam kesuksesan BEAST attack karena dengan menyisipkan teks artinya sama saja kita bisa menggeser batas blok plaintext. Bagaimana maksudnya ?

Ingat bahwa agar kita bisa menebak satu blok dengan mudah, kita harus membuat 15 byte pertama blok tersebut menjadi sesuatu yang kita ketahui, kemudian hanya menyisakan satu byte saja yang tidak diketahui.

Apa yang terjadi bila teks “topsecret” disisipkan teks “xxxxxxxxxxxxxxx” di awalnya? Setelah digabung teks gabungannya menjadi “xxxxxxxxxxxxxxxtopsecret”. Lalu so what? Apa gunanya menambahkan teks di awal? Memang sepintas tidak terlihat bedanya, baru akan terlihat gunanya ketika kita melihat teks gabungan tersebut dalam bentuk blok-blok plainteks.

Sudah terlihat bedanya bukan? Setelah ditambahkan 15 huruf ‘x’ di awal, sekarang jumlah blok plainteks menjadi 2 (P1 dan P2), dan blok plainteks pertama adalah ‘xxxxxxxxxxxxxxxt’. Aha! Sekarang kita bisa menebak P1 dengan mudah karena kita yakin bahwa 15 karakter pertama P1 berisi ‘x’ karena kita sendiri yang menambahkan huruf ‘x’ tersebut.

Teknik menyisipkan teks ini bertujuan untuk menggeser batas blok (chosen boundary) sehingga hanya menyisakan satu karakter saja yang tidak diketahui.

Setelah penyerang menebak 256 kali, dijamin dia akan mengetahui bahwa huruf pertama adalah ‘t’. Selanjutnya bagaimana cara menebak karakter ke-2 ?

Menebak karakter ke-2 dilakukan dengan mengulang langkah awal tadi, yaitu menggeser batas dengan menyisipkan teks di awal. Kali ini yang disisipkan adalah 14 huruf ‘x’, bukan lagi 15 huruf ‘x’. Mari kita lihat blok plainteksnya.

Karena karakter yang disisipkan (prepend) hanya 14, maka dalam P1 menyisakan ‘to’. Kita sudah tahu 14 huruf pertama adalah ‘x’ dan huruf pertama adalah ‘t’, jadi dari P1 hanya karakter terakhir yang tidak diketahui isinya. Sekali lagi, kita berada dalam posisi yang kita inginkan, kita hanya perlu menebak 256 kali tebakan untuk mendapatkan huruf ke-2 :

Ga = xxxxxxxxxxxxxxta
Gb = xxxxxxxxxxxxxxtb
Gc = xxxxxxxxxxxxxxtc
…
Go = xxxxxxxxxxxxxxto

Menebak karakter ke-3 juga dilakukan dengan cara yang sama. Kita menggeser boundary dengan menyisipkan 13 karakter ‘x’ di awal sehingga blok plainteks yang terbentuk adalah:

Kali ini P1 adalah 13 huruf ‘x’, diikuti dengan 2 karakter yang sudah diketahui ‘to’ dan satu karakter lagi yang belum diketahui. Karena hanya karakter terakhir yang tidak diketahui, maka hanya diperlukan paling banyak 256 kali tebakan untuk mengetahui isi karakter ke-3:

Ga = xxxxxxxxxxxxxtoa
Gb = xxxxxxxxxxxxxtob
Gc = xxxxxxxxxxxxxtoc
…
Gp = xxxxxxxxxxxxxtop

Dua Fase Serangan

Tadi sudah kita bahas bagaimana cara mendekrip satu blok cipherteks. Secara umum tahapannya bisa dibagi menjadi 2 fase:

Fase menggeser batas
Fase melakukan 256 tebakan

Fase pertama si penyerang memanfaatkan privilege chosen boundarynya untuk menggeser batas. Penyerang akan menyisipkan suatu teks untuk menggeser batas blok plainteks sedemikian hingga hanya menyisakan satu karakter yang tidak diketahui. Gambar di bawah ini menunjukkan proses serangan pada fase pertama. Penyerang mengirimkan 15 karakter ‘x’ kemudian menerima hasil enkripsi 15 karakter ‘x’ dan ‘topsecret’ dalam bentuk C0||C1||C2.

Fase kedua adalah fase untuk menebak karakter terakhir, pada fase ini penyerang memanfaatkan privilege chosen plaintextnya (lempar plaintext, terima ciphertext). Dari fase pertama penyerang sudah mengetahui:

Ciphertext C = C0||C1||C2
P1 = xxxxxxxxxxxxxxx?

Penyerang harus menebak karakter terakhir P1 yang belum diketahui isinya.

Langkah pertama penyerang memilih tebakan Ga = ‘xxxxxxxxxxxxxxxa’ kemudian menentukan plaintext P3 = C0 XOR C2 XOR Ga.

Hanya pengingat saja. Karena adanya chained IV, kita tahu bahwa plaintext yang kita pilih ini akan dienkrip dengan menggunakan C2 sebagai IV. Nanti plaintext tersebut akan di-XOR lagi dengan IV (C2) sebelum dienkrip sehingga menyisakan C0 XOR Ga saja yang akan dienkrip.

C3 = E(P3 XOR C2) = E(Co XOR C2 XOR Ga XOR C2) = E(Co XOR Ga)

Karena P3 sudah kita XOR duluan dengan C2, nanti akan menyisakan C3 = Encrypt(C0 XOR Ga). Dalam P3 juga kita gunakan C0 karena kita akan membandingkan dengan C3 dengan C1 dan C1 = Encrypt(C0 XOR P1).

Plaintext P3 ini adalah plaintext yang dipilih penyerang (chosen plaintext) untuk dienkrip menjadi C3. Kemudian penyerang akan melihat apakah C3 = C1 ? Bila tidak sama, maka penyerang akan melanjutkan dengan tebakan lain.

Karena C3 tidak sama dengan C1 artinya tebakan Ga salah. Penyerang membuat tebakan baru Gb = ‘xxxxxxxxxxxxxxxb’ kemudian menentukan P4 = C0 XOR C3 XOR Gb. Plainteks pilihan penyerang ini akan dienkrip menjadi C4. Penyerang akan melihat apakah C4 = C1 ? Bila tidak sama, penyerang akan melanjutkan dengan tebakan lain.

Penyerang akan terus mencoba sampai pada tebakan ke-20 (dalam contoh kasus ini), penyerang membuat tebakan Gt = ‘xxxxxxxxxxxxxxxt’ dan menentukan P22 = C0 XOR C21 XOR Gt. Setelah P22 dienkrip menjadi C22, penyerang melihat bahwa ternyata C22 = C1, yang artinya penyerang yakin bahwa P1 adalah ‘xxxxxxxxxxxxxxxt’.

Setelah penyerang mengetahui karakter pertama adalah ‘t’ selanjutnya penyerang akan mengulangi lagi dari fase pertama untuk menggeser batas dan fase kedua untuk menebak karakter terakhir sebanyak maksimal 256 kali tebakan.

Chosen Boundary dalam HTTPS

Selama ini yang sudah kita bahas masih dalam tataran model atau teoretis saja. Sebenarnya apakah model tersebut ada di dunia nyata ? Jawabnya ada, BEAST attack adalah serangan yang mengeksploitasi chained IV menggunakan teknik pergeseran batas blok (chosen boundary) untuk mendekrip SSL record.

Berikut adalah contoh cookie-bearing request yang dikirim oleh browser dan sudah dipotong-potong menjadi blok-blok plainteks, P1 || P2 || P3 || P4. Dengan sniffing penyerang berhasil mendapatkan ciphertext C = C1 || C2 || C3 || C4 dan ingin mencuri cookie PHPSESSID korban. Bagaimanakah caranya ?

Penyerang bisa mencuri cookie PHPSESSID dengan cara yang sama dengan yang sudah kita bahas tadi.

Fase pertama kita harus menggeser batas bloknya sehingga hanya byte terakhir saja yang tidak diketahui isinya. Dalam request HTTP di atas sebagian besar isi teks sudah diketahui, “POST”, “HTTP/1.1″ dan “Cookie” adalah teks yang umum ada pada request HTTP, bukan hal yang rahasia. Satu-satunya yang rahasia pada request di atas hanyalah isi dari PHPSESSID “af25c…”, bahkan panjang dari isi PHPSESSID bukan sesuatu yang rahasia.

Penyerang bisa menyisipkan teks tambahan dalam URI path untuk menggeser batas. Dalam contoh request di atas kita ingin menggeser “af25c…” sebanyak 12 karakter ke kanan. Penyerang akan mengirimkan cookie-bearing request dengan URI PATH /xxxxxxxxxxxx sehingga blok plainteks dari request yang terbentuk adalah:

Perhatikan pada request yang telah digeser ini, P3 adalah “kie: PHPSESSID=a”. Dari P3 tersebut hanya karakter terakhir saja yang tidak diketahui, “Cookie” dan “PHPSESSID” adalah teks yang umum pada request HTTP. Sudah terbayang kan caranya? Setelah kita menggeser agar P3 menjadi seperti itu, selanjutnya kita masuk ke fase dua, yaitu menebak karakter terakhir sebanyak maksimal 256 kali.

Dengan mengulangi fase pertama dan fase kedua untuk semua karakter pada cookie, pada akhirnya penyerang akan bisa mencuri cookie. Inilah yang sebenarnya terjadi dalam serangan BEAST attack.

Skenario Serangan

Bagaimana sebenarnya serangan BEAST itu dilakukan untuk mencuri cookie PHPSESSID seperti contoh request di atas? Gambar di bawah menunjukkan skenario serangan BEAST bagaimana seorang penyerang mencuri cookie PHPSESSID bank.com.

Serangan BEAST ini mensyaratkan penyerang berada dalam posisi yang memungkinkan untuk melakukan sniffing (e.g. satu jaringan LAN, berada di proxy/router).

Syarat kedua adalah penyerang berhasil menjalankan script di browser yang sama (di tab berbeda) dengan yang dipakai korban untuk membuka bank.com. Script tersebut berfungsi sebagai agent yang mampu mengirimkan cookie-bearing request dan mengirimkan data (over SSL) ke situs bank.com. Ada banyak cara penyerang bisa mengeksekusi script di browser korban, antara lain dengan merayu korban mengklik situs evil.com yang berisi script agent.

Berikut adalah cara yang dilakukan penyerang untuk mencuri PHPSESSID:

Pada fase pertama script yang jalan di browser korban memaksa browser korban mengirimkan cookie-bearing request ke bank.com dengan URI path mengandung ‘xxxxxxxxxxxxxxxx’ untuk menggeser isi PHPSESSID sebanyak 12 karakter.
Sniffer yang dipasang si penyerang mencatat request POST tersebut dalam bentuk SSL record yang berisi C=C1||C2||C3||C4
Karena karakter pertama PHPSESSID berada pada byte terakhir P3, maka selanjutnya penyerang masuk ke fase dua untuk menebak karakter terakhir P3
Script agent akan memaksa browser mengirimkan data ke situs target sebagai lanjutan dari request POST pada fase pertama (sebagai bagian dari POST body)
Penyerang akan meminta browser mengenkripsi P5 = C2 XOR C4 XOR Ga dan mengirimkannya (over SSL) ke situs target
Sniffer penyerang akan melihat C5 yang lewat di jaringan dan memeriksa apakah C5 = C3 ? Bila sama, maka tebakan penyerang benar
Bila tebakan penyerang salah maka penyerang akan membuat tebakan baru dan kembali ke langkah 5.
Paling banyak dalam 256 kali tebakan si penyerang akan berhasil mendapatkan karakter pertama isi PHPSESSID.
Selanjutnya penyerang kembali ke fase pertama di langkah 1 sampai semua karakter PHPSESSID berhasil dicuri.

Simulasi Serangan

Saya membuat script python kecil untuk mensimulasikan bagaimana proses dekripsi dalam BEAST attack ini terjadi. Berikut ini adalah screen recording ketika script demo simulasi BEAST attack tersebut dijalankan.

Source code dari script di bawah ini bisa didownload di sini: beast2.py

Saya akan jelaskan sedikit cara kerja script tersebut. Cipher yang dipakai adalah AES dengan panjang blok 16 byte, kunci dan isi teks rahasia disimpan dalam variabel key dan secret.

Fungsi challengePhase1(text) ini digunakan untuk mensimulasikan serangan pada fase pertama. Teks yang dikirim ke fungsi akan ditambahkan di awal teks rahasia, “plaintext = text + secret”. Selanjutnya plainteks gabungan ini dienkrip dengan AES mode CBC dan fungsi ini mengembalikan IV+ciphertextnya.

Perhatikan bahwa initialization vector pada variabel iv selalu berubah menjadi blok ciphertext terakhir. Hanya IV pertama yang digenerate secara random.

Fungsi challengePhase2(text) mensimulasikan serangan pada fase kedua (fase tebakan). Teks yang dikirim ke fungsi adalah plainteks yang dipilih (chosen plaintext) untuk dienkrip. Fungsi mengembalikan ciphertext hasil enkripsinya. Pada fungsi ini IV juga selalu diubah menjadi blok ciphertext terakhir.

Setelah kita siapkan dua fungsi untuk fase pertama dan fase kedua, sekarang kita lihat bagaimana penyerang melakukan serangannya (tentu dalam simulasi).

Pertama penyerang akan membuat r yang berisi banyak karakter NULL (0×00) sebagai teks yang akan disisipkan untuk menggeser blok plainteks. Pada awalnya r akan berisi 15 karakter NULL untuk menebak karakter pertama secret. Berikutnya r berisi 14 karakter NULL untuk menebak karakter kedua secret dan seterusnya.

Blok loop di bawah ini adalah blok yang melakukan tebakan mulai dari karakter ASCII 32 sampai karakter ASCII 127 (karena kita tahu plainteks adalah printable ASCII). Guess block G adalah r + satu karakter ASCII antara 32-127 dan chosen plainteks (challengeblock) yang akan dienkrip adalah Ci XOR IV XOR G.

Keluaran dari challengePhase2 akan dibandingkan dengan cipherteks yang dicari, bila sama, maka karakter yang dicari berhasil ditemukan.