BAB III
ANALISIS DAN PERANCANGAN
3.1 Analisis Sistem
Analisis sistem pada dasarnya merupakan tahapan yang ditujukan untuk menciptakan pemahaman yang menyeluruh terhadap kebutuhan sistem sehingga diperoleh
gambaran tugas-tugas yang akan dikerjakan sistem. Hal ini akan membantu pemodelan rancang bangun sistem yang nantinya akan diimplementasikan dalam
bentuk nyata.
3.1.1 Analisis Masalah
Untuk mengidentifikasi masalah digunakan diagram Ishikawa fishbone diagram. Diagram Ishikawa adalah sebuah alat grafis yang digunakan untuk mengidentifikasi,
mengeksplorasi dan menggambarkan suatu masalah serta sebab dan akibat dari masalah tersebut [16]. Diagram ini juga sering disebut sebagai diagram sebab-akibat
atau diagram tulang ikan. Identifikasi terhadap permasalahan akan membantu analisis persyaratan sistem yang nantinya akan dikembangkan.
Masalah utama yang mendapat perhatian adalah kenyamanan dan keamanan penggunaan layanan email client. Selanjutnya masalah ini diuraikan ke dalam
beberapa kategori yaitu, kategori pengguna layanan email people, implementasi kriptografi method, ukuran pesan material dan distribusi kunci procedure.
Untuk kategori pengguna layanan email, penyebab masalah yang mungkin muncul adalah pesan yang dikirimkan oleh pengguna mungkin bersifat rahasia,
akibatnya bila pesan ini dicuri oleh orang yang tidak bertanggung jawab kemungkinan akan merugikan pengguna. Untuk kategori implementasi kriptografi, penyebab
Universitas Sumatera Utara
masalah yang mungkin muncul adalah proses enkripsi pesan melalui operasi bit dapat menghasilkan ciphertext yang dikategorikan sebagai karakter non-printable, akibatnya
bila ditransmisikan melalui media internet mail akan menimbulkan representasi yang salah sehingga hasil proses dekripsi berbeda dengan informasi asli plaintext.Untuk
kategori ukuran pesan, penyebab masalah yang mungkin muncul adalah ukuran pesan telalu besar dan bahkan semakin besar ketika mengalami encoding enkripsi maupun
proses encoding base64, sehingga membebani media transmisi data dan waktu yang diperlukan untuk memproses pesan ini dengan Three Pass Protocol akan semakin
lama. Sedangkan untuk kategori distribusi kunci, penyebab masalah adalah implementasi kriptografi simetri yang membutuhkan media transmisi yang benar-
benar aman untuk mendistribuksikan kunci akibatnya bila kunci dicuri oleh pihak yang tidak bertanggung jawab maka pengguna baik pengirim maupun penerima
pesan akan dirugikan. Seluruh kategori dan sebab akibat yang disebutkan kemudian dimuat dalam sebuah diagram Ishikawa sebagai berikut.
Gambar 3.1 Diagram Ishikawa untuk AnalisisPermasalahan Sistem
Pada diagram Ishikawa diatas masalah utama ditunjukkan oleh segi empat paling kanan kepala ikan, sedangkan kategori ditunjukkan oleh segi empat yang
dihubungkan oleh sebuah garis ke tulang utama garis horizontal yang terhubung ke kepala ikan. Selanjutnya sebab akibat yang muncul ditunjukkan oleh tulang-tulang
kecil yang diwakili oleh garis panah yang mengarah ke tulang-tulang kategori masalah.
Universitas Sumatera Utara
3.1.2 Analisis Persyaratan Requirement Analysis
Analisis persyaratan sebuah sistem dikelompokkan ke dalam dua bagian besar yaitu, analisis persyaratan fungsional dan analisis persyaratan non-fungsional.
3.1.2.1 Analisis Persyaratan Fungsional
Persyaratan fungsional adalah segala sesuatu yang harus dimiliki oleh sistem. Persyaratan fungsional sistem yang akan dirancang antara lain sebagai berikut:
1. Sistem harus menyediakan sumberdaya untuk melakukan enkripsi dan dekripsi
dengan menerapkan Three Pass Protocol. Enkripsi dan dekripsi dilakukan dengan operasi XOR, dimana kunci yang digunakan panjangnya sama dengan ukuran
pesan input. Kunci dibangkitkan dengan algoritma pembangkit bilangan acak LCG.
2. Pada penerapan Three Pass Protocol sistem juga harus menyediakan sumberdaya
untuk menerapkan mekanisme kompresi dan dekompresi dengan algoritma LZW. 3.
Sistem juga harus menyediakan fungsi base64 encoding untuk menghindari perubahan representasi informasi akibat munculnya karakter non-printable pada
chipertext .
3.1.2.2 Analisis Persyaratan Non-Fungsional
Persyaratan non-fungsional adalah persyaratan apa yang harus dilakukan sistem. Seringkali berupa batasan atau sesuatu yang menjadi perhatian stakeholder sebuah
sistem. Beberapa persyaratan non-fungsional yang harus dipenuhi oleh sistem yang dirancang adalah sebagai berikut.
1. Penggunaan add on pada perangkat lunak email client Mozilla Thunderbird tidak
menimbulkan gangguan fungsionalitas aplikasi Mozilla Thunderbird. 2.
Implementasi sistem harus memperhatikan efisiensi operasi yang harus dilakukan oleh sistem, waktu eksekusi proses yang terlibat pada setiap tahap Three Pass
Universitas Sumatera Utara
Protocol serta kemudahan penggunaan sehingga tidak menimbulkan persepsi yang
kurang baik oleh pengguna. 3.
Penggunaan sistem harus menghindari munculnya biaya tambahan. 4.
Untuk menjaga kerahasiaan kunci, pengguna tidak perlu mengetahui kunci yang digunakan pada proses enkripsi dan dekripsi.
3.1.2.3 Pemodelan Persyaratan Sistem dengan Use Case
Pemodelan sistem dilakukan untuk memperoleh gambaran yang lebih jelas tentang objek apa saja yang akan berinteraksi dengan sistem serta hal-hal apa saja yang harus
dilakukan oleh sebuah sistem sehingga sistem dapat berfungsi dengan baik sesuai dengan fungsionalitasnya.
Perancangan fungsionalitas perangkat lunak add on yang nantinya akan dikembangkan dimodelkan dengan diagram use case. Aktor yang nantinya akan
berinteraksi dengan sistem adalah pengguna. Pengguna dikategori sebagai dua entitas yang saling bertukar informasi yaitu, pengirim dan penerima.
Sesuai dengan analisis kebutuhan sistem, beberapa hal yang nantinya harus dilakukan sistem adalah :
1. Menerapkan kompresi data LZW sebelum pesan dienkripsi pada tahap awal
Three Pass Protocol dan dekompresi data LZW setelah didekripsi pada tahap
akhir Three Pass Protocol.
2. Melakukan enkripsi dan dekripsi pesan teks yang terdapat pada emaildengan
menerapkan Three Pass Protocol.
3. Membangkitkan kunci dengan algoritma LCG untuk menghasilkan kunci
sepanjang pesan yang akan dienkripsi.
4. Untuk menjaga agar tidak terjadi kehilangan informasi pada saat ditransmisikan,
terutama untuk karakter-karakter yang non-printable misalnya control character pada ASCII, maka setiap kali akan ditransmisikan pesan terlebih dahulu di-
encode dengan menggunakan algoritma base64 encoding. Kemudian ketika akan
Universitas Sumatera Utara
dienkripsi atau didekripsi pesan terlebih dahulu di-decodemenggunakan
algoritma base64 decoding.
Berdasarkan informasi kebutuhan sistem dan aktor yang berperan, diagram use case
berikut dirancang sebagai pemodelan persyaratan sistem.
Pengguna
Pengirim Penerima
Add On Kemanan Email dengan Kriptografi XOR Three Pass Protocol dan Kompresi Data LZW
Kontrol Proses Three Pass Protocol
Enkripsi
Dekripsi Encode base64
Decode Base64 Kompresi
Dekompresi «uses»
«uses» «uses»
«uses» «uses»
«uses» Key Generate
«extends»
Gambar 3.2 Use CaseDiagram Sistem yang Akan dikembangkan
Pada diagram tersebut tampak bahwa seorang pengguna hanya bekerja dengan mengakses use case kontrol proses Three Pass Protocol. Pengguna tidak perlu
mengetahui secara persis proses apa saja yang terjadi pada setiap tahap. Dengan demikian untuk memutuskan proses apa yang nantinya dilakukan pada setiap tahap
menjadi tanggung jawab sistem. Proses kompresi-dekompresi serta encoding- decoding
tidak diinisialisasi oleh pengguna, melainkan secara otomatis dijalankan oleh sistem ketika proses-proses ini diperlukan. Sedangkan enkripsi dan dekripsi
dipilih oleh pengguna setiap tahap, namun pilihan pengguna ini tetap akan dievaluasi
Universitas Sumatera Utara
oleh sistem, apakah urutan proses yang dipilih oleh pengguna sesuai dengan Three Pass Protocol
. Untuk menjaga agar proses yang dipilih oleh pengguna baik tahap enkripsi maupun dekripsi selalu tepat, sistem memberikan penanda pada pesan yang
telah diproses sehingga dengan penanda ini sistem dapat memutuskan apa yang akan dilakukan selanjutnya.
Berikut ini merupakan dokumentasi naratif untuk use case Kontrol Proses Three Pass Protocol
.
Tabel 3.1 Dokumentasi Naratif Use Case Kontrol Proses Three Pass Protocol.
Nama use case Kontrol Proses Three Pass Protocol
Aktor Pengguna
Deskripsi Use case
yang mendeskripsikan fungsi pengendalian proses yang Three Pass Protocol
. Pengendalian proses dilakukan berdasarkan informasi pada bagian awal pesan yang menunjuk pada urutan
proses yang telah dilakukan sebelumnya. Pre-condition
Pesan yang akan diproses tersedia pada jendela compose message milik Mozilla Thunderbird.
Typical course of event
Aksi aktor Respon sistem
Langkah 1: Pengguna menekan menekan tombol enkripsi atau
tombol dekripsi pada toolbar.
Langkah 5: Pengguna melanjutkan proses berikutnya.
Langkah 2: Sistem merespon dengan mengecek informasi
urutan proses sebelumnya. Langkah 3: Sistem kemudian
melakukan rangkaian proses yang harus dilakukan.
Langkah 4: Sistem memberi konfirmasi keberhasilan proses
telah berhasil dilakukan. Alternate course
Aksi aktor Respon sistem
- -
Post condition Pesan telah diproses sesuai dengan tahapan tertentu pada Three Pass
Protocol .
Universitas Sumatera Utara
Activity diagram untuk use case kontrol proses Three Pass Protocol terlihat
sebagai berikut.
Pengguna menekan tombol enkripsidekripsi
Konfirmasi apa yang seharusnya dilakukan oleh pengguna Sistem mengambil pesan yang tersedia
Sistem mengecek proses yang harus dilakukan
urutan yang diminta user tepat?
Sistem memanggil modul yang diperlukan. Sistem menuliskan pesan hasil pemrosesan
Sistem mengkonfirmasi keberhasilan proses
Gambar 3.3 Activity Diagram Kontrol Proses Three Pass Protocol
Pada dokumentasi naratif use casedan activity diagram terlihat bahwa kontrol proses dilakukan dengan menjaga tahapan Three Pass Protocol berlangsung sesuai
dengan mekanisme yang seharusnya dan kemudian sistem memutuskan apa saja yang harus dilakukan oleh sistem pada setiap tahapan dengan memanggil modul program
yang sesuai untuk memproses pesan.
Tabel berikut merupakan dokumentasi naratif untuk use caseEncode base64.
Universitas Sumatera Utara
Tabel 3.2 Dokumentasi Naratif Use CaseEncodeBase64
Nama use case Encodebase64
Aktor -
Deskripsi Use case
mendeskripsikan fungsi encode deretan bit ke dalam bentuk yang dapat ditransmisikan tanpa karakter non-printable
ASCII. Pre-condition
Pesan telah dienkripsi atau didekripsi dan siap untuk diencode.
Typical course of event
Aksi aktor Respon sistem
- Langkah 1:Sistem membentuk
deretan 6 bit kemudian mengkonversinya ke nilai
desimal, dimana nilai desimal tersebut menunjuk pada indeks
himpunan karakter yang digunakan base64 ancode.
Alternate course Aksi aktor
Respon sistem -
- Post condition
Pesan telah di-encode dan siap untuk dikirimkan.
Pada bab sebelumnya telah dijelaskan bagaimana proses yang belangsung pada encode base64
. Bit-bit input hasil enkripsi akan dibagi-bagi ke dalam kelompok- kelompok yang masing-masing panjangnya enam bit. Setiap enam bit ini kemudian
dikonversi menjadi bilangan desmimal kisaran nilai 0-63. Bilangan desimal hasil konversi ini kemudian menjadi penunjuk karakter substitusi sesuai dengan indeks
himpunan karakter untukencodebase64.
Bila terdapat bit sisa berlaku bila panjang bit input secara keseluruhan tidak habis dibagi enam maka sistem akan menambahkan padding pada deretan bit sisa.
Kemudian sistem memberikan penanda pada output. Pada base64 encoding standar penanda yang digunakan adalah symbol ‘=’ yang menunjukkan padding 2 bit. Pada
sistem yang dirancang penanda yang berbeda, untuk penanda padding sebesar 1, 2, 3, 4 dan 5 bit masing-masing secara berturut-turut digunakan simbol ‘’,’’,’’,’’ dan
Universitas Sumatera Utara
‘’. Pertimbangan penggunaan simbol-simbol ini adalah untuk mengurangi jumlah penggunaan simbol padding ‘=’, sehingga simbol padding selalu hanya terdiri dari
satu buah karakter simbol tunggal.
Activity diagram untuk use caseencode base64 adalah sebagai berikut.
Sistem mengkonversi 6 bit ke bilangan desimal.
Sistem mengecek apakah akhir bit? Sistem mensubstitusi 6 bit yang dikonversi dengan
karakter base64 encoding yang indeksnya sesuai
tidak Sistem memeriksa apakah diperlukan padding
tidak Sistem memberikan padding bit.
Sistem mengkonversi 6 bit hasil penambahan padding ke bilangan desimal
Sistem mensubstitusi 6 bit hasil padding dengan karakter base64 encoding yang sesuai
ya
ya
Gambar 3.4 Activity DiagramEncodeBase64
Tabel berikut adalah dokumentasi naratif untuk use case enkripsi.
Universitas Sumatera Utara
Tabel 3.3 Dokumentasi Naratif Use CaseEnkripsi.
Nama use case Enkripsi
Aktor -
Deskripsi Use case
ini berfungsi untuk melakukan enkripsi XOR. Pre-condition
Pesan telah tersedia dalam bentuk bit dan siap untuk dienkripsi
Typical course of event
Aksi aktor Respon sistem
- Langkah 1: Sistem memanggil
pembangkit kunci. Langkah 2 : Sistem menerapk-
an operasi XOR terhadap setiap bit plain text dan kunci.
Langkah 3 : sistem menyimpan kunci
Alternate course Aksi aktor
Respon sistem -
- Post condition
Diperoleh deretan bit yang merupakan cipher text.
Activity diagram untuk use case enkripsi terlihat sebagai berikut.
Sistem memanggil pembangkit kunci atau mengambil kunci tersimpan Sistem mengecek apakah kunci sesuai?
Sistem menerapkan operasi XOR Bit kunci terhadap bit plaintext
Konfirmasi kunci tidak sesuai ya
tidak
Sistem mengecek apakah semua bit telah diproses.
ya tidak
Gambar 3.5 Activity Diagram Enkripsi
Universitas Sumatera Utara
Pada dokumentasi naratif dan activity diagram diatas terlihat bahwa ciphertext hasil enkripsi seperti telah dijelaskan pada bagian sebelumnya merupakan hasil
operasi XOR bit plaintext dengan kunci enkripsi. Sistem pertama sekali akan memanggil modul pembangkit kunci. Selajutnya diperiksa apakah panjang kunci
sesuai dengan panjang bit plaintext. Bila panjang kunci tidak sesuai maka sistem harus memberikan konfirmasi. Bila kunci sesuai dan operasi XOR berhasil dilakukan maka
sistem akan menyimpan kunci dan memberikan konfirmasi bahwa operasi XOR berhasil dilakukan.
Tabel berikut adalah dokumentasi naratif untuk use case key generate.
Tabel 3.4 Dokumentasi Naratif Use CaseKey Generate
Nama use case
Key Generate Aktor
- Deskripsi
Use case inimendeskripsikan fungsi pembangkitan bilangan acak
semu yang digunakan sebagai kunci enkripsi Pre-condition
-
Typical course of event
Aksi aktor Respon sistem
- Langkah 1 : sistem mengatur
nilai multiplier, additive
modulus dan modulus input
algoritma LCG. Langkah 2 : sistem meng-
hitung nilai kunci ke-i hingga panjang bit kunci sesuai.
Alternate course Aksi aktor
Respon sistem -
- Post condition
Kunci telah tersedia dan siap untuk digunakan.
Use casekey generate merupakan mekanisme pembangkitan kunci enkripsi
dengan algoritma LCG sperti telah disebutkan pada bab sebelumnya. Proses
Universitas Sumatera Utara
perulangan pemangkitan kunci akan dilakukan terus menerus hingga panjang bit kunci sama dengan panjang bit plaintext.
Activity diagram untuk use casekey generate terlihat sebagai berikut.
Sistem mengInisialisasi nilai mulitiplier additive modulus dan modulus
Sistem menghitung nilai xi
Sistem mengkonversi xi ke bentuk bit
Ya Tidak
Sistem memeriksa apakah panjang kunci sesuai
Gambar 3.6 Activity DiagramKey Generate
Inisiasi nilai konstanta multiplier dilakukan bedasarkan informasi detik waktu terjadinya pembangkitan kunci sedangkan untuk nilai awal dan konstanta additive
modulus berdasarkan informasi menit waktu terjadinya pembangkitan kunci.
Pertimbangan penggunaan nilai menit dan detik adalah nilanya yang cenderung berubah setiap saat sehingga kunci yang dihasilkan selalu berubah-ubah setiap saat.
Untuk nilai modulus ditetapkan sebesar 64 agar panjang bit kunci selalu bernilai 6 bit sesuai dengan panjang bit hasil encode base64.
Berikut ini adalah dokumentasi naratif untuk use case dekripsi.
Universitas Sumatera Utara
Tabel 3.5 Dokumentasi Naratif Use CaseDekripsi
Nama use case Dekripsi
Aktor -
Deskripsi Use case
ini akan melakukan dekripsi terhadap ciphertext. Pre-condition
Pesan ciphertext telah di-decode ke dalam bentuk bit.
Typical course of event
Aksi aktor Respon sistem
- Langkah 1: Sistem mengambil
kembali kunci yang tersimpan. Langkah 2 : Sistem memeriksa
kesesuaian kunci. Langkah 3: Sistem melakukan
mendekripsi ciphertext Alternate course
Aksi aktor Respon sistem
- -
Post condition Deretan bit hasil dekripsi dihasilkan.
Activity diagram untuk use case dekripsi terlihat sebagai berikut.
Sistem mengambil kembali kunci yang disimpan pada saat enkripsi
Sistem menerapkan Operasi XOR pada cipher dan kunci Ya
Tidak Sistem mengkonfirmasi bahwa
kunci tidak sesuai
Ya Tidak
Sistem mengecek apakah panjang kunci sesuai
Sistem mengecek apakah semua bit telah diproses
Gambar 3.7 Activity Diagram Dekripsi
Universitas Sumatera Utara
Proses dekripsi pada dasarnya sama dengan proses enkripsi, hanya saja pada proses dekripsi kunci tidak dibangkitkan melainkan di-retrieve setelah sebelumnya
disimpan pada proses enkripsi. Proses pencocokan panjang kunci dan operasi XOR yang dilakukan persis sama seperti proses enkripsi.
Tabel berikut adalah dokumentasi naratif untuk use case kompresi.
Tabel 3.6 Dokumentasi Naratif Use CaseKompresi
Nama use case Kompresi
Aktor -
Deskripsi Use case
ini mendeskripsikan fungsi kompresi data teks dengan algoritma Lempel Ziv Welch LZW.
Pre-condition Pesan telah tersedia dalam compose message window Mozilla
Thunderbird.
Typical course of event
Aksi aktor Respon sistem
- Langkah 1: Sistem menginisia-
lisasi dictionary. Langkah 2 : Sistem melakukan
perulangan proses identifikasi karakter pada kamus hingga
dihasilkan indeks yang sesuai. Langkah 3: Sistem menghasil-
kan deretan indeks karakter sebagai hasil kompresi.
Langkah 4 : sistem melakukan proses berulang terus-menerus
hingga seluruh input selesai diproses.
Alternate course Aksi aktor
Respon sistem -
- Post condition
Deretan desimal indeks karakter pada kamus dihasilkan sebagai hasil kompresi.
Universitas Sumatera Utara
Activity diagram untuk use case kompresi terlihat sebagai berikut.
Sistem memasangkan mengambil karakter pertama Sistem memasangkan karakter
sebelumnya dengan karakter berikutnya Sistem memeriksa apakah pasangan
karakter terdapat dalam dictionary.
Sistem menambahkan pasangan karakter Ke dalam dictionary
Sistem mengambil indeks karakter yang sebelumnya masih ditemukan dalam dictionary sebagai output
Sistem mengambil karakter yang terakhir ditambahkan Untuk diproses pada tahap selanjutnya
Sistem memeriksa apakah sudah mencapai karakter terakhir
Sistem menambahkan indeks untuk deretan karakter yang terakhir diproses
tidak ya
ya tidak
Gambar 3.8 Activity Diagram Kompresi
Untuk proses enkripsi proses yang dilakukan adalah semua proses yang terdapat pada kompresi dengan algoritma LZW. Tahap pertama adalah dengan
inisialisasi kamus dengan 256 karakter standar pada tabel ASCII. Selanjutnya dilakukan pemeriksaan kamus, substitusi indeks dan penambahan entri pada kamus
hingga input selesai dikompresi.
Tabel berikut adalah dokumentasi naratif untuk use case dekompresi.
Universitas Sumatera Utara
Tabel 3.7 Dokumentasi Naratif Use CaseDekompresi
Nama use case Dekompresi
Aktor -
Deskripsi Use case
ini mendeskripsikan fungsi dekompresi data dengan algoritma Lempel Ziv Welch LZW.
Pre-condition Data hasil kompresi dalam bentuk bilangan desimal telah tersedia
dan siap untuk proses dekompresi.
Typical course of event
Aksi aktor Respon sistem
- Langkah 1: Sistem menginisia-
lisasi dictionary dengan 256 karakter ASCII.
Langkah 2 : Sistem melakukan perulangan proses identifikasi
indeks pada kamus hingga dihasilkan deretan karakter
sebaga output dekompresi. Langkah 3: Sistem menghasil-
kan deretan karakter sebagai hasil dekompresi.
Alternate course Aksi aktor
Respon sistem -
- Post condition
Deretan karakter dihasilkan sebagai hasil dekompresi.
Proses dekompresi dilakukan dengan menerapkan langkah-langkah dekompresi pada algoritma LZW. Seperti pada kompresi proses yang dilakukan
adalah inisialiasi dictionary dengan 256 karakter ASCII. Selanjutnya dilakukan pemeriksaan entri pada dictionary, substitusi indeks dengan entri serta proses
penambahan entri baru pada kamus. Proses ini dilakukan berulang-ulang hingga semua input selesai didekompresi.
Universitas Sumatera Utara
Activity diagram untuk use case dekompresi terlihat sebagai berikut.
Inisiasi dictionary dengan 256 karakter ASCII Sistem mengkonversi indek pertama pada
Bentuk terkompresi menjadi karakter dictionary yang indeksnya sesuai
Ya Tidak
Sistem menambahkan karakter yang terakhir Kali ditemukan dalam dictionary dipasangkan dengan
Karakter pertamanya ke dalam output Sistem menambahkan karakter yang sebelumnya
Masih ditemukan dalam dictionary dipasangkan dengan dengan karakter pertama dari output ke dalam dictionary
Ya Tidak
Sistem memeriksa indeks berikutnya
Sistem menambahkan karakter yang Indeksnya sesuai ke dalam output.
Sistem memeriksa apakah input dekompresi Telah selesai diproses
Sistem memeriksa apakah pasangan karakter ditemukan dalam dictionary
Gambar 3.9 Activity Diagram Dekompresi
Tabel berikut adalah dokumentasi naratif untuk use case decode base64.
Universitas Sumatera Utara
Tabel 3.8 Dokumentasi Naratif Use CaseDecode Base64.
Nama use case Decode Base64
. Aktor
- Deskripsi
Use case ini mendeskripsikan fungsi decodebase64
Pre-condition Data dalam bentuk encoded.
Typical course of event
Aksi aktor Respon sistem
- Langkah 1 : Sistem memeriksa indeks
karakter pada himpunan karakter base64. Langkah 2 : indeks dalam bentuk desimal
dirubah ke bentuk biner 6 bit. Alternate course
Aksi aktor Respon sistem
- -
Post condition Data tersedia dalam bentuk bit dan siap untuk dienkripsidekripsi.
Activity diagram untuk use casedecodebase64 terlihat sebagai berikut.
Sistem memperoleh data dalam bentuk encoded Sistem memeriksa simbol padding
Konversi karakter ke dalam bentuk desimal yang menunjukkan indeks pada himpunan karakter
base64 Konversi bilangan desimal ke bentuk biner 6 bit
Sistem memproses karakter terakhir sesuai dengan ada atau tidaknya padding
Tidak Ya
Sistem memeriksa apakah sudah mencapai karakter terakhir
Gambar 3.10 Activity Diagram DecodeBase64
Universitas Sumatera Utara
Decode base64 dilakukan dengan memeriksa keberadaan simbol padding dan
menyesuaikan jumlah bit pada karakter terakhir input. Masing-masing simbol kemudian dikonversi ke bentuk desimal yang merupakan indeks setiap karakter pada
himpunan karakter base64 encoding. Bilangan desimal ini kemudian dikonversi ke bentuk biner masing-masing 6 bit. Deretan bit ini kemudian diproses selanjutnya
apakah akan dienkripsi atau didekripsi.
3.1.3Analisis Proses Sistem
Pada bab sebelumnya telah dijelaskan bahwa pada penerapan Three Pass Protocol digunakan algoritma kriptografi XOR, kompresi LZW dan base64 encoding. Proses
pada tahap pertama yang berlangsung pada penerapan Three Pass Protocol dalam penelitian ini digambarkan sebagai sequence diagram berikut.
cryptography lzwCompression
encoDecoding ioFileAccessing
getBodyText compressplainText
compressed binarizecompressed
binCompressed encryptbinCompressed
xorplain,key encodebinCipher
lcgKeyGeneratelength
getProfileDirectory encodedCipher
savekey,DictionaryBitLength WriteKeyandDictLengthOnTextFile
Perform Compression Step
Gambar 3.11 Sequence Diagram Tahap Pertama Three Pass Protocol
Universitas Sumatera Utara
Pada tahap pertama Three Pass Protocol proses yang berlangsung secara berturut-turut adalah kompresi data dengan LZW, konversi hasil kompresi ke bentuk
biner, enkripsi pesan dengan XOR didalamnya dilakukan pembangkitan kunci dengan LCG, dan encodebase64.
Implementasi proses kompresi dengan algoritma LZW dituliskan sebagai pseudocode
dibawah ini. Selain itu, analisis kompleksitas waktu dengan notasi Big-O dilakukan karena nantinya lamanya waktu eksekusi juga menjadi pertimbangan pada
pengujian sistem.
Tabel 3.9 Pseudocode dan Kompleksitas Algoritma Kompresi LZW
Step Pseudocode
1 : 2 :
3 : 4 :
5 : 6 :
7 : 8 :
9 : 10:
11: 12:
13: 14:
15: 16:
17: 18:
19: 20:
21: 22:
23: 24:
25: dictionary
null
for i = 0 to 255 do
dictionary[i] convertToASCIICharsi
dictionaryBitLength
¬lengthOfconvertToBinarylengthOfdictionary
endfor resultCount
0 lookAhead
null
fori = 0 to lengthOfinputStream do
nextChar inputStreami
lookAheadNext lookAhead + nextChar
dictionaryIndex getIndexOflookAheadNext
ifdictionaryIndex = -1 then
lookAhead lookAheadNext
else
compressed[resultCount] getIndexOflookAhead
resultCount resultCount + 1
addToDictionarylookAheadNext looakahead
nextChar
endif if i = lengthOfinputStream then
compressed getIndexOflookAhead
endif endfor
1 255
1255 1255
1 1
n 1n
1n 1n
1n 1n
1n 1n
1n 1n
1n 1
Kompleksitas Big-O On
Setelah dikompresi dengan algoritma LZW, proses berikutnya dilanjutkan dengan membangkitkan kunci enkripsi dengan algoritma LCG. Setelah dibangkitkan
kunci akan disimpan dalam sebuah berkas teks pada direktori profile Mozilla Thuderbird kemudian dilakukan enkripsi terhadap input biner dengan operasi XOR
menggunakan kunci yang dibangkitkan sebelumnya. Proses pembangkitan kunci dilakukan seperti pada pseudocode berikut.
Universitas Sumatera Utara
Tabel 3.10 Pseudocode dan Kompleksitas Algoritma LCG
Step Pseudocode
1 : 2 :
3 : 4 :
5 : 6 :
7 : 8 :
9 : 10:
11: 12:
13: key
null i
0 inita,b,x0
do{
xi
x0a + b mod 64
x0 Xi
key key + binarizexi
} while lengthOfkey=lengthOfbinaryPlain for i = 0 to lengthOfinputStream
cipher
XORbinaryPlaini,keyi endfor
saveEncryptionKey 1
1 1
n 1n
1n 1n
n 1n
1
Kompleksitas Big-O On
Kemudian proses enkripsi yang dilakukan dituliskan sebagai pseudocode berikut.
Tabel 3.11 Pseudocode dan Kompleksitas Algoritma Enkripsi XOR
Step Pseudocode
1 : 2 :
3 : 4 :
key generateKeylengthOfBinaryPlain
for i = 0 to lengthOfinputStream
cipher
XORbinaryPlaini,keyi endfor
1 n
1n
Kompleksitas Big-O On
Hasil enkripsi kemudian di-encodebase64. Algoritma untuk menerapkan encode base64
dituliskan sebagai pseudocode berikut.
Tabel 3.12 Pseudocode dan Kompleksitas AlgoritmaEncodeBase64
Step Pseudocode
1 : 2 :
3 : 4 :
5 : 6 :
7 : 8 :
9 : 10:
11: 12:
13: 14:
encoded null
counter 0
do {
temp
substringunencoded, counter, counter+6
counter counter + 6
dec convertToDecimaltemp
encoded encoded+ getBase64CharFordec
} whilelengthOfunencoded-counter=6 If lengthOfunencodedBits-counter= 0 then
numberOfPadding
lengthOfunencodedBits-counter
temp
setPaddingtemp,numberOfPadding
dec convertToDecimaltemp
encoded encoded+ getBase64CharFordec
endif
1 1
n 1n
1n 1n
1n 1
1 1
1 1
Kompleksitas Big-O On
Universitas Sumatera Utara
Proses yang berlangsung pada Tahap kedua Three Pass Protocol digambarkan pada sequence diagram berikut.
cryptography encodecoding
ioFileAccessing getBodyText
encryptbinCompressed lcgKeyGeneratelength
xorplain,key encodebinCipher
saveKey getProfileDirectory
writeKeyOnTextFile decodeplainText
decodedPlaintext
encodedCipher
Gambar 3.12 Sequence Diagram Tahap Kedua Three Pass Protocol
Pada tahap kedua Three Pass Protocol setiap karakter pada pesan yang diterima di-decodebase64 hingga didapatkan kembali deretan bit. Algoritma decode
base64 dituliskan sebagai pseudocode berikut.
Tabel 3.13 Pseudocode dan Kompleksitas AlgoritmaDecodeBase64
Step Pseudocode
1 : 2 :
3 : 4 :
5 : 6 :
7 : 8 :
unencodedBit null
lastChar getLastCharencoded
lastPadding checkPaddinglastChar
fori= 0 tolengthOfencoded
temp getIndexForencodedi
unencodedBit unencodedBit+convertToBinarytemp
endfor unencoded
unencoded + lastPadding 1
1 1
n 1n
1n n
1
Kompleksitas Big-O On
Universitas Sumatera Utara
Deretan bit hasil peroses decode base64 kemudian dienkripsi kembali. Seperti pada tahap pertama, sebelum dilakukan enkripsi telebih dahulu dibangkitkan kunci
dengan algoritma LCG. Dengan kunci ini kemudian dilakukan enkripsi persis seperti tahap pertama. Kunci ini kemudian disimpan ke dalam sebuah berkas teks. Hasil
enkripsi kemudian di-encode base64. Algoritma yang digunakan untuk melakukan enkripsi dan dekripsi persis sama dengan algoritma dari tahap pertama.
Proses pada tahap ketiga Three Pass Protocol digambarkan pada sequence diagram
berikut ini.
cryptography encoDecoding
ioFileAccessing getBodyText
decryptbinCipher xorcipher,key
encodebinPlain encodedPlain
saveKey getProfileDirectory
getKeyFromFile decodeplainText
decodedPlaintext
Key
getProfileDirectory getDictionaryBitLength
getDictionaryBitLengthFromFile dictionaryBitLength
Gambar 3.13 Sequence Diagram Tahap Ketiga Three Pass Protocol
Pada tahap ketiga proses pertama diawali dengan proses decodebase64 deretan karakter input. Kemudian proses berikutnya adalah mengambil kembali kunci yang
Universitas Sumatera Utara
disimpan sebelumnya pada tahap pertama. Dengan kunci ini dilakukan dekripsi melalui operasi XOR pada masing-masing bit. Dekripsi mirip seperti proses enkripsi
hanya saja, proses dekripsi tidak melibatkan pembangkitan kunci.
Tabel 3.14 Pseudocode dan Kompleksitas Algoritma Dekripsi XOR
Step Pseudocode
1 : 2 :
3 : 4 :
key getStoredKey
for i = 0 to lengthOfinputStream
cipher
XORbinaryPlaini,keyi endfor
1 n
1n
Kompleksitas Big-O On
Hasil dekripsi ini kemudian di-encodebase64 kembali. Proses encode base64 pada tahap ini juga menggunakan algoritma yang sama dengan tahap sebelumnya.
Pada tahap ketiga informasi mengenai panjang bit kamus yang berguna pada proses dekompresi disisipkan pada bagian awal pesan. Panjang bit kamus ini nantinya
digunakan untuk mendekompresi pesan menjadi bentuk semula.
cryptography encoDecoding
ioFileAccessing getBodyText
decryptbinCipher xorcipher,key
saveKey getProfileDirectory
getKeyFromFile decodeplainText
decodedPlaintext
Key lzwCompression
decCompressedbinaryPlain,dictionaryBitLength compressedDecimalPlain
decompresscompressedPlain plainText
Perform Decompression
Gambar 3.14 Sequence Diagram Tahap Terakhir Three Pass Protocol
Universitas Sumatera Utara
Tahap akhir pada prinsipnya sama dengan tahap ketiga, hanya saja bit-bit hasil decoding base64
dan dekripsi XOR tidak di-encode seperti tahap sebelumnya. Hal ini dilakukan karena data tidak perlu dikirimkan lagi. Yang di perlukan pada tahap akhir
adalah data kembali ke bentuk semula bentuk sebelum dienkripsi oleh pengirim. Untuk itu hasil dekripsi harus di dekompresi untuk mendapatkan bentuk semula.
Algoritma dekompresi dituliskan sebagai pseudo code berikut.
Tabel 3.15 Pseudocode dan Kompleksitas AlgoritmaDekompresi LZW
Step Pseudo code
1 : 2 :
3 : 4 :
5 : 6 :
7 : 8 :
9 : 10:
11: 12:
13: 14:
15: 16:
17: 18:
19: dictionary
null
for i = 0 to 255 do
dictionary[i] convertToASCIICharsi
dictionaryBitLength
¬lengthOfconvertToBinarylengthOfdictionary
endfor prev
getStreamFromDictionaryinputStream0 uncompressed
prev
for i = 1 to lengthOfinputStream
temp getStreamFromDictionaryinputStreami
if temp = ‘’ then
entry temp
else
entry prev + firstCharOfprev
endif uncompressed
entry addTodictionaryprev + firstCharOfentry
prev entry
endfor
1 255
1255 1255
1 1
n 1n
1n 1n
1n 1n
1n 1n
1n
Kompleksitas Big-O On
3.2 Perancangan Sistem
