Setelah dilakukan pengujian sebanyak tiga kali sesuai dengan jumlah digit pada bilangan tersebut dan dihasilkan nilai -1, -1 dan 1. Maka, sesuai ketentuan di atas
dapat ditarik kesimpulan bahwa 101 adalah bilangan prima.
2.6 Mozilla Thunderbird dan Add On pada Mozilla Thunderbird
Mozilla thunderbird merupakan salah satu produk Mozilla Foundation, yang pertama kali dirilis pada tanggal 7 Desember 2004. Perangkat ini merupakan aplikasi mail
client atau MUA - Mail User Agent yang bersifat free, open source dan multi- platform. Perangkat ini dikembangkan dengan menggunakan bahasa pemrograman
C++, XUL, Javascript dan CSS. Tampilan Mozilla Thunderbird dapat dilihat pada gambar 2.4.
Gambar 2.4 Tampilan Mozilla Thunderbird
Seperti perangkat lunak produk Mozilla Foundation lainnya perangkat ini juga dapat ditingkatkan kemampuannya melalui perangkat tambahan extension atau
dikenal juga dengan istilah add on. Add on dapat dirancang dan dikembangkan siapa saja yang memiliki kemampuan menggunakan bahasa pemrograman umum seperti
Universitas Sumatera Utara
javascript dan untuk mengmbangkan user interface dapat digunakan XUL XML- User Interface Languagedan CSS.
Universitas Sumatera Utara
BAB 3
ANALISIS DAN PERANCANGAN SISTEM
3.1 Analisis Sistem
Dalam perancangan sebuah sistem diperlukan analisis untuk menentukan kebutuhan
sistem. Dengan adanya analisis sistem, sistem yang dirancang diharapkan akan lebih baik dan memudahkan dalam pengembangan sistem selanjutnya. Tujuan dari analisis
sistem ini sendiri adalah untuk 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, sebab dan akibat dari masalah
itu. 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 dalam implementasi three pass protocol. Selanjutnya masalah ini diuraikan ke dalam
beberapa kategori yaitu, pengguna e-mail people, implementasi kriptografi method, perangkat pendukung material dan teknik pengimplementasian procedure.
Untuk kategori pengirim pesan, penyebab masalah yang mungkin muncul adalah pesan yang dikirimkan oleh pengguna mungkin bersifat rahasia, akibatnya
Universitas Sumatera Utara
bila pesan ini dicuri oleh orang yang tidak bertanggung jawab kemungkinan akan merugikan pengguna. Untuk kategori implementasi kriptografi, penyebab masalah
yang mungkin muncul adalah pembangkitan bilangan prima dan proses enkripsi dekripsi dengan algoritma Massey-Omura. Untuk kategori perangkat pendukung,
penyebab masalah yang mungkin muncul adalah media untuk pengimplementasian kriptografi serta koneksi internet yang tidak stabil sehingga mempengaruhi waktu
pengiriman pesan. Sedangkan untuk kategori teknik pengimplementasian, penyebab masalah adalah penggunaan add on pada Mozilla Thunderbird untuk proses enkripsi
dan dekripsi teks yang akan dikirim melalui e-mail. Seluruh kategori dan sebab akibat yang disebutkan kemudian dimuat dalam sebuah diagram Ishikawa seperti pada
gambar 3.1.
Gambar 3.1 Diagram Ishikawa untuk Analisis Permasalahan Sistem
3.1.2 Analisis Persyaratan Requirement Analysis Analisis persyaratan sebuah sistem dikelompokkan ke dalam dua bagian besar yaitu :
1 Analisis Persyaratan Fungsional Persyaratan fungsional adalah segala sesuatu yang harus dimiliki oleh sistem.
Persyaratan fungsional sistem yang akan dirancang adalah sistem harus menyediakan sumber daya untuk melakukan enkripsi dan dekripsi dengan
menerapkan Three Pass Protocol. Enkripsi dan dekripsi dilakukan dengan algoritma Massey-Omura. Kunci dibangkitkan dengan pembangkit bilangan
prima Lehmann Prime Generator.
Universitas Sumatera Utara
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. Persyaratan non fungsional meliputi performa,
mudah untuk dipelajari dan digunakan, hemat biaya, dokumentasi, manajemen kualitas, dan kontrol.
a Performa Add on yang dibangun harus dapat mengenkripsi pesan dengan
menggunakan algoritma Massey-Omura dan Lehmann Prime Generator. Dan dapat mendekripsi kembali pesan tersebut.
b Mudah digunakan User friendly Add on yang dibangun harus sederhana agar mudah digunakan oleh
pengguna user. Add on yang dimaksud adalah Add on yang memiliki interface yang menarik dan memiliki cara penggunaan yang mudah
dalam pengoperasiannya. c Hemat biaya
Add on yang dibangun tidak memerlukan perangkat tambahan ataupun perangkat pendukung lainnya yang dapat mengeluarkan biaya.
d Kontrol Add On yang dibangun memiliki kontrol untuk bisa digunakan dalam
setiap versi Mozilla Thunderbird
.
3.1.3 Pemodelan Sistem 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 sesuai 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.
Universitas Sumatera Utara
Sesuai dengan analisis kebutuhan sistem, beberapa hal yang nantinya harus dilakukan sistem adalah :
1. Melakukan enkripsi dan dekripsi pesan teks yang terdapat pada e-mail dengan
algoritma Massey-Omura
2. Melakukan enkripsi dan dekripsi pesan teks yang terdapat pada e-mail dengan
menerapkan Three Pass Protocol. 3. Membangkitkan bilangan prima dengan algoritma Lehmann Prime Generator.
Berdasarkan informasi kebutuhan sistem dan aktor yang berperan, diagram use case pada gambar 3.2 dirancang sebagai pemodelan persyaratan sistem.
Gambar 3.2 Use Case Diagram Sistem Yang Akan Dikembangkan
Pada diagram tersebut tampak bahwa seorang pengguna melakukan proses enkripsi pada pesan sebelum pesan tersebut dikirim. Pengguna perlu mengetahui
secara persis proses apa saja yang terjadi pada setiap tahap. Dengan demikian harus melakukan tahap-tahap tersebut dengan bantuan arahan dari sistem. Enkripsi dan
dekripsi dipilih oleh pengguna setiap tahap, namun pilihan pengguna ini tetap akan dievaluasi oleh sistem, apakah urutan proses yang dipilih oleh pengguna sesuai
dengan Three Pass Protocol. Untuk proses Send terjadi setiap selesai proses enkripsi dan dekripsi, kecuali Dekripsi II. Hal ini dikarenakan pada tahapan Three Pass
Protocol setelah pesan didekripsi oleh penerima pesan, pesan itu tidak dikirimkan kembali kepada pengirim karena pesan hasil dekripsi itu merupakan pesan asli.
Spesifikasi untuk use case enkripsi dapat dilihat pada tabel 3.1.
user
Enkripsi
Dekripsi Send
Universitas Sumatera Utara
Tabel 3.1 Spesifikasi Use Case Enkripsi
Name Enkripsi
Actors User
Trigger User telah menginputkan plainteks yang akan dienkripsi
Preconditions Pesan yang akan diproses berada pada body e-mail Mozilla
Thunderbird Post Conditions
User dapat melihat cipherteks hasil proses enkripsi Success Scenario
1. User telah menginputkan plainteks yang akan dienkripsi. 2. User mengakses tombol enkripsi.
3. Sistem mengecek pesan yang terdapat pada body e-mail. 4. Jika tidak terdapat pesan pada body e-mail maka user
menginputkan kembali pesan yang akan dikirim 5. Jika terdapat pesan, maka sistem akan memanggil pembangkit
kunci. 6. Sistem akan melakukan proses enkripsi terhadap plainteks yang
diinputkan dan menampilkan cipherteksnya. 7. User dapat melihat cipherteks hasil proses enkripsi.
Alternative Flows -
Activity diagram untuk use case enkripsi dapat dilihat pada gambar 3.3.
Pengguna Sistem
ketik pesan di body email
akses tombol eknripsi
melakukan enkripsi dengan Algoritma Massey Omura
Menampilkan pesan hasil enkripsi
membangkitkan bilangan prima dengan Lehmann Prime Generator
Cek pesan yang terdapat pada body e- mail
Terdapat pesan pada body e-mail Ya
Tidak
Gambar 3.3 Activity Diagram Enkripsi
Universitas Sumatera Utara
Terdapat dua kali proses enkripsi pada Three Pass Protocol, yang pertama dilakukan oleh pengirim pesan dan yang kedua dilakukan oleh penerima pesan. Proses
yang terjadi pada saat enkipsi yang pertama tidak jauh berbeda dengan proses enkripsi yang kedua. Perbedaannya hanya pada kunci enkripsinya eA dan eB. Dimana eA
merupakan kunci enkripsi pengirim pesan dan eB merupakan kunci enkripsi penerima pesan. Kemudian cipherteks hasil enkripsi pertama akan menjadi plainteks pada
enkripsi kedua setelah pesan dikirim oleh pengirim ke penerima.
Untuk melakukan proses enkripsi baik pengirim maupun penerima cukup mengakses tombol enkripsi. Kemudian sistem akan membangkitkan bilangan prima
dengan Lehmann Prime Generator. Bilangan prima tersebut juga akan menjadi penentu kunci enkripsi. Setelah bilangan prima dibangkitkan, selanjutnya sistem akan
mengenkripsi pesan yang sudah diketikkan di body e-mail dengan algoritma Massey- Omura yang kemudian hasil enkripsinya dapat dilihat di body e-mail dimana pesan
diketikkan sebelumnya.
Spesifikasi untuk use case send dapat dilihat pada tabel 3.2.
Tabel 3.2 Spesifikasi Use Case Send
Name Send
Actors User
Trigger -
Preconditions User telah menginputkan pesan di body e-mail
Post Conditions -
Success Scenario 1. User telah menginputkan pesan yang akan dikirim.
2. User mengakses tombol send. 3. Sistem mengirim pesan ke alamat e-mail yang dituju
Alternative Flows -
Activity diagram untuk use case send dapat dilihat pada gambar 3.4.
Universitas Sumatera Utara
Sistem Pengguna
input pesan yang akan dikirim
akses tombol send
kirim pesan
Gambar 3.4 Activity Diagram Send
Karena media yang digunakan adalah e-mail, proses pengiriman data atau pesan menjadi bagian yang penting. Baik pengirim maupun penerima akan melakukan
proses send untuk mengirim pesan satu sama lain. Dalam proses Three Pass Protocol terdapat 3 kali proses send. Dari pengirim ke penerima, penerima ke pengirim dan
pengirim ke penerima.
Untuk melakukan pengiriman pesan, baik pengirim maupun penerima cukup mengakses tombol send. Kemudian sistem akan mengirimkan pesan yang telah tertulis
di body e-mail ke alamat e-mail yang dituju..
Spesifikasi untuk use case dekripsi dapat dilihat pada tabel 3.3.
Tabel 3.3 Spesifikasi Use Case Dekripsi
Name Dekripsi
Actors User
Trigger User telah menginputkan cipherteks yang akan didekripsi
Preconditions User mengakses tombol dekripsi
Post Conditions User dapat melihat plainteks hasil proses dekripsi
Success Scenario 1. User telah menginputkan cipherteks yang akan didekripsi.
Universitas Sumatera Utara
2. User mengakses tombol dekripsi. 3. Sistem mengecek pesan yang terdapat pada body e-mail.
4. Jika tidak terdapat pesan pada body e-mail maka user menginputkan kembali pesan yang akan dikirim
5. Jika terdapat pesan, maka sistem akan memanggil kembali kunci yang tersimpan.
6. Sistem akan melakukan proses dekripsi terhadap cipherteks yang diinputkan dan menampilkan plainteksnya.
7. User dapat melihat plainteks hasil proses dekripsi. Alternative Flows
-
Activity diagram untuk use case dekripsi dapat dilihat pada gambar 3.5.
Sistem Pengguna
masukkan pesan ke dalam body e- mail
mengakses tombol dekripsi
mendekripsi pesan dengan Algoritma Massey Omura
menampilkan pesan hasil dekripsi
mengambil kembali kunci yang tersimpan
cek pesan yang terdapat pada body e- mail
Terdapat pesan pada body e-mail Ya
Tidak
Gambar 3.5 Activity Diagram Dekripsi
Universitas Sumatera Utara
Sama halnya pada proses enkripsi, terdapat dua kali proses dekripsi pada Three Pass Protocol, yang pertama dilakukan oleh pengirim pesan dan yang kedua
dilakukan oleh penerima pesan. Proses yang terjadi pada saat dekipsi yang pertama tidak jauh berbeda dengan proses dekripsi yang kedua. Perbedaannya hanya pada
kunci dekripsinya dA dan dB. Dimana dA merupakan kunci dekripsi pengirim pesan dan dB merupakan kunci dekripsi penerima pesan.
Untuk melakukan proses dekripsi baik pengirim maupun penerima cukup mengakses tombol dekripsi. Kemudian sistem akan mengambil kembali kunci yang
tersimpan. Kemudian sistem akan mendekripsi pesan yang ada di body e-mail dengan algoritma Massey-Omura yang kemudian hasil dekripsinya dapat dilihat di body e-
mail dimana pesan diketikkan sebelumnya
Sequence diagram untuk proses enkripsi dapat dilihat pada gambar 3.6.
: getBodyText : Enkripsi
: Lehmann : MasseyOmura
Generate bilangan prima input pesan
user klik tombol enkripsi
enkripsi
Sistem menampilkan pesan hasil enkripsi Pengguna
cek
Gambar 3.6 Sequence Diagram Enkripsi
Pada gambar 3.6 dapat dilihat bahwa pengguna mengetikkan pesan ke dalam body e-mail. Setelah itu, user mengakses tombol enkripsi untuk membangkitkan
bilangan prima dengan Lehmann Prime Generator dan kemudian mengenkripsi pesan
Universitas Sumatera Utara
tersebut dengan algoritma Massey-Omura. Pesan hasil enkripsi ciphertext otomatis dituliskan kembali ke dalam body e-mail.
Hasil dari enkripsi pada proses yang pertama diatas akan dikirim. Sequence diagram pengirimannya dapat dilihat pada gambar 3.7.
: Send input pesan
user klik tombol send
lihat pesan : getBodyText
Pengguna
kirim
Gambar 3.7 Sequence Diagram Send
Pesan dikirim setelah user mengakses tombol send. Setelah pesan dikirim, maka pesan akan dienkripsi lagi. Proses enkripsinya sama dengan proses pada enkripsi
sebelumnya. Perbedaaanya adalah pada kunci yang dihasilkan oleh fungsi random. Setelah enkripsi kedua dilakukan, hasilnya dikirim kembali untuk didekripsi.
Sequence diagram proses dekripsi dapat dilihat pada gambar 3.8.
Universitas Sumatera Utara
: dekripsi
dekripsi input pesan
user klik tombol dekripsi ambil kunci
Sistem menampilkan pesan hasil dekripsi : MasseyOmura
: getBodyText Pengguna
Gambar 3.8 Sequence Diagram Dekripsi
Pada gambar 3.8 dapat dilihat bahwa pengguna harus mengakses tombol dekripsi untuk mendekripsi pesan yang terdapat di body e-mail. Setelah pengguna
mengakses tombol dekripsi, maka sistem terlebih dahulu akan mengambil kunci yang telah disimpan untuk digunakan dalam proses dekripsi. Kemudian pesan hasil dekripsi
akan ditampilkan di body e-mail.
3.1.4 Pseudocode dan Flowchart Pseudocode merupakan urutan langkah-langkah yang mendeskripsikan dari
algoritma-algoritma yang mempunyai struktur sederhana dengan tujuan untuk memudahkan manusia dalam memahami prinsip-prinsip algoritma. Flowchart adalah
bagan yang memperlihatkan urutan dan hubungan antar proses beserta pernyataannya. Dengan adanya flowchart pengguna dapat lebih mudah memahami bagaimana sistem
bekerja.
1 Pseudocode Proses Enkripsi Urutan proses enkripsi yang dilakukan untuk mengenkripsi pesan dituliskan
sebagai pseudocode seperti pada gambar 3.9.
Universitas Sumatera Utara
Gambar 3.9 Pseudocode Algoritma Enkripsi Massey-Omura
Pada pseudocode nomor 1 sampai 42 merupakan proses utama dalam pengenkripsian menggunakan Massey-Omura, dimulai dengan mengambil pesan
yang terdapat di body e-mail kemudian membaca penanda yang terdapat pada pesan. Jika terdapat tanda asterix maka karakter akan dipisah-pisah oleh tanda
spasi yang kemudian disimpan di dalam suatu array. Kemudian dua karakter terakhir akan dihapus karena berupa karakter spasi dan bilangan prima yang
sudah tidak diperlukan. Namun, jika tidak terdapat tanda asterix maka sistem akan mengambil nilai desimal dari kode ASCII yang telah diketikkan di body e-
mail dan kemudian membangkitkan bilangan prima untuk menghitung modulo eksponensial dari tiap-tiap karakter.
Universitas Sumatera Utara
2 Pseudocode Proses Dekripsi Urutan proses enkripsi yang dilakukan untuk mengenkripsi pesan dituliskan
sebagai pseudocode seperti pada gambar 3.10.
Gambar 3.10 Pseudocode Algoritma Dekripsi Massey-Omura
Pada pseudocode nomor 1 sampai 41 merupakan proses utama dalam pendekripsian menggunakan Massey-Omura, dimulai dengan mengambil pesan
yang terdapat di body e-mail serta mengambil kunci dan bilangan bilangan prima yang telah disimpan saat proses enkripsi. Setelah itu, sistem akan membaca
penanda yang terdapat pada pesan. Jika terdapat tanda asterix maka karakter terakhir berupa tanda asterix akan dihapus. Kemudian dihitung modulo
Universitas Sumatera Utara
eksponensial dari tiap-tiap bilangan. Namun, jika tidak terdapat tanda asterix maka sistem akan menghitung modulo eksponensial dari bilangan-bilangan yang
terdapat di body e-mail dan mengembalikan kode ASCII dari nilai desimal yang dihasilkan.
3 Pseudocode Pembangkit Bilangan Prima Urutan proses pembangkitan bilangan prima yang dilakukan dituliskan sebagai
pseudocode seperti pada gambar 3.11.
Gambar 3.11 Pseudocode dan Kompleksitas Algoritma LPG
Pada pseudocode nomor 1 sampai 38 merupakan proses dalam pembangkitan bilangan prima menggunakan Lehmann Prime Generator, dimulai dengan
mengambil p secara acak dan mengecek apakah modulo dari bilangan tersebut
Universitas Sumatera Utara
tidak sama dengan nol. Kemudian dilakukan penghitungan Legendre sebanyak jumlah digit bilangan tersebut untuk memastikan bahwa bilangan tersebut pasti
prima.
4 Flowchart Proses Algoritma Massey-Omura pada Three Pass Protocol Pada algoritma Massey-Omura yang proses pengimplementasiannya
menggunakan three pass protocol, terjadi dua kali enkripsi yang dilakukan oleh pengirim dan penerima pesan. Dimana pihak pertama melakukan proses enkripsi
pertama E
1
akan menghasilkan cipherteks yang menjadi plainteks untuk pihak kedua dan setelah itu pihak kedua mengenkripsi lagi E
2
menghasilkan cipherteks yang akan didekripsi oleh pihak pertama. Begitu juga dengan proses
dekripsi pertama D
1
dan proses dekripsi kedua D
2
seperti gambar 3.12.
Universitas Sumatera Utara
Mulai
Plainteks P
Chiperteks C
2
Cipherteks C
1
Enkripsi I eA
Enkripsi II eB
Plainteks P
Chiperteks C
3
Dekripsi I dA
Dekripsi II dB
Selesai
Gambar 3.12 Flowchart Proses Three Pass Protocol
Universitas Sumatera Utara
5 Flowchart Enkripsi Proses enkripsi merupakan proses mengubah pesan asli ke cipherteks sehingga
tidak dimengerti. Terdapat dua kali proses enkripsi pada algoritma Massey- Omura. Proses yang terjadi pada enkripsi akan dijelaskan pada Gambar 3.13.
Mulai
Plainteks P
Cipherteks C
1
Selesai Generate bilangan prima
p
Ambil eA 2 eA p - 1
dA eA
-1
mod p-1
C
1
m
eA
mod p
Gambar 3.13 Flowchart Proses Enkripsi I
Universitas Sumatera Utara
Keterangan : eA
: Kunci enkripsi sender p
: Bilangan prima m
: Plainteks dA
: Kunci dekripsi sender
Mulai
Cipherteks C
1
Cipherteks C
2
Selesai Ambil eB
2 eB p - 1
dB eB
-1
mod p-1
C
2
C
1 eB
mod p
Gambar 3.14 Flowchart Proses Enkripsi II
Universitas Sumatera Utara
Keterangan : eB
: Kunci enkripsi receiver p
: Bilangan prima m
: Plainteks dB
: Kunci dekripsi receiver
6 Flowchart Dekripsi Proses dekripsi merupakan proses mengembalikan ciphertext ke plaintext pesan
asli. Terdapat dua kali proses dekripsi pada algoritma Massey-Omura. Dimana pesan asli akan diperoleh setelah proses dekripsi ke-2. Proses yang terjadi pada
dekripsikan dijelaskan pada gambar 3.15.
Mulai
Cipherteks C
2
Cipherteks C
3
Selesai C
3
C
2 dA
mod p
Gambar 3.15 Flowchart Proses Dekripsi I
Universitas Sumatera Utara
Mulai
Cipherteks C
3
Plainteks P
Selesai C
4
C
3 dB
mod p
Gambar 3.16 Flowchart Proses Dekripsi II
7 Flowchart Proses Pembangkitan Bilangan Prima dengan Menggunakan Lehmann Prime Generator
Kunci yang digunakan pada sistem ini dibangkitkan secara acak. Proses
pembangkitan kunci akan terlihat pada flowchart seperti pada gambar 3.17.
Universitas Sumatera Utara
Mulai
Plainteks P
Selesai Bilangan prima
L = 1 atau L ≡ -1
tidak
Pencarian L sebanyak jumlah
digit p L
≡ a
p-12
mod p
ya
ya tidak
Generate bilangan prima p
Generate bilangan acak a, 1ap
Gambar 3.17 Flowchart Proses Pembangkitan Bilangan Prima
Keterangan : L
: Legendre a
: bilangan yang diambil secara acak dengan ketentuan 1ap p
: bilangan prima
Universitas Sumatera Utara
3.2 Perancangan Sistem