Perbandingan Algoritma Enkripsi GGHN(8,8) dan RC4 Untuk Video Conference

Jurnal Sistem Informasi Bisnis 01(2011)

On-line : http://ejournal.undip.ac.id/index.php/jsinbis

27

Perbandingan Algoritma Enkripsi GGHN(8,8) dan RC4 Untuk Video Conference Satriyoa, Eko Sediyonob, Adian Fatchurrohimc a Jurusan Teknik Elektro, Politeknik Negeri Pontianak Fakultas Teknologi Informasi, Univ. Kristen Satya Wacana, Salatiga c Magister Sistem Informasi, Universitas Diponegoro, Semarang

b

Abstract Encryption is a solutions to secure the information transmitted through the medium of communication that can not be intercepted by unauthorized parties. This study implemented two algorithms i.e. RC4 and GGHN (8.8) in video conference. This study compared the speed of both encryption and decryption of the encryption algorithm, and perform measurements of bandwidth. From the results of measurements of the speed can be concluded that the RC4 algorithm is 1.53 times and 1.34 times faster than GGHN(8,8) for encryption and decryption audio data. The encryption and decryption video data RC4 are 1.44 times and 1.09 times faster than GHN(8,8). Bandwidth usage for video conferencing without encryption and bandwidth usage on a video conference with RC4 encryption and GGHN (8.8) is the same. Keywords: Video Conference; RC4; GGHN(8,8); Real Time Protocol.

1. Pendahuluan Kerahasiaan dan keamanan informasi yang dikirimkan melalui media komunikasi sangat penting karena informasi yang dikirimkan bersifat rahasia.Komunikasi video conference pada rapat yang bersifat rahasia diperlukan usaha untuk menjaga informasi tidak disadap oleh pihak yang tidak berhak. Salah satu cara untuk mengamankan informasi adalah dengan melakukan enkripsi menggunakan algoritma tertentu. Komunikasi video conference yang dilakukan pada Local Area Network (LAN) menggunakan teknik multicast rawan terhadap tindakan penyadapan oleh pihak yang tidak berhak. Pada teknik multicast paket data akan dikirimkan ke semua komputer pada jaringan LAN yang membuka session dengan alamat multicast dan port yang sama, penyadap bisa mendapatkan paket data tersebut dan menampilkanya. Tetapi jika paket yang dikirimkan telah dienkripsi maka penyadap tidak bisa menampilkan paket data audio/ video yang dikirimkan. Pada penelitian ini metode enkripsi GGHN(8,8) diimplementasikan pada enkripsi video conference dan dibandingkan performance serta pemakaian bandwidth dengan metode enkripsi RC4. 2. Kerangka Teori Algoritma RC4. Agoritma ini merupakan enkripsi stream symmetric proprietary yang dibuat oleh RSA Data Security Inc (RSADSI).Penyebarannya diawali dari sebuah source code yang diyakini sebagai RC4 dan dipublikasikan secara 'anonymously' pada tahun 1994.Algoritma yang dipublikasikan ini sangat identik dengan implementasi RC4 pada produk resmi. RC4 tidak dipatenkan oleh RSADSI, hanya saja tidak diperdagangkan secara bebas (trade secret). 

Alamat email : [email protected]

KSA for i = 0 to N – 1 S[i] = i; j = 0; for i = 0 to N – 1 j = (j + S[i] + K[i mod l]) mod N; Swap(S[i],S[j]); PRGA i = 0; j = 0; while (1) i = (i + 1) mod N; j = (j + S[i]) mod N; Swap(S[i],S[j]); out = S[(S[i] + S[j]) mod N];

2.1. Algoritma GGHN Algoritma ini merupakan hasil modifikasi dari algoritma RC4 oleh Guang Gong pada tahun 2005. Algoritma GGHN(8,32) ini tiga kali lebih cepat dari algoritma RC4. GGHN (8,32) memiliki Sbox yang mempunyai 256 elemen (N = 256) bilangan bulat dengan panjang 32 bit (M = 232), sehingga Pseudo Random Generation Algorithm menghasilkan aliran kunci 32 bit, yang akan di-XOR-kan dengan Plaintext. Algoritma enkripsi GGHN adalah sebagai berikut (Gong et al., 2005) : KSA for i = 0 to N – 1 S[i] = ai; End for j = k = 0; Repeat r times for i = 0 to N – 1 j = (j + S[i] + K[i mod l]) mod N; Swap(S[i],S[j]); S[i] = S[i] + S[j] mod M; k = k + S[i] mod M; end for

Jurnal Sistem Informasi Bisnis 01(2011)

On-line : http://ejournal.undip.ac.id/index.php/jsinbis

melakukan dekripsi pada paket yang diterima sehingga tidak bisa ditampilkan/ dimainkan

PRGA i = 0; j = 0; while (1) i = (i + 1) mod N; j = (j + S[i]) mod N; k = (k + S[j]) mod M; out = (S[(S[i] + S[j]) mod N] + k) mod M; S[(S[i] + S[j]) mod N] = k + S[i] mod M;

receive

Encode

Stream

Network

transmit

Participant1 Participant2

2.2. Streaming Streaming adalah sebuah teknik yang digunakan untuk melakukan transfer data media secara langsung dari sumber ke player secara real time dan kontinyu tanpa perantara media penyimpanan (Austerberry, 2005). Data video yang dikirimkan berasal dari file multimedia atau dari peralatan multimedia misalkan webcam (Gambar 1). Capture

receive

transmit

Algoritma ini terdiri dari dua bagian yaitu Key Scheaduling Algoritma (KSA) dan Pseudo-Random Generation Algorithm (PRGA). KSA diawali dengan inisialisasi Sbox dengan suatu nilai yang telah ditentukan ai, kemudian dilakukan pengacakan Sbox sebanyak minimal 16 kali putaran (r : round). Pengacakan ini dilakukan dengan permutasi nilai Sbox dengan kunci (K). Pada tahap ini juga dilakukan penentuan nilai variabel k yang akan digunakan pada proses selanjutnya PRGA. Pembangkitan pseudorandom key dilakukan dengan mengupdate nilai Sbox dengan penumlahan elemen Sbox dengan nilai k. Proses ini berbeda dengan PRGA pada algoritma RC4 yang mengunakan operasi swap untuk mengacak Sbox. Pada penelitian ini digunakan metode GGHN (8,8) karena hasil pembacaan data dari buffer adalah data dengan type array byte. GGHN (8,8) memiliki Sbox dengan 256 (N = 256) elemen yang memiliki panjang 8 bit (M = 28).

Source

28

Decode

receive

Ilegal Participant

Gambar 2. Video Conference dengan teknik multicast 2.3. Real Time Protocol. RTP adalah protokol yang header format dan kontrolnya didesain untuk mendukung aplikasi-aplikasi transmisi data real-time seperti audio, video, dan juga simulasi data melalui suatu jaringan. Protokol RTP menggunakan User Datagram Protocol (UDP) (Gambar 3). UDP tidak berorientasi pada koneksitas (connectionless) dimana setiap paket data dikirim tanpa ada hubungan antara client dan server. Kelebihan UDP adalah kecepatan transfer data data server ke client yang lebih tinggi daripada TCP. Dengan menggunakan UDP yang dapat mengirimkan paket IP secara multicast, RTPstream yang di bentuk oleh satu terminal dapat dikirimkan kebeberapa terminal tujuan.

Display

Gambar 1. Proses Streaming Data video dari source di-capture dan disimpan dalam buffer kemudian di-encode sesuai dengan format yang diinginkan. Pada tahap ini pada umumnya juga dilakukan kompresi sehinggga ukuran data tidak terlalu besar, kemudian dilakukan streaming data video maupun data audio kepada user yang lain. Setelah data diterima maka akan di-decode kemudian ditampilkan di layar. Pengiriman paket data audio/video pada video conference menggunakan teknik multicast, memungkinkan bagi participant gelap (ilegal) untuk mendapatkan dan menampilkan paket data audio/video selama proses conference karena paket data akan dikirim ke semua komputer pada multicast group (Gambar 2). Untuk mengamankan paket data tersebut dilakukan enkripsi pada paket data sebelum paket data tersebut dikirimkan dan sebaliknya dilakukan dekripsi paket data yang diterima sehingga dapat ditampilkan. Participant gelap tidak

Gambar 3. Arsitektur RTP

2.4. Java Media Freamwork API (JMF) Java Media Framework adalah interface untuk pengembangan dan pemrosesan audio, video, dan timebased media lain dalam bahasa pemrograman java (Gambar 4). Beberapa dari fungsi JMF, yaitu : a. Dapat digunakan untuk berbagai file multimedia pada Java Applet atau aplikasi desktop. Format yang mendukung antara lain AU, AVI,MIDI, MPEG, QUICKTIME dan WAV. b. Play media streaming dari internet c. Capture audio dan video dengan mikropon dankamera video kemudian menyimpan datatersebut kedalam format yang mendukungnya. d. Mengirimkan audio dan video secara realtime ke dalam jaringan internet atau intranet.

Jurnal Sistem Informasi Bisnis 01(2011)

On-line : http://ejournal.undip.ac.id/index.php/jsinbis

Encrypted Data

Network

User1 Session manager

29 Encrypted Data

Network

User 2 Session manager

User 2

User 1

Network

DataSource DataSource

DataSource

DataSource

User1

User 2

Session manager

Processor

Player

Processor

Session manager

Player DataSource

DataSource

DataSource

DataSource

DataSource

DataSource Encrypt

Decrypt

Processor

Processor

DataSource

Encrypt

Decrypt

Processor

Processor

DataSource

Gambar 4. Diagram blok Video Conference dengan JMF Interface yang digunakan untuk video conference antara lain:  MediaLocator : untuk merepresentasikan lokasi media baik audio maupun video.  Manager : interface yang berfungsi sebagai penghubung objek, mengintegrasikan implementasi interface yang digunakan dengankelas-kelas yang ada. Misalnya dengan Manager dapat dibuat Player dari DataSource.  Player : memproses masukan data media dari suatu DataSource kemudian menampilkan pada layar dan speaker.  Processor adalah interface sejenis player yang dapat menampilkan media data.Processor menerima input media data dari datasource dan melakukan proses yang ditentukan pengguna.  DataSource : menyediakan masukan media-stream bagi Player atau Processor 3.

Gambar 5. Diagram blok Video Conference dengan enkripsi

Video

Video Native JPEG encoder

JPEG Encrypt

Decrypt

Packetizer

JPEG Depacketizer

Native JPEG decoder

Gambar 6. Proses enkripsi/dekripsi data video Data audio hasil capture mikropon akan disusun menjadi paket data audio dan dienkripsi menggunakan metode GGHN(8,8) atau RC4, kemudian akan dikirim ke user lain. Setelah paket data diterima akan langsung di dekripsi menggunakan metode GGHN(8,8) atau RC4 dan diurai kembali menjadi data audio sehingga dapat dimainkan di speaker (Gambar 7).

Perancangan Aplikasi Audio

Aplikasi video conference yang dibangun merupakan sebuah aplikasi video conference yang menggunakan metode enkripsi untuk mengamankan data audio dan video sebelum data tersebut dikirimkan. Sebaliknya sebelum data audio dan video yang diterima dapat ditampilkan/dimainkan di monitor/speaker terlebih dahulu dilakukan dekripsi. Aplikasi ini menggunakan Codec JPEG untuk video, sedangkan untuk audio tidak dilakukan compresi (Gambar 5). Data video hasil capture webcam akan dikodekan dalam format JPEG oleh JPEG encoder kemudian frame JPEG akan disusun menjadi paket data video oleh JPEG Packetizer dan sebelum dikirimkan akan diencrypt dengan metode enkripsi GGHN (8,8) atau RC4. Setelah data diterima oleh user lain maka paket video langsung didekripsi menggunakan metode GGHN(8,8) atau RC4, kemudian diurai menjadi frame JPEG oleh JPEG Depacketizer, dan terahir akan didekodekan oleh JPEG decoder sehingga bisa ditampilkan di layar (Gambar 6).

Audio PCM Packetizer

Encrypt

Decrypt

PCM Depacketizer

Gambar 7. Proses enkripsi data audio

3.1. Use Case Diagram Model Use Case adalah sebuah kumpulan dari diagram dan teks yang mendeskripsikan bagaimana keinginan pengguna berinteraksi dengan sistem.Diagram Use Case mengidentifikasikan fungsionalitas yang disediakan oleh sistem (Use Case), dan pengguna yang berinteraksi dengan sistem (aktor), dan gabungan antara pengguna dan fungsionalitas. User atau pemakai dapat memilih metode enkripsi pada video conference yaitu RC4, GGHN atau tanpa enkripsi (Gambar 8).

Jurnal Sistem Informasi Bisnis 01(2011)

On-line : http://ejournal.undip.ac.id/index.php/jsinbis GghnEng

Video Conference dengan Enkripsi RC4

captureDev +getVideoML() +capDev()

-k : short -o : byte -w : short -j : int -S : short -a : short -K : byte #KSA() : void #Encrypt() : byte #swap() : void

Video Conference denganEnkripsi GGHN

Video Conference Tanpa Enkripsi

User

VideoConf

Gambar 8. Diagram Use Case

3.2. Activity Diagram Diagran ini merupakan teknik untuk menggambarkan logika prosedural, proses bisnis, dan jalur kerja. Activity diagram untuk aplikasi video conference seperti yang terlihat pada Gambar 9. Setelah aplikasi dijalankan, user menetukan alamat multicast group, port yang dipakai dan TTL. User dapat memilih metode enkripsi RC4 atau GGHN(8,8) pada audio dan video yang akan dikirimkan. Setelah tombol conference ditekan maka user akan tergabung dalam video conference. Jika tombol stop ditekan maka video conference akan berhenti dan akan tampil waktu enkripsi dan dekripsi (Gambar 9).

Masukan Alamat dan Port

Pilih Metode Enkripsi

Conference Apakah Stop? [tidak] [ya]

Tampil waktu enkripsi/dekripsi

Gambar 9 Activity Diagam

3.3. Class Diagram Diagram ini menggambarkan struktur kelas dari suatu sistem.Class diagram juga menggambarkan hubungan yang dapat muncul antar kelas. Gambar 10 merupakan class diagram aplikasi secure video conference menggunakan metode enkripsi RC4 dan GGHN(8,8) (Gambar 10).

#sessionHandler : SessionHandler +sesionThread #strAdress : string #port : int #ttl : int #audioformat : string #videoformat : string +tencryptv : string +tdecryptv : string +tencrypta : string +tdecrypta : string +inencryptv : byte +outencryptv : byte +inencrypta : byte +outencrypta : byte +VideoConf() +actionPerformed() : void +enableAVButtons() : void +join() : void +leave() : void +printData() : void +run() : void +main() : void

#vf -g1 : GghnEng +getName() : string +getSupportedInputFormats() +getSuportedOutputFormats() +process() : int

EncryptVideo #vf -rc42 : RC41 +getName() : string +getSupportedInputFormats() +getSuportedOutputFormats() +process() : int

CaptureManager

RC4au EncryptPcm #rc4au2 : RC4au #af +getName() : string +getSupportedInputFormats() +getSupportedOutputFormats() +process() : int

+SIZE : short +s1 : short +s2 : byte -h : byte -i : int -j : int -key : byte #SimpanKunci() : void #Sbox() : void #swap() : void #encrypt() : byte

PcmDepacketizer SessionHandler

#PUGIN_NAME : string #CUSTOM_PCM : string #HDR_SIZE : int #DEFAULT_RATE : int #DEFAULT_SIZE : int #DEFAULT_CHNLS : int -SupportedInputFormats -SupportedOutputFormats -inFormat -outFormat #getName() : string #matches() : bool +getSupportedInputFormats() +getSupportedOutputFormats() +setInputFormat() +setOutputFormat() #getInputFormat() #getOutputFormat() #process() : int

#audioSessionManager() #videoSessionManager #cname : string #captureManeger : CaptureManager #audioMediaReceiver : MediaReceiver #videoMediaReceiver : MediaReceiver #audiosendStream #videoSendStream +MYPCM_PAYLOAD : int #myPcmFormat -rtcpviewer : RTCPViewer #SessionHandler() : SessionHandler #RegisterCustomPayload2() : bool #RegisterCustomPayload() : bool -sendAudio() : void -sendVideo() : void #createSessionManager() +stopSession() : void

MediaReceiver #p #Playertabel +update() +stop() DecryptVideog #vf -g2 : GghnEng2 +getName() : string +getSupportedInputFormats() +getSuportedOutputFormats() +process() : int

GghnEngau -k : short -o : byte -w : short -j : int -S : short -a : short -K : byte #KSA() : void #Encrypt() : byte #swap() : void

+SIZE : short +s1 : short +s2 : byte -h : byte -i : int -j : int -key : byte #SimpanKunci() : void #Sbox() : void #swap() : void #encrypt() : byte

EncryptPcmg #ga : GghnEngau #af +getName() : string +getSupportedInputFormats() +getSupportedOutputFormats() +process() : int

#audioProcessor #videoProcessor #videoCDI -videolocator +CaptureManager() -getAudioMedialocator() +createAudioDataSource() +createVideoProcessor() +createVideoDataSource() -endAudio() -endVideo()

DecryptPcmg #ga2 : GghnEngau2 #af +getName() : string +getSupportedInputFormats() +getSupportedOutputFormats() +process() : int

RC41

GghnEngau -k : short -o : byte -w : short -j : int -S : short -a : short -K : byte #KSA() : void #Encrypt() : byte #swap() : void

EncryptVideog PcmPacketizer #PLUGIN_NAME : string #CUSTOM_PCM : string #DataSize : int #HDRSize : int -SupportedInputFormat -SupportedOutputFormat -inFormat -outFormat -history : byte -pktHdr : byte -historyLength : int +PcmPacketizer() +getName() : string +matches() : bool +getSupportedInputFormat() +getSupportedOutputFormat() +setiputFormat() +setInputformat() +getOutputFormat() +Process() : int

30

DecryptPcm #rc4au12 : RC4au1 #af +getName() : string +getSupportedInputFormats() +getSupportedOutputFormats() +process() : int

GghnEng2 -k : short -o : byte -w : short -j : int -S : short -a : short -K : byte #KSA() : void #Encrypt() : byte #swap() : void

RC4au1 +SIZE : short +s1 : short +s2 : byte -h : byte -i : int -j : int -key : byte #SimpanKunci() : void #Sbox() : void #swap() : void #encrypt() : byte

DecryptVideo #vf -rc4 : RC4 +getName() : string +getSupportedInputFormats() +getSuportedOutputFormats() +process() : int

RC4 +SIZE : short +s1 : short +s2 : byte -h : byte -i : int -j : int -key : byte #SimpanKunci() : void #Sbox() : void #swap() : void #encrypt() : byte

Gambar 10. Class DiagramVideo Conference 3.4. Enkripsi Paket Data Video/Audio Proses enkripsi dan dekripsi paket data audio video dilakukan dalam pada codec dalam processor. Class EncryptPcm dan class DecryptPcm sebagai codec audio sedangkan class EncryptVideo dan class DecryptVideo sebagai codec video. Codec membaca data pada satu track, memproses data dari track tersebut dan menghasilkan output sesuai dengan format yang telah ditentukan. Dalam penerapan codec, yang diperlukan adalah: 1. Mengimplementasikan getSupportedInputFormats() dan getSupportedouputFormats() untuk menentukan format input dan output. 2. Mengimplementasikan method process() untuk mengolah data buffer dari input track. Sebelum paket data audio/video dikirimkan dilakukan enkripsi dengan menggunakan metode RC4 atau GGHN(8,8) dalam method process(). InputBuffer akan dicasting menjadi byte array (plaintext), kemudian akan dienkripsi menghasilkan data hasil enkripsi (chipertext) berupa byte array. Hasil enkripsi dikeluarkan sebagai outputbuffer. Sebaliknya setelah paket data audio/video diterima dilakukan dekripsi sebelum dilakukan depaketisasi. InputBuffer akan di-casting menjadi byte array, kemudian didekripsi menggunakan metode RC4 atau GGHN(8,8)

Jurnal Sistem Informasi Bisnis 01(2011)

On-line : http://ejournal.undip.ac.id/index.php/jsinbis

sehingga menghasilkan data hasil dekripsi (plaintext) berupa byte array dan dikeluarkan sebagai outputBuffer.

Percobaan Ke 7

4. Pengujian dan Analisa Pengujian aplikasi video conference dilakukan untuk masing-masing metode enkripsi secara terpisah. Dari pengujian ini akan didapatkan waktu yang dibutuhkan untuk enkripsi/dekripsi baik paket data audio maupun video. Pengujian dilakukan dengan 2 participant dan 1 ilegal participant. Saat digunakan video conference tanpa enkripsi ilegal participant bisa menampilkan paket data video dan audio, sedangkan pada saat menggunakan enkripsi RC4 maupun enkripsi GGHN(8,8) ilegal participant tidak bisa menampilkan paket video maupun audio, saat participant 1 dan 2 sedang berkomunikasi. Pengujian ini juga mengamati pemakaian bandwidth yang digunakan untuk video conference (Gambar 11 dan 12).

RC4 (Nano Second) Enkripsi Dekripsi 36877 29613

31

GGHN(8,8) (Nano Second) Enkripsi Dekripsi 43581 38273

8

27098

27377

54756

38832

9

37155

27377

43581

38832

10

37993

28775

43581

38552

Rata -rata

31512.3

28740.9

48218.4

38664.2

Tabel 2. Uji kecepatan enkripsi/dekripsi data video Percobaan Ke

RC4 (Nano Second) Enkripsi Dekripsi

GGHN (Nano Second) Enkripsi Dekripsi

1

38552

55593

59504

53358

2

32127

31568

58667

62020

3

12013

15645

53917

56152

4

26260

37714

40787

41346

5

37714

43023

39949

30730

6

49447

85205

39390

69003

7

35480

65651

57269

51403

8

40229

48330

46374

29892

9

16762

48830

34921

62858

10

42464

48330

48444

65930

Rata -rata

33104.8

47988.9

47922.2

52269.2

Ethernet Switch

Participant2

Participant1

Ilegal participant

Gambar 11 Konfigurasi pengujian

(a) (b) Gambar 12. Tampilan Video; (a) participant1; (b) Ilegal participant 4.1. Pengujian Kecepatan Data hasl pengujian kecepatan enkripsi dan dekripsi paket data video dan audio terlihat pada Tabel 1. Tabel 1 Uji kecepatan enkripsi/dekripsi data audio Percobaan Ke 1

RC4 (Nano Second) Enkripsi Dekripsi 27658 27937

GGHN(8,8) (Nano Second) Enkripsi Dekripsi 43301 38273

2

39670

27099

43581

38832

3

27098

27098

53918

38832

4

27377

37378

68724

39391

5

27099

27377

43581

38832

6

27098

27378

43580

37993

Dari hasil rata-rata pada Tabel 1 terlihat bahwa metode RC4 lebih cepat 1,53 kali bila dibandingkan dengan metode GGHN(8,8) untuk enkripsi data audio, sedangkan untuk dekripsi data audio RC4 lebih cepat 1,34 kali dibanding GGHN(8,8). Pada enkripsi data video, RC4 lebih cepat dari GGHN(8,8) sebesar 1,44 kali, dan untuk dekripsi data video RC4 lebih cepat 1,09 kali dibanding GGHN (8,8). 4.2. Pengujian Pemakaian Bandwidth Hasil pengujian pemakaian bandwidth untuk video conference dengan enkripsi RC dan video conference dengan enkripsi GGHN(8,8) ditunjukan pada Gambar 13. Pemakaian Bandwidth untuk video conference dengan enkripsi R4 maupun dengan enkripsi GGHN(8,8) sama besar yaitu 9Mbps. Kapasitas data sebelum dan sesudah enkripsi tidak mengalami perubahan karena data diXORkan dengan kunci internal yang telah dibangkitkan.

Jurnal Sistem Informasi Bisnis 01(2011)

On-line : http://ejournal.undip.ac.id/index.php/jsinbis

(a)

32

2. Metode enkripsi RC4 lebih cepat dalam melakukan enkripsi dan dekripsi paket data audio video pada aplikasi video conference dibandingkan dengan metode enkripsi GGHN(8,8). 3. Kapasitas data sebelum dan sesudah enkripsi tidak mengalami perubahan. 4. Pemakaian Bandwidth untuk Video Conference dengan enkripsi RC4 dan GGHN(8,8) sama besar. Daftar Pustaka

(b)

(c) Gambar 13. Hasil penujian bandwidth; (a) tanpa enkripsi; (b) enkripsi RC4; (c) enkripsi GGHN(8,8)

5. Kesimpulan Setelah dilakukan pengujian pada penelitian ini maka dapat disimpulkan: 1. Metode enkripsi RC4 dan GGHN(8,8) dapat digunakan untuk enkripsi / dekripsi paket data uadio/video pada aplikasi video conference.

Amor, M, Fuentes, L., Pinto, M., 2004. A survey of multimedia software engineering. Journal of Universal Computer Science, Malaga. Aslam, J., Raafique, S.., Tauseef-ur-Rehman, S., 2005. Analysis of Real Time Protocol Security. Information Technology Journal: Asian Network for Scientific Information. Austerberry, D., 2005. The Technology of Video and Audio Streaming (2nd ed.). Burlington: Focal Press. Fortino, G., Russo, W., Zimeo, E., 2003. Enhancing cooperative playback systems with efficient encrypted multimedia streaming. Proc. of IEEE Int’l Conf. on Multimedia and Expo. Gong, G., Gupta, K.C., Hell, M., Nawaz, Y., 2005. Towards a general RC4-like keystream generator. Conference on Information Security and Cryptology. 3822: 162–174, New York.: Springer. Handojo, A., 2009. Aplikasi Video Conference Dengan Kemampuan Beroperasi Pada IPv4 dan Ipv. Yogyakarta: Seminar Nasional Aplikasi Teknilogi Informasi. Mengual, L., 2001. Design and Testing of two secure Video Conferencing applications baseds on JMF (Java Media Framework) and VIC (Video Conferencing Tool). Science and Technology Ministry of Spain projects. Madrid Schulzrinne, C. .RTP: A Transport Protocol for Real-TimeApplications. http://www.ietf.org/rfc/rfc1889.txt