Mozilla Thunderbird dan Add On pada Mozilla Thunderbird Analisis Sistem

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