Requirements yang ada akan dibagi menjadi 2 dua bagian. Bagian
pertama adalah Functional Requirement yaitu aktivitas dan service yang harus disediakan oleh sistem yang akan dikembangkan. Bagian kedua adalah
Nonfunctional Requirement yaitu fitur-fitur lain yang diperlukan oleh sistem agar
sistem dapat lebih memuaskan.
a. Functional Requirements
Sistem yang dikembangkan harus mempunyai functional requirements sebagai berikut:
1. Aplikasi yang ada harus dapat mengirim sms ke handphone penerima. a. Pada saat pengiriman data sms, pengirim harus memasukan password dari
sms tersebut. b. Aplikasi dapat melakukan enkripsi data SMS.
2. Handphone penerima ketika menerima pesan yang masuk dari HP pengirim data atau pesan yang ada masih di enkripsi, ketika HP penerima memasukan
password proses deskripsi dilakukan. 3. Sistem memiliki tingkat keamanan yang tinggi dalam pemprosesan pesan.
4. Algoritma yang digunakan untuk enkripsi dan deskripsi adalah algoritma RSA.
5. Adanya fasilitas inbox dan outbox yang digunakan untuk menyimpan dan melihat data sms yang masuk dan keluar.
6. Adanya fasilitas petunjuk penggunaan teknis atau bantuan pada aplikasi, sehingga aplikasi mudah digunakan.
b. Nonfunctional Requirements
Nonfunctional Requirements dari sistem yang dikembangkan akan
dijelaskan dalam bentuk tabel berikut:
Tabel 4.3
Nonfunctional Requirement
Jenis Kebutuhan Penjelasan
1. Model Tampilan Performance a Tampilan interface yang menarik dan
lebih user friendly sehingga lebih mudah dimengerti dan digunakan
oleh user.
2. Model Penyimpanan Data Information
a Model penyimpanan data yang digunakan bukanlah suatu tools
database, tetapi menggunakan tools dari J2ME yang bernama RMS, RMS
merupakan suatu mekanisme yang digunakan
oleh MIDP
untuk menyimpan data, pada dasarnya
RMS menyimpan
kumpulan kumpulan record pada memori
persistence. Dengan digunakannya RMS,
sehingga aplikasi
yang dijalankan tidak perlu mengakses
dari tools database lain, sehingga
tidak memberatkan aplikasi yang dijalankan.
3. Model Pengontrolan Sistem Control
a Meningkatkan keamanan terhadap pelaksanaan proses penyimpanan
data. b Membatasi
akses penggunaan
terhadap aplikasi
dengan cara
menerapkan input password pada HP pengirim dan penerima .
c Mencegah kebocoran pesan kepada pihak yang tidak berwenang.
4. Model Efisiensi Sistem Eficiency
a Menggunakan sistem penyimpanan data
yang terpadu
untuk memudahkan proses cross-checking
pesan antara pengirim dan penerima. b Mengefisienkan
waktu untuk
pelaksanaan proses
validasi pembacaan pesan
4.2.1.3 Analisis Keputusan Decision Analysis
Dari tahapan analisis sebelumnya telah diketahui permasalahan dari sistem berjalan dan persyaratan dan kebutuhan sistem yang diinginkan, maka fase
selanjutnya adalah analisis keputusan yaitu menentukan komponen-komponen dari sistem usulan yang akan dirancang, dibangun dan diimplementasikan. Berikut
merupakan komponen-komponen yang dibutuhkan: 1. Data SMS masuk
Data sms masuk tersimpan didalam inbox pada bagian ini user dapat membalas sms, mengedit sms dan menghapus sms yang masuk.
2. Data SMS keluar Pada data sms keluar fitur yang disajikan sama dengan data sms masuk, pada
bagian ini dilengkapi fasilitas membalas sms, mengedit sms dan menghapus sms yang masuk.
3. Enkripsi dan Dekripsi data Enkripsi data dilakukan ketika pesan akan disampaikan ke HP penerima.
Dekripsi data dilakukan ketika pesan diterima dari HP pengirim. Enkripsi dan dekripsi data menggunakan algoritma RSA. Algoritma RSA adalah adalah
sebuah algoritma pada enkripsi public key. RSA merupakan salah satu algoritma yang paling maju dalam bidang kriptografi public key. RSA masih
digunakan secara luas dalam protokol electronic commerce, dan dipercaya dalam mengamankan dengan menggunakan kunci yang cukup panjang.
4. Bantuan Bantuan adalah petunjuk teknis penggunaan aplikasi yang bisa dibaca oleh
user yang menggunakan aplikasi. Berikut ini adalah alur kerja sistem yang diusulkan :
Gambar 4.1. Alur kerja sistem yang diusulkan
Setelah mengetahui komponen-komponen sistem yang diusulkan selanjutnya adalah menentukan jenis perangkat sistem yaitu berupa tools atau alat untuk
merancang dan mengimplementasikan sistem ususlan sehingga menghasilkan
arsitektur sistem yang diinginkan. Dalam menentukan arsitektur sistem usulan yang terpenting adalah pemahaman terhadap jenis tools yang akan digunakan
karena harus sesuai dengan kebutuhan pengguna dan fungsi-fungsi sistem yang terdapat didalamnya.
Sistem usulan dirancang dengan menggunakan UML Unified Modeling Language
, dan bahasa pemograman JAVA khususnya J2ME. Sehingga konsep tentang UML dn JAVA harus benar-benar dikuasai.
4.2.2 Perancangan Aplikasi
4.2.2.1. Identifikasi Use case dan Aktor
Identifikasi aktor dan use case ini didasari pada kebutuhan fungsi-fungsi sistem. Kebutuhan akan fungsi ini diakomodir di use case. Selanjutnya use case
menyediakan nilai hasil kepada aktor. Atas dasar spesifikasi ini paling tidak didapat cara menetukan aktor.
Berdasarkan penjelasan bab sebelumnya use case mencakup aliran-aliran kerja workflow dalam sistem bersifat internal sedangkan aktor-aktor mencakup
segala sesuatu yang ada di luar sistem bersifat eksternal. Perbedaan antara use case dan aktor yang sedang dibahas saat ini dengan use case bisnis dan pekerja
bisnis dibahas secara sekilas pada tabel di bawah ini.
Tabel 4.4 Perbedaan Objek-objek dalam Model Bisnis dan Model Sistem.
Nama Objek Model Bisnis
Model Sistem
Use Case Mendeskripsikan apa yang
dikerjakan perusahaan atau instansi.
Mendeskripsikan sistem
yang akansedang
dikembangkan dalam
perusahaan atau instansi. Aktor
Bersifat eksternal terhadap perusahan atau instansi.
Bersifat eksternal terhadap sistem yang akansedang
dikembangkan Pekerja Bisnis
Bersifat internal dalam perusahaan atau instansi.
Tidak digunakan
Pemodelan sistem dilakukan untuk mendeskripsikan use case apa saja dan aktor yang akan terlibat dalam analisis sistem usulan, dapat dilihat dalam tabel
requirement aktor dan use case berikut ini.
Tabel 4.5 Requirement Aktor dan Use case
Requirement Aktor
Use case
1. Pengirim sms dapat mengirim sms. Pengirim
Kirim SMS
2. Pengirim dan penerima sms dapat melihat data sms masuk yang
tersimpan dan juga dapat mengedit, membalas dan menghapus sms.
Pengirim dan penerima.
Inbox
3. Pengirim dan penerima sms dapat melihat data sms keluar yang
tersimpan dan juga dapat mengedit, membalas dan menghapus sms.
Pengirim dan penerima.
Inbox
4. Penerima sms dapat membaca sms yang masuk.
5. Penerima dan pengirim sms dapat membaca
petunjuk teknis
penggunaan aplikasi. Penerima
Pengirim dan Penerima
terima SMS
bantuan
4.2.2.2.2Use Case Diagram
Use Case Diagram menjelaskan apa yang akan dilakukan oleh sistem yang
akan dibangun dan siapa yang berinteraksi dengan sistem. Use Case Diagram dapat dibuat sesuai dengan tabel Requirement Aktor dan Use Case di atas. Berikut
ini adalah use case diagram untuk aplikasi enkripsi SMS.
Gambar 4.2
Use case Diagram
4.2.2.3 Use Case Scenario
Setiap use case di atas harus di deskripsikan dalam dokumen yang disebut dokumen flow of event. Dokumentasi ini mendefinisikan apa yang harus
dilakukan oleh sistem ketika aktor mengaktifkan use case. Struktur dari dokumen use case
ini bisa bermacam-macam tetapi umumnya deskripsi ini paling tidak harus mengandung:
1. Brief Description deskripsi singkat 2. Aktor yang terlibat
3. Precondition yang penting bagi use case untuk memulai 4. Deskripsi rinci dari aliran kejadian yang mencakup
a. Main flow dari kejadian yang bisa dirinci lagi menjadi sub flow dari kejadian sub flow bisa dibagi lagi lebih jauh menjadi sub flow yang lebih
kecil agar dokumen lebih mudah dibaca dan dimengerti b. Alternative flow untuk mendefinisikan situasi perkecualian
5. Postcondition yang menjelaskan state dari sistem setelah use case berakhir Selain beberapa hal yang disebutkan di atas, dapat juga memakai beberapa
deskripsi tambahan lainnya untuk melengkapi pendeskripsian yang dibuat. Setelah menjelaskan use case pada bahasan sebelumnya, maka berikut ini akan dijelaskan
spesifikasi use case yang telah ditentukan. 1. Use case kirim SMS
Tabel 4.6 Use case scenario kirim SMS
Use Case Name
kirim SMS
Actor
Pengirim
Description
Use case ini digunakan pengirim SMS untuk mengirimkan SMS.
References Gambar 4.2
Actor Action System Response
Typical Course of Events Step
1: Actor memilih kirim SMS
Step 3: Actor memasukan
no yang dituju ketik pesan dan memasukan password.
Step 2: Sistem
menampilkan form untuk kirim SMS.
Step 4 : Sistem
mengenkripsi sms dan mengirimkan pesan.
Alternative Course Jika pesan tidak terkirim maka user harus mengulang
step 1
Pre Condition Actor
belum mengirimkan sms dan password pada HP penerima.
Post Condition
SMS terkirim dan data sms terenkripsi.
2. Use case inbox
Tabel 4.7 Use case scenario inbox
Use Case Name
Inbox
Actor
Pengirim dan Penerima
Description Use case ini digunakan pengirim dan penerima untuk
melihat data sms yang masuk, mengedit sms, delete sms dan balas sms.
References
Gambar 4.2
Actor Action System Response
Typical Course of Events Step
1: Actor memilih menu inbox
Step 3: Actor memasukan
pilihan edit, reply atau delete.
Step 2: Sistem
menampilkan data-data SMS
Step 4 : Jika actor
memilih edit maka aplikasi akan
menampilkan form edit, jika memilih
reply,aplikasi akan melakukan proses kirim
sms, tanpa perlu memasukan nomor HP,
jika actor memilih delete maka data akan terhapus.
Alternative Course Jika pesan actor memilih reply maka akan melakukan
usecase kirim SMS.
Pre Condition
Data SMS masuk ada di inbox.
Post Condition SMS terkirim, data sms yang masuk dapat diedit dan
dihapus.
3. Use case outbox Tabel 4.8
Use case scenario outbox
Use Case Name
Outbox
Actor Pengirim dan Penerima
Description
Use case ini digunakan pengirim dan penerima untuk melihat data sms yang keluar, mengedit sms, delete sms
dan balas sms.
References
Gambar 4.2
Actor Action System Response
Typical Course of Events
Step 1: Actor memilih menu
outbox Step
3: Actor memasukan pilihan edit, reply atau
delete. Step
2: Sistem menampilkan data-data
SMS Step 4
: Jika actor memilih edit maka
aplikasi akan menampilkan form edit,
jika memilih reply,aplikasi akan
melakukan proses kirim sms, tanpa perlu
memasukan nomor HP, jika actor memilih delete
maka data akan terhapus.
Alternative Course
Jika pesan actor memilih reply maka akan melakukan usecase kirim SMS.
Pre Condition Data SMS masuk ada di outbox.
Post Condition
SMS terkirim, data sms yang masuk dapat diedit dan dihapus.
4. Use case terima SMS
Tabel 4.9
Use case scenario terima SMS
Use Case Name terima SMS
Actor
Penerima
Description
Use case ini digunakan penerima SMS untuk membaca SMS.
References Gambar 4.2
Actor Action System Response
Typical Course of Events Step
1: Actor memilih baca SMS
Step 3: Actor memasukan
memasukan password. Step
2: Sistem menampilkan form untuk
terima SMS. Step 4
: Sistem mengdekripsi sms dan
pesan ditampilkan.
Alternative Course Jika password salah maka sms tidak akan didekripsi,
dan actor harus kembali ke step 3.
Pre Condition Actor
sudah menerima SMS
Post Condition
SMS dekripsi dan dapat ditampilkan.
5. Use case Bantuan
Tabel 4.10 Use case scenario bantuan
Use Case Name
Bantuan
Actor
Pengirim dan Penerima
Description Use case ini digunakan pengirim dan penerima SMS
untuk membaca petunjuk teknis aplikasi.
References
Gambar 4.2
Actor Action System Response
Typical Course of Events
Step 1: Actor memilih menu
bantuan . Step
2: Sistem menampilkan petunjuk
teknis aplikasi.
Alternative Course
-
Pre Condition Actor
belum mengerti tata cara penggunaan aplikasi
Post Condition
Petunjuk teknis aplikasi dapat dibaca oleh actor.
4.2.2.4 Activity Diagram
Activity diagram memodelkan alur kerja work flow sebuah urutan
aktivitas pada suatu proses. Diagram ini sangat mirip dengan flow chart karena kita dapat memodelkan proses logika, proses bisnis dan alur kerja. Perbedaan
utamanya adalah flow chart dibuat untuk menggambarkan alur kerja dari sebuah sistem, sedangkan activity diagram dibuat untuk menggambarkan aktivitas aktor.
Berikut akan digambarkan satu persatu activity diagram untuk masing- masing use case.
1. Activity Diagram kirim SMS.
Gambar 4.3 Activity Diagram dari use case kirim SMS
Pertama kali pengirim memilih menu kirim SMS, kemudian sistem akan menampilkan form untuk kirim SMS, pada form tersebut pengirim menginput
nomor yang akan dikirim SMS, kemudian setelah menginput nomor maka pengirim mengetikan pesan yang akan disampaikan , setelah itu pengirim
menginput password yang akan digunakan pada SMS tersebut, setelah itu SMS akan di enkripsi dan pesan akan dikirimkan.
2. Activity Diagram Inbox
Gambar 4.4 Activity Diagram dari use case inbox
Pada activity diagram ini actor memilih menu inbox, kemudian sistem akan menampilkan data sms yang masuk, kemudian actor memilih menu yang
ada. Jika actor memilih untuk edit maka sistem akan menampilkan form edit, kemudian actor mengedit sms yang masuk. Jika actor memilih menu delete, maka
data sms yang dipilih akan terhapus dari sistem. Jika actor memilih menu reply maka sistem akan menampilkan form untuk reply, dan kemudian actor mengisi
form reply, kemudian sms di enkripsi dan sms disampaikan ke nomor tujuan.
3. Activity Diagram Outbox
Gambar 4.5 Activity Diagram dari use case outbox
Pada activity diagram ini actor memilih menu outbox, kemudian sistem akan menampilkan data sms yang keluar, kemudian actor memilih menu yang
ada. Jika actor memilih untuk edit maka sistem akan menampilkan form edit, kemudian actor mengedit sms yang keluar. Jika actor memilih menu delete, maka
data sms yang dipilih akan terhapus dari sistem. Jika actor memilih menu reply maka sistem akan menampilkan form untuk reply, dan kemudian actor mengisi
form reply, kemudian sms di enkripsi dan sms disampaikan ke nomor tujuan,
4. Activity Diagram Terima SMS
Gambar 4.6 Activity Diagram dari use case terima SMS
Pada activity diagram ini actor memilih menu baca sms, kemudian sistem akan menampilkan sms yang masuk, sms yang masuk masih terenkrip. kemudian
actor memasukan password, Jika password yang dimasukan benar maka sistem
akan mendekrip pesan SMS, dan menampilkannya ke layar penerima. Jika password yang dimasukan salah, maka actor harus memasukan password dengan
benar.
5. Activity Diagram Bantuan
Gambar 4.7
Activity Diagram dari use case bantuan
Pada activity diagram ini actor memilih menu bantuan, kemudian sistem akan menampilkan petunjuk teknis yang dapat dibaca untuk mengetahui tata cara
penggunaan aplikasi.
4.2.2.5 Sequence Diagram
Sequence diagram menggambarkan interaksi antar objek di dalam dan di
sekitar sistem termasuk pengguna, display, dan sebagainya berupa message yang digambarkan terhadap waktu. Dibawah ini adalah sequence diagram
untuk masing-masing modul.
1. Sequence Diagram Kirim SMS
Gambar 4.8. Sequence Diagram dari use case kirim SMS
Pada sequence diagram ini pengirim memilih menu kirim SMS, kemudian sistem akan menampilkan form untuk kirim SMS, pada form
tersebut pengirim menginput nomor yang akan dikirim SMS, kemudian setelah menginput nomor maka pengirim mengetikan pesan yang akan
disampaikan , setelah itu memanggil class untuk enkripsi data, setelah data di enkripsi maka pesan dikirim, dan masuk ke dalam data sms keluar.
2. Sequence Diagram Inbox
Gambar 4.9. Sequence Diagram dari use case inbox
Pada sequence diagram ini actor memilih menu inbox, kemudian memanggil modul data sms, kemudian user memilih data sms, kemudian
sistem akan memanggil class menu, jika user memilih edit, maka sistem akan menampilkan class edit, kemudian user mengedit sms yang ada. Jika
user memilih delete maka data akan di delete di hapus dari data sms masuk jika memilih reply maka sistem akan menampilkan form untuk kirim
SMS, pada form tersebut pengirim menginput nomor yang akan dikirim
SMS, kemudian setelah menginput nomor maka pengirim mengetikan pesan yang akan disampaikan , setelah itu memanggil class untuk enkripsi
data, setelah data di enkripsi maka pesan dikirim, dan masuk ke dalam data sms keluar.
3. Sequence Diagram Outbox
Gambar 4.10 Sequence Diagram
untuk use case outbox Pada sequence diagram ini actor memilih menu outbox, kemudian
memanggil modul data sms, kemudian user memilih data sms, kemudian sistem akan memanggil class menu, jika user memilih edit, maka sistem
akan menampilkan class edit, kemudian user mengedit sms yang ada. Jika user memilih delete maka data akan di delete di hapus dari data sms
keluar. Jika memilih reply maka sistem akan menampilkan form untuk kirim SMS, pada form tersebut pengirim menginput nomor yang akan
dikirim SMS, kemudian setelah menginput nomor maka pengirim mengetikan pesan yang akan disampaikan , setelah itu memanggil class
untuk enkripsi data, setelah data di enkripsi maka pesan dikirim, dan masuk ke dalam data sms keluar.
4. Sequence Diagram Terima SMS
Gambar 4.11. Sequence Diagram
untuk use case terima SMS Pada sequence diagram ini sistem memanggil data sms, kemudian
memanggil class form sms, kemudian actor menginput password, dan akan memanggil class cek password, jika password yang dimasukan
benar, maka class untuk dekripsi pesan akan di panggil dan pesan akan ditampilkan, kemudian pesan masuk ke dalam class data pesan keluar.
5. Sequence Diagram Bantuan
Gambar 4.12. Sequence Diagram
untuk use case Bantuan Pada sequence diagram ini sistem menu awal, kemudian
memanggil class bantuan, kemudian akan menampilkan bantuan pada user.
4.2.2.6 Class Diagram Class diagram
merupakan diagram yang selalu ada di permodelan sistem berorientasi objek. Class diagram menunjukkan hubungan antar class dalam
sistem yang sedang dibangun dan bagaimana mereka saling berkolaborasi untuk
mencapai suatu tujuan.
Dibawah ini adalah class diagram pada aplikasi enkripsi dan deskripsi sms:
Gambar 4.13. Class Diagram
Daftar Operasi dapat dilihat pada table 4.11 dan Daftar Atribut pada Kelas Kirim SMS dapat dilihat pada tabel 4.12
Operasi dan Atribut 1. Kelas Kirim SMS
Tabel 4.11 Daftar Operasi dari Kelas Kirim SMS Nama Operasi
Visibility Private, Public
Keterangan
Proses Enkripsi Public
Untuk mengirimkan pesan dan password yang
telah dienkripsi IsValidPhone Number
Protected Untuk memasukkan
nomor telepon penerima
Tabel 4.12 Daftar Atribut dari Kelas Kirim SMS Nama Atribut
Visibility Private, Public
Type
Hasil Enkrip Protected
String HEnkrip
Private String
Tambah Record Outbox Public
void Menu Proses Enkripsi
Private void
Menu Reply SMS Public
String Menu Kirim SMS
Private Void
Menu Forward SMS public
void
2. Kelas Enkripsi SMS
Daftar Atribut pada Kelas Enkripsi SMS dapat dilihat pada tabel 4.13
Tabel 4.13 Daftar Operasi dari Kelas Enkripsi SMS
3. Kelas Receive SMS
Daftar Operasi dapat dilihat pada table 4.14 dan Daftar Atribut pada Kelas Receive SMS dapat dilihat pada tabel 4.15
Tabel 4.14 Daftar Operasi dari Kelas Receive SMS Nama Operasi
Visibility Private, Public
Keterangan
Proses Dekripsi Public
Untuk menghitung hasil dekrip dari SMS yang
telah dienkrip
Nama Atribut Visibility
Private, Public Type
Status Protected
String Menu Reply SMS
Public Void
Menu Kirim SMS Private
Void Command Action
public Void
Hitung Enkripsi Public
String
Tabel 4.15 Daftar Atribut dari Kelas Receive SMS Nama Atribut
Visibility Private, Public
Type
txtPengirim private
String Plaintext
private String
PK private
Int txtPesan
private String
Status protected
String txtTujuan
private String
SK private
Int HasilDekrip
private String
Plaintext2 private
String Port
protected String
menuSMS private
Void Pangkat
private Void
menuProsesDekripsi private
Void Hitung Dekripsi
Public String
Dekrip private
Int Data2753
private Int
4. Kelas Outbox
Daftar Atribut pada Kelas Kirim SMS dapat dilihat pada tabel 4.16
Tabel 4.16 Daftar Atribut dari Kelas Outbox Nama Atribut
Visibility Private, Public
Type
cariRecordOutbox public
Void deleteOutbox
public Void
detailoutbox Public
Void menuForward
Public Void
menuOutbox Public
Void Menu SMS
Public Void
TambahRecordOutbox public
Void
5. Kelas Inbox
Daftar Atribut pada Kelas Kirim SMS dapat dilihat pada tabel 4.17
Tabel 4.17 Daftar Atribut dari Kelas Inbox Nama Atribut
Visibility Private, Public
Type
noPengirim protected
String txtPesan
protected String
Menu kirim SMS Private
Void menuInbox
Public Void
Delete Inbox Public
Void
Detail Inbox Public
String Cari Record
public Void
4.2.2.7. Spesifikasi Proses yang Diusulkan
Pada bagian ini akan dibahas mengenai proses perancangan sistem program, pengimplementasian kriptografi dalam proses pengambilan data SMS
dengan mempertimbangkan berbagai faktor dan kebutuhan, seperti yang telah ditetapkan pada tahap analisis sistem.
4.2.2.7.1 Rancangan Pembangkitan Kunci
Seperti yang telah di jelaskan pada bagian analisis sistem, program sistem keamanan ini akan dibuat dengan menggunakan Kriptografi RSA.
RSA merupakan sebuah algoritma pada enkripsi public key. RSA merupakan salah satu algoritma yang paling maju dalam bidang kriptografi
public key dan dipercaya dalam mengamankan dengan menggunakan
kunci yang cukup panjang. Modul-modul proses yang terdapat dalam algoritma RSA adalah sebagai berikut:
Gambar 4.14
Tahapan algoritma RSA
Dari modul diatas dapat dijelaskan sebagai berikut:
a. Algoritma Proses Pembangkitan Kunci
1. Tentukan bilangan prima p dan q 2. if p = “prima“ and q = “prima” then
3. Hitung r ← p q
4. Hitung r
← p – 1q – 1 5. Pilih PK
5.1 While PK relative prima dgn
r dan PK r 5.2
PiliH PK 4.3 END WHILE
5. Hitung SK 6. SELESAI
Keterangan dari algoritma diatas adalah sebagai berikut: Tentukan bilangan prima secara acak p dan q, setalah itu lakukan
proses perhitungan p q untuk menghasilkan nilai r sebagai modulus. Lakukan proses perhitungan p-1q-1 untuk menghasilkan nilai
ryang digunakan untuk mencari nilai SK Secret Key. Pilih bilangan bulat PK Public Key, dan selama PK adalah bilangan
pembagi terbesar dan lebih kecil dari r, lakukan proses untuk
mencari nilai SK. Berikut ini adalah flow chart pembangkitan kunci algoritma RSA.
Gambar 4.15
Flow Chart Algoritma Pembangkit Kunci RSA
b. Algoritma Penentuan Bilangan p dan q Prima
1. Mulai 3. For i=1, i=100, i++
3.1 if i = 1 Cetak “prima” 3.2 else if i = 2 Cetak “prima”
3.3 else ifi mod 2 = 0 and i mod 3 = 0 cetak “prima”
3.4 else cetak “bukan Prima” 4. END FOR
5. Selesai
c. Algoritma Proses Enkripsi