Algoritma CCM diajukan oleh Doug Whiting, Russ Housley, dan Niels Ferguson pada tahun 2002. Algoritma CCM bergantung pada pemilihan algoritma blok kunci simetrik yang mendasarinya. Dengan demikian, algoritma CCM merupakan sebuah modus operasi algoritma blok. Algoritma blok yang digunakan mendasari CCM merupakan algoritma yang sudah diakui dengan ukuran blok 128 bit. Sampai dengan sekarang satu-satunya algoritma blok 128 bit yang sudah diakui adalah algoritma AES.
Seperti modus operasi lainnya, sebuah kunci rahasia untuk algoritma blok tersebut harus dibangkitkan sebelumnya di antara pihak-pihak yang akan berhubungan. Kunci dibangkitkan acak secara seragam, atau mendekati acak secara seragam sehingga setiap kemungkinan kunci dibangkitkan secara (hampir) equally likely. Sebagai tambahan, kunci harus dibangun oleh suatu metode manajemen kunci yang terjamin. Kunci harus dijaga kerahasiaannya dan hanya digunakan untuk modus CCM. Pada keadaan minimum, sifat keamanan CCM tergantung pada kerahasiaan kunci.
AES merupakan algoritma kriptografi yang didesain untuk beroperasi pada blok pesan 128 bit dan menggunakan variasi blok kunci dengan panjang 128 bit, 192 bit, atau 256 bit. Variasi ukuran kunci mengakibatkan pemilihan penggunaan kunci sulit untuk diprediksi oleh kriptanalis. Ukuran kunci minimum yang mencapai 128 bit mengakibatkan range minimum bagi ruang kunci sebesar 2128, dibandingkan dengan DES yang menggunakan 56 bit kunci, ruang kunci sebesar 256 mengindikasikan AES lebih tahan terhadap serangan exhaustive key search.
AES didesain untuk melakukan proses penyandian secara rahasia dengan tingkat keamanan tak linear dengan kompleksitas waktu seefisien mungkin melalui penggunaan proses-proses transformasi yang ringan dalam implementasi seperti XOR, pergeseran (shift), dan subtitusi. Akan tetapi, invers (proses kebalikan) dari proses-proses tersebut terkadang memiliki efisiensi yang rendah, akibatnya proses dekripsi AES menjadi lambat dalam implementasi. Hal ini ditunjukkan dalam hasil penelitian Giri (2004).
Meskipun demikian, kekurangan ini dapat dihindari oleh algoritma CCM. CCM hanya memerlukan fungsi enkripsi AES baik dalam proses CCM generation-encryption maupun dalam proses CCM decryption-verification. Dengan hanya menggunakan fungsi enkripsi AES dapat mengarah ke penghematan ukuran program CCM atau ukuran perangkat keras (jika CCM diimplementasikan dalam perangkat keras).
Data yang dilindungi CCM terdiri dari tiga elemen, yaitu: Nonce (N), Payload (P), dan
Associated Data (A). Ketiga elemen data ini dibentuk dengan suatu cara yang unik menggunakan sebuah fungsi pemformatan menjadi rangkaian tak-kosong dari blok data input lengkap. Selain fungsi pemformatan, CCM juga memerlukan suatu fungsi pembangkitan counter.
Nilai nonce sebaiknya tak-berulang dengan pengertian bahwa pada sembarang dua pasangan data yang berbeda yang dilindungi oleh CCM selama umur hidup kunci akan diberikan nonce yang berbeda. Sebagai akibatnya, nonce menentukan suatu invokasi (yaitu suatu operasi sandi blok) dalam CCM. Dengan mengasumsikan bahwa tidak terdapat
associated data, atau kalaupun ada, associated data tersebut bernilai kecil, maka dapat dikatakan bahwa jumlah total invokasi dalam CCM tidak akan melebihi 261.
Dari fungsi pemformatan dapat dilihat bahwa parameter nonce n menentukan parameter q, yaitu panjang oktet dari representasi biner panjang oktet payload, karena q = 15 - n. Parameter q menentukan panjang maksimum dari payload dengan p < 28q, maka P terdiri atas oktet-oktet kurang dari 28q, yaitu kurang dari 28q-4 blok-blok 128-bit. Nilai n menentukan jumlah maksimum nonce
yang berbeda, yaitu 28n. Dengan asumsi bahwa associated data bernilai kecil, maka semakin besar nonce akan mengakibatkan panjang maksimum dari payload yang bisa diproteksi CCM menjadi semakin kecil. Namun semakin kecil nonce, maka akan semakin kecil jumlah maksimum nonce yang berbeda.
CCM pada dasarnya menggabungkan dua algoritma kriptografik. Mekanisme pertama adalah CBC-MAC yang memberikan jaminan otentikasi. Jaminan ini berarti musuh tidak dapat dengan mudah memalsukan valid
ciphertext tanpa adanya akses terhadap kunci rahasia.
Algoritma CBC-MAC membangkitkan sebuah nilai MAC yang merupakan nilai otentikasi dari suatu pesan. Suatu nilai MAC memberikan jaminan otentisitas yang lebih kuat daripada suatu nilai checksum atau error detecting code. Verifikasi dari suatu (non-kriptografik) checksum atau error detecting code dirancang hanya untuk mendeteksi modifikasi data yang bersifat kebetulan (accidental), sementara verifikasi dengan MAC, seperti yang digunakan pada CCM, dirancang untuk mendeteksi modifikasi data yang bersifat kebetulan, maupun bersifat disengaja, serta dilakukan oleh pihak yang tak punya kuasa.
Proses CCM generation-encryption akan mengekspansi panjang payload dengan panjang MAC. MAC yang dibangkitkan dalam CCM dinyatakan dengan T. Panjang bit
T, dinyatakan dengan Tlen, merupakan suatu parameter yang ditetapkan untuk semua proses CCM dengan kunci yang diberikan. Nilai Tlen yang semakin besar memberikan jaminan otentisitas yang semakin besar pula. Namun, dengan semakin besar nilai Tlen
maka semakin besar pula ruang penyimpanan untuk ciphertext.
Meskipun fungsi pemformatan yang digunakan dalam penelitian ini memungkinkan Tlen untuk sembarang bilangan bulat kelipatan 16 antara 32 dan 128, namun nilai Tlen yang kurang dari 64 seharusnya tidak digunakan tanpa analisis yang cermat dari resiko penerimaan data tak-otentik sebagai tak-otentik. Secara khusus nilai
Tlen yang lebih kecil dari 64 sebaiknya tidak digunakan kecuali lingkungan protokol atau aplikasi pengontrolan dengan cukup membatasi jumlah kejadian proses decryption-verification bisa mengembalikan pesan error
INVALID, untuk semua implementasi dengan menggunakan kunci yang diberikan. Suatu batasan pada jumlah kejadian dengan output adalah pesan error INVALID sebelum masa hidup kunci berakhir untuk semua implementasi proses decryption-verification
dengan menggunakan kunci tersebut dinyatakan sebagai MaxErrs.
Dengan cara yang sama, untuk nilai Tlen
yang lebih besar, lingkungan protokol atau aplikasi pengontrolan sebaiknya membatasi jumlah input yang tak-otentik yang mungkin dihadirkan pada proses decryption-verification
sampai pada jumlah sepadan dengan nilai dari data yang dilindungi. Probabilitas tertinggi yang dapat diterima untuk sebuah pesan yang
tak-otentik dapat melewati proses decryption-verification ini dinyatakan sebagai Risk. Berdasarkan kedua hal tersebut maka nilai
Tlen harus memenuhi pertidaksamaan berikut ini:
Tlen≥ log2 (MaxErrs / Risk) (Dworkin 2004).
Sebagai contoh, misalkan sebuah sistem tidak akan menghasilkan pesan INVALID lebih dari 1024 pesan sebelum memberhentikan kunci (yaitu MaxErrs = 210), dan bahwa para pengguna dapat mentolerir sekitar satu dari satu juta kesempatan sistem tersebut dapat menerima pesan tak-otentik (yaitu Risk = 2-20). Dalam hal ini, bisa digunakan nilai Tlen terendah, yaitu 32. Namun, jika MaxErrs = 232 dan Risk = 2-32, maka nilai Tlen sekurang-kurangnya adalah 64.
Untuk kebanyakan aplikasi, Whiting et al.
(2002) merekomendasikan penggunaan Tlen
sekurang-kurangnya adalah 64. Penelitian ini tidak dilakukan dalam suatu aplikasi pengontrolan tertentu sehingga sulit untuk menentukan parameter Risk dan MaxErrs. Oleh karenanya, dalam penelitian ini pun dipilih nilai minimum Tlen yang direkomendasikan yaitu 64 bit sehingga dapat memberikan jaminan otentisitas yang cukup serta ekspansi pesan pun tidak terlalu besar.
Mekanisme kedua dalam CCM adalah modus Counter (CTR) yang memberikan jaminan kerahasiaan. Jaminan ini berarti musuh tidak dapat dengan mudah mengambil sembarang informasi dari ciphertext tanpa adanya akses terhadap kunci rahasia. Tujuan utama seorang musuh dalam hal ini adalah untuk membedakan ciphertext dari “random gibberish”, yaitu bitstring yang dipilih secara acak seragam dari kumpulan semua bitstring
yang mungkin dengan panjang tertentu. Karena nilai nonce selalu berbeda, maka blok pertama dari data terformat dan blok-blok
counter akan selalu baru. Suatu payload yang sama dengan kunci rahasia yang sama pun akan menghasilkan ciphertext yang berbeda jika nonce yang digunakan juga berbeda. Dengan demikian, output ciphertext akan sangat menyerupai “random gibberish” dan pada modus CTR ini tidak terjadi collision
sehingga birthday attack dapat dihindari. Berbeda keadaannya jika nonce yang digunakan bernilai sama, misal N0, untuk beberapa aplikasi CCM dengan menggunakan kunci yang berbeda. Meet-in-the-middle
attack atau precomputation attack dapat terjadi di sini. Misalkan musuh memilih nonce
tertentu N0 dan memilih 264 kunci K yang berbeda secara acak. Diasumsikan musuh mengetahui 16 byte pertama dari pesan, maka musuh dapat dengan mudah menghitung suatu
table entry dari masing-masing nilai kunci, membangkitkan pasangan dalam bentuk (K,S1). Musuh lalu pengawasi pengiriman pesan dan collision untuk S1 diharapkan terjadi setelah memeriksa 264 pesan yang dikirim. Dengan cara ini, kunci yang digunakan dapat diketahui oleh musuh. Langkah yang ditempuh adalah sebanyak 264 dan bukan sebanyak ukuran ruang kunci yaitu 2128. Dua senjata yang bisa digunakan untuk melawan serangan ini adalah dengan menggunakan ukuran kunci yang lebih besar serta dengan menggunakan nilai nonce yang selalu baru.
Modus CTR tidak hanya digunakan untuk mengenkripsi payload tetapi juga mengenkripsi MAC. Dengan mengenkripsi MAC maka collision attack pada proses CBC-MAC juga dapat dihindari dan musuh tidak akan memperoleh informasi apapun mengenai hasil CBC-MAC.
Pada proses CCM decryption-verification, seluruh atau sebagian payload tidak boleh dilepaskan sampai nilai MAC telah berhasil diverifikasi. Hal ini dapat mencegah terjadinya chosen-ciphertext attack yang akan mengambil informasi berharga dari kueri proses decryption-verification yang tak-valid.
Dari segi efisiensi, dapat dengan mudah dihitung bahwa penggunaan CCM untuk mengenkripsi dan mengotentikasi payload
kosong, tanpa associated data, membutuhkan dua invokasi. Untuk setiap blok associated data yang ditambahkan dibutuhkan satu invokasi, sedangkan untuk setiap blok
payload yang ditambahkan dibutuhkan dua invokasi. Kasus terburuk adalah ketika
payload dan associated data masing-masing hanya terdiri dari satu oktet. Pada kasus ini, CCM membutuhkan lima invokasi.
Dari struktur CCM yang menggabungkan modus CBC-MAC dengan modus CTR dapat dilihat bahwa CCM bersifat not fully parallelizable. Pemparalelan tidak dapat dilakukan pada proses CBC-MAC namun mungkin untuk dilakukan pada proses CTR. Hal ini bisa dikatakan sebagai salah satu kekurangan CCM. Meskipun demikian, CCM mempunyai kelebihan dari sisi lain. Para perancang CCM tidak akan memberlakukan
paten terhadap algoritma ini. Seluruh hak kekayaan intelektual terhadap algoritma CCM dilepaskan kepada publik.
Dari beberapa hal yang diuraikan di atas dapat diketahui bahwa jika dipandang sebagai modus operasi algoritma blok, CCM memberikan jaminan keamanan yang lebih baik dari modus operasi ECB seperti yang diterapkan pada penelitian Giri (2004) terhadap algoritma blok AES karena selain jaminan kerahasiaan, CCM juga memberikan jaminan otentikasi pesan. Untuk dua blok
plaintext yang sama dengan kunci yang diberikan, modus ECB akan menghasilkan blok ciphertext yang sama. Dengan alasan ini, ECB tidak baik digunakan untuk mengenkripsi plaintext berukuran panjang ataupun untuk suatu aplikasi yang kuncinya digunakan berulang-ulang untuk mengenkripsi lebih dari satu pesan. Jika hal ini dilakukan maka musuh dapat dengan mudah mematahkannya. Namun dari segi kecepatan, secara teoritis dapat dikatakan bahwa ECB lebih baik dari CCM karena dalam ECB hanya terdapat satu proses enkripsi algoritma blok dan tidak terdapat chaining di dalamnya, sedangkan dalam CCM terjadi dua proses yaitu otentikasi dengan CBC-MAC dan enkripsi dengan CTR, serta di dalam CBC-MAC terdapat proses chaining. Selain itu, struktur ECB yang memungkinkan pemrosesan secara paralel semakin dapat meningkatkan kecepatan algoritma ECB.
Berdasar analisis dapat dikatakan bahwa CCM didesain untuk mendapatkan kerahasiaan dan otentikasi pesan secara simultan menggunakan sebuah kunci rahasia. Kebutuhan akan hanya fungsi forward cipher
dari algoritma blok yang mendasari CCM menjadikan ukuran kode implementasi CCM yang lebih kecil. Meskipun demikian, beberapa timbal balik kinerja pada proses-proses dalam CCM harus dipikirkan terlebih dahulu sebelum mengaplikasikan algoritma ini. Semakin besar nonce, maka akan semakin kecil panjang maksimum dari payload yang bisa diproteksi CCM. Semakin kecil nonce, maka akan semakin kecil jumlah maksimum
nonce yang berbeda. Semakin besar nilai Tlen
akan memberikan jaminan otentisitas yang semakin besar pula. Namun, dengan semakin besar nilai Tlen maka semakin besar pula ruang penyimpanan untuk ciphertext.
Berikut ini adalah evaluasi algoritma CCM berdasarkan keadaan kompleksitas waktu untuk waktu terburuk, dinotasikan dengan O
(big O), yang dilakukan untuk menduga besarnya sumber daya waktu yang dibutuhkan untuk sembarang ukuran input.
a. Analisis Algoritma Proses
Generation-Encryption CCM
Diagram alir proses generation-encryption
CCM dapat dilihat pada Gambar 8. Langkah untuk melakukan proses generation-encryption CCM dengan didasarkan pada algoritma blok AES adalah:
1. Pemformatan input nonce, associated data, dan payload
2. Ekspansi kunci
3. Pembangkitan nilai otentikasi menggunakan algoritma CBC-MAC berdasarkan algoritma blok AES
4. Pembangkitan blok-blok counter
5. Enkripsi nilai otentikasi (hasil pada langkah nomor 3) dan payload
menggunakan algoritma blok AES dengan modus operasi CTR sehingga didapatkan
ciphertext.
Waktu eksekusi pada langkah 1 dan 2 adalah konstan (misal α) karena tidak dipengaruhi ukuran input. Langkah 3 (misal waktu eksekusi = 1) dipengaruhi jumlah blok data terformat, sehingga untuk input berukuran n1 blok diperlukan waktu 1n1. Langkah 4 (misal waktu eksekusi = 2) dipengaruhi jumlah blok payload, sehingga untuk payload berukuran n2 blok diperlukan waktu 2(n2+1). Langkah 5 (misal waktu eksekusi = 3) dipengaruhi jumlah blok
counter hasil langkah 4 sehingga diperlukan waktu sebesar 3(n2+1).
Secara keseluruhan, waktu eksekusi
generation-encryption CCM adalah 1n1 +
2(n2+1) + 3(n2+1) + α, dengan 1, 2, 3 dan α adalah suatu konstanta; n1 adalah jumlah blok data terformat dan n2 adalah jumlah blok
counter. Notasi О untuk kasus terburuk proses
generation-encryption CCM adalah:
GE(CCM) = 1n1 + 2(n2+1) + 3(n2+1) + α Didapatkan kompleksitas GE(CCM) adalah dalam lingkup О(n).
b. Analisis Algoritma Proses
Decryption-Verification CCM
Diagram alir proses decryption-verification CCM dapat dilihat pada Gambar 9. Langkah untuk melakukan proses
decryption-verification CCM dengan didasarkan pada algoritma blok AES adalah:
Gambar 8 Diagram alir proses generation-encryption CCM.
Gambar 9 Diagram alir proses decryption-verification CCM.
1. Pembangkitan blok-blok counter
2. Ekspansi kunci
3. Dekripsi ciphertext menggunakan algoritma blok AES dengan modus operasi CTR sehingga didapatkan payload
4. Pemformatan input nonce, associated data, dan payload
5. Pembangkitan nilai otentikasi menggunakan algoritma CBC-MAC berdasarkan algoritma blok AES untuk kemudian dilakukan verifikasi dengan nilai otentikasi yang terdapat pada
ciphertext sehingga diperoleh payload
terverifikasi.
Langkah 1 (misal waktu eksekusi = 1) dipengaruhi jumlah blok input ciphertext, sehingga untuk input berukuran n1 blok (setelah dikurangkan dengan panjang nilai otentikasi yang terdapat pada ciphertext)
diperlukan waktu 1(n1+1). Waktu eksekusi pada langkah 2 dan 4 adalah konstan (misal β) karena tidak dipengaruhi ukuran input.
Langkah 3 (misal waktu eksekusi = 2) dipengaruhi jumlah blok counter hasil langkah 1 sehingga diperlukan waktu 2(n1+1). Langkah 5 (misal waktu eksekusi = 3) dipengaruhi jumlah blok data terformat, sehingga untuk input berukuran n3 blok diperlukan waktu 3n3.
Secara keseluruhan, waktu eksekusi
decryption-verification CCM adalah 1(n1+1) + 2(n1+1) + 3n3 + β, dengan 1, 2, 3, dan β adalah suatu konstanta; n1 adalah jumlah blok
counter dan n2 adalah jumlah blok data terformat. Notasi О untuk kasus terburuk proses decryption-verification CCM adalah:
DV(CCM) = 1(n1+1) + 2(n1+1) + 3n3 + β Didapatkan kompleksitas DV(CCM) adalah dalam lingkup О(n).
Analisis Uji Implementasi
Antarmuka implementasi diberikan pada Lampiran 1. Contoh rekaman uji implementasi deskripsi tahapan proses
generation-encryption dan decryption-verification diberikan pada Lampiran 2.
Uji implementasi CCM dilakukan dengan lima macam percobaan. Setiap percobaan mengambil 32 ukuran file payload berupa teks sebagai objek kajian dalam selang 0 byte
sampai dengan 1000 byte, dengan n ditetapkan dengan nilai 7 serta t ditetapkan dengan nilai 8. Untuk tiap percobaan diberikan nilai a yang berbeda, secara berturut-turut yaitu a = 0, 8, 16, 24, dan 32. Rekapitulasi setiap hasil pengujian secara lengkap diberikan pada Lampiran 3-12.
Tabel 5 berikut memperlihatkan 32 ukuran
payload yang dikaji pada penelitian ini serta ukuran blok counter yang dibangkitkan untuk setiap ukuran payload. Ukuran terkecil blok
counter yang dibangkitkan adalah 16 byte, yaitu 1 blok counter 128-bit. Ukuran terbesar blok counter adalah 1024 byte, yaitu 64 blok
counter 128-bit. Dengan demikian, jumlah invokasi terbesar pada modus CTR adalah sebanyak 26.
Dari setiap percobaan yang dilakukan didapatkan rekapitulasi uji hasil implementasi proses generation-encryption dan decryption-verification yang tercantum pada Tabel 6-10. Masing-masing tabel memuat rekapitulasi rataan running time generation-encryption
(GE) dan decryption-verification (DV) terhadap ukuran data terformat yang berbeda, yaitu payload dan associated data yang telah dibentuk oleh fungsi pemformatan.
Tabel 5 Ukuran payload dan ukuran blok
counter yang dibangkitkan
Payload (byte) Blok Counter (byte) 0 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 1000 1024 Tabel 6 Rekapitulasi rataan running time
generation-encryption dan decryption-verification dengan a = 0, n = 7, dan t = 8 Data Terformat (byte) Rataan GE (detik) Rataan DV (detik) 16 0.1530 0.1640 48 0.4448 0.4524 80 0.7558 0.7873 112 1.0537 1.0923 144 1.3700 1.3893 176 1.6768 1.6867 208 1.9729 2.0158
Lanjutan Tabel 6 Data Terformat (byte) Rataan GE (detik) Rataan DV (detik) 240 2.2437 2.3128 272 2.5514 2.6058 304 2.8637 2.9056 336 3.1560 3.2532 368 3.4960 3.5248 400 3.8084 3.8179 432 4.0902 4.0704 464 4.3848 4.4694 496 4.6915 4.7481 528 4.9940 5.0215 560 5.2835 5.3330 592 5.5748 5.6638 624 5.8981 5.9440 656 6.2266 6.2405 688 6.5049 6.5608 720 6.7982 6.8346 752 7.1057 7.1093 784 7.4118 7.5480 816 7.7323 7.8020 848 8.0192 8.0347 880 8.3427 8.3558 912 8.5839 8.6721 944 8.9451 8.8814 976 9.2229 9.2166 1024 9.6444 9.6682 Dari Tabel 6 dapat dilihat bahwa dengan a
= 0, ukuran terkecil data terformat adalah 16
byte, yakni 1 blok 128-bit, sedangkan ukuran terbesar data terformat adalah 1024 byte, yakni 64 blok 128-bit. Jumlah invokasi pada CBC-MAC dalam percobaan yang pertama ini adalah 26. Dengan demikian, jumlah total invokasi pada percobaan pertama adalah sebanyak 2 x 26 = 27. Jumlah ini masih jauh lebih kecil dari batas jumlah invokasi 261. Tabel 7 Rekapitulasi rataan running time
generation-encryption dan decryption-verification dengan a = 8, n = 7, dan t = 8 Data Terformat (byte) Rataan GE (detik) Rataan DV (detik) 32 0.2237 0.2250 64 0.5362 0.5174 96 0.8395 0.8455 128 1.1202 1.1722 160 1.4746 1.4910 192 1.7540 1.8048 224 2.0260 2.0562 256 2.3621 2.3799 Lanjutan Tabel 7 Data Terformat (byte) Rataan GE (detik) Rataan DV (detik) 288 2.6616 2.7046 320 2.9515 3.0102 352 3.2626 3.2933 384 3.6008 3.6287 416 3.8703 3.8854 448 4.1820 4.2202 480 4.5212 4.5092 512 4.7732 4.8238 544 5.0709 5.1144 576 5.4487 5.4636 608 5.6966 5.7556 640 5.9291 6.0661 672 6.2465 6.3903 704 6.5932 6.6003 736 6.9783 6.9285 768 7.2356 7.3079 800 7.5244 7.5972 832 7.8768 7.9417 864 8.0953 8.1593 896 8.4724 8.4550 928 8.7315 8.8235 960 9.0656 9.1549 992 9.4285 9.3160 1040 9.8250 9.8731 Tabel 7 menunjukkan bahwa dengan a = 8, ukuran terkecil data terformat adalah 32 byte, yaitu 2 blok 128-bit, sedangkan ukuran terbesar data terformat adalah 1040 byte, yakni 65 blok 128-bit. Jumlah invokasi pada CBC-MAC dalam percobaan kedua ini adalah 64. Dengan demikian, jumlah total invokasi pada percobaan kedua adalah sebanyak 129, atau dengan kata lain bertambah 1 invokasi dibandingkan pada percobaan pertama.
Tabel 8 Rekapitulasi rataan running time
generation-encryption dan decryption-verification dengan a = 16, n = 7, dan t = 8 Data Terformat (byte) Rataan GE (detik) Rataan DV (detik) 48 0.2968 0.3060 80 0.6073 0.5966 112 0.9109 0.9212 144 1.2050 1.2329 176 1.5101 1.5344 208 1.8296 1.8331 240 2.0966 2.1528 272 2.4179 2.4428 304 2.7136 2.7618
Lanjutan Tabel 8 Data Terformat (byte) Rataan GE (detik) Rataan DV (detik) 336 3.0143 3.0283 368 3.3078 3.3730 400 3.6358 3.6222 432 3.9497 3.9393 464 4.2106 4.2576 496 4.5384 4.6134 528 4.8027 4.8374 560 5.1751 5.1542 592 5.4843 5.4841 624 5.7447 5.7250 656 6.0599 6.0949 688 6.3164 6.3130 720 6.6757 6.6866 752 6.9567 6.9662 784 7.3128 7.2841 816 7.5224 7.5819 848 7.8518 7.8838 880 8.1506 8.2336 912 8.5154 8.6321 944 8.8087 8.8426 976 9.1149 9.1055 1008 9.3991 9.3947 1056 9.7745 9.8277 Tabel 9 Rekapitulasi rataan running time
generation-encryption dan decryption-verification dengan a = 24, n = 7, dan t = 8 Data Terformat (byte) Rataan GE (detik) Rataan DV (detik) 48 0.3067 0.2937 80 0.6050 0.6112 112 0.9032 0.936 144 1.2099 1.2457 176 1.4988 1.5502 208 1.7991 1.8614 240 2.1025 2.1415 272 2.4111 2.4538 304 2.743 2.7581 336 2.9909 3.0594 368 3.3047 3.3813 400 3.6326 3.6703 432 3.9328 3.9648 464 4.2205 4.2395 496 4.5306 4.5496 528 4.8211 4.8651 560 5.1219 5.1643 592 5.4241 5.4621 624 5.7501 5.7926 656 6.0302 6.1002 Lanjutan Tabel 9 Data Terformat (byte) Rataan GE (detik) Rataan DV (detik) 688 6.3412 6.3832 720 6.6566 6.6721 720 6.6566 6.6721 752 6.9259 6.9949 784 7.2609 7.2826 816 7.5284 7.5531 848 7.8493 7.9250 880 8.1737 8.2350 912 8.5073 8.4967 944 8.7816 8.8515 976 9.0529 9.1209 1008 9.3533 9.4697 1056 9.8392 9.9103 Dari Tabel 8 dan Tabel 9 dapat ditunjukkan bahwa dengan a = 16 dan a = 24, ukuran terkecil data terformat adalah 48 byte, yaitu 3 blok 128-bit, sedangkan ukuran terbesar data terformat adalah 1056 byte, yakni 66 blok 128-bit. Jumlah invokasi pada CBC-MAC dalam percobaan ketiga dan keempat ini adalah 66. Dengan demikian, jumlah total invokasi pada percobaan ketiga dan keempat adalah sebanyak 130, atau dengan kata lain bertambah 2 invokasi dibandingkan pada percobaan pertama.
Rekapitulasi percobaan kelima ditunjukkan pada Tabel 10. Dengan a = 32, ukuran terkecil data terformat adalah 64 byte, yaitu 4 blok 128-bit, sedangkan ukuran terbesar data terformat adalah 1072 byte, yakni 67 blok 128-bit. Jumlah invokasi pada CBC-MAC dalam percobaan ini adalah 67. Dengan demikian, jumlah total invokasi adalah sebanyak 131, atau dengan kata lain bertambah 3 invokasi dibandingkan pada percobaan pertama.
Tabel 10 Rekapitulasi rataan running time
generation-encryption dan decryption-verification dengan a = 32, n = 7, dan t = 8 Data Terformat (byte) Rataan GE (detik) Rataan DV (detik) 64 0.3828 0.3856 96 0.6706 0.6845 128 0.9739 1.0070 160 1.2893 1.2979 192 1.5734 1.5915 224 1.8908 1.8877 256 2.1794 2.2312
Lanjutan Tabel 10 Data Terformat (byte) Rataan GE (detik) Rataan DV (detik) 288 2.4826 2.5327 320 2.7880 2.8197 352 3.1027 3.1359 384 3.4055 3.4405 416 3.7178 3.7471 448 4.0183 4.0485 480 4.2970 4.3266 512 4.5917 4.6505 544 4.9081 4.9334 576 5.1772 5.2415 608 5.5091 5.5225 640 5.8372 5.8624 672 6.1361 6.1662 704 6.4151 6.4350 736 6.7278 6.7701 768 7.0321 7.0690 800 7.3289 7.3249 832 7.6376 7.6719 864 7.9047 7.9674 896 8.2262 8.2748 928 8.5469 8.5981 960 8.8271 8.8509 992 9.1572 9.2565 1024 9.4762 9.4622 1072 9.9238 9.9819 Berdasar Tabel 6-10, dengan meningkatnya ukuran file payload, running time eksekusi proses uji baik generation-encryption maupun decryption-verification
mengalami peningkatan. Hal ini terjadi karena semakin besar ukuran payload maka ukuran data terformat dan blok counter yang dibangkitkan menjadi semakin besar pula.
Gambar 10 adalah grafik hubungan antara proses generation-encryption dan decryption-verification terhadap ukuran data terformat untuk percobaan pertama, yaitu dengan a = 0. Dari grafik tersebut dapat dikatakan bahwa nilai running time proses generation-encryption dan decryption-verification adalah sama, dalam artian tidak terdapat beda atau selisih nilai running time yang signifikan di antara kedua proses tersebut. Hal ini dikarenakan CCM hanya memerlukan fungsi enkripsi dari AES baik untuk CCM
generation-encryption maupun CCM
decryption-verification, sehingga efisiensi yang rendah pada proses kebalikan AES yang memungkinkan proses dekripsi menjadi lambat dalam implementasi seperti yang sudah diuraikan sebelumnya, dapat dihindari.
Dari keempat percobaan lainnya juga dapat dilihat keadaaan yang tidak berbeda, yaitu nilai running time proses generation-encryption dapat dikatakan sama dengan nilai
running time proses decryption-verification.
Running Time Generation-Encryption dan Decryption-Verification CCM a = 0, n = 7, t = 8 0.00 2.00 4.00 6.00 8.00 10.00 12.00 16 144 272 400 528 656 784 912
Formatted Data (byte)
Rat a an R u n ni n g Ti m e ( d e tik ) Generation-Encryption Decryption-Verification
Gambar 10 Hubungan running time generation-encryption dan
decryption-verification terhadap ukuran data terformat pada percobaan pertama.
Dengan adanya penambahan blok
associated data (pada percobaan kedua sampai dengan kelima) maka ukuran data terformat semakin besar sehingga menambah jumlah invokasi yang terjadi. Penambahan jumlah invokasi ini mengakibatkan running time proses generation-encryption dan
decryption-verification pada percobaan kedua sampai dengan kelima mengalami peningkatan dibandingkan percobaan pertama (dengan a = 0). Gambar 11 memberikan gambaran hubungan antara proses generation-encryption dan decryption-verification
terhadap ukuran associated data pada kelima percobaan yang dilakukan.
Hal lain yang dapat ditunjukkan oleh Tabel 6-10 adalah bahwa meskipun data terformat berukuran sama, dengan nilai a dan
payload yang berbeda, misal data terformat berukuran 96 pada Tabel 7 dan Tabel 10, maka running time-nya juga akan berbeda. Hal ini dikarenakan penambahan associated data hanya berpengaruh terhadap jumlah invokasi pada CBC-MAC, sedangkan penambahan ukuran payload akan berpengaruh terhadap jumlah invokasi pada kedua proses CBC-MAC dan CTR. Untuk ukuran payload yang besar dengan ukuran
associated data yang kecil sehingga diperoleh data terformat dengan ukuran tertentu akan
memerlukan running time yang lebih besar