hi henry, coba baca diskusinya dari awal.
hm, yg gue maksud itu, justru komentar ferdinand yg mengatakan bahwa, "tidak feasible untuk implement rsa dengan carrier short message service (sms) text". gue setuju dengan itu dan ga setuju kalau diskusi yg spesifik tentang sms tiba2 di-stretch keluar konteks dengan komentar general yg kira2 "kan rsa ga dipake karena performance-nya". komentar itu berdasarkan praktek bahwa key rsa sangat besar, sehingga tidak feasible untuk sms. ferdinand tidak mengatakan bahwa "performance rsa tidak lambat", etc. kita sedang bicara konteks sms, ketika tiba2 satu orang ngomentari di luar konteks "setau gue karena performance". inti dari feasible tidak feasible yg gue dan ferdinand diskusikan, adalah, kalau pake rsa, carrier dari paket jauh lebih besar ukurannya daripada message-nya sendiri. analoginya sama seperti orang berencana mengirimkan sebuah laptop dari jakarta ke san fransisco lewat via dhl, di dalam sebuah kontainer 20 feet. ferdinand mengatakan "ga feasible kirim laptop pake kontainer". tidak feasible, berarti bukan ga bisa dilakukan. tapi orang sehat kemungkinan besar tidak mengambil pilihan itu. lalu ada yang komentar, 'kenapa pake dhl, fedex kan lebih cepat, karena dia pake pesawat'. nah itulah out of context. kita bahas masalah feasibility, sementara dia mengasumsikan ferdinand bilang bahwa "secara umum orang tidak memilih assymetric encryption karena ukuran paketnya besar" dan bukan "secara umum orang tidak memilih asymmetric encryption karena alasan performance". lalu orang mulai mengomentari hal yang berbeda dari konteks awalnya, semakin tidak membaca awal diskusi dan diskusi semakin ngelantur. 2010/6/21 Henry Girsang <ryg...@yahoo.com> > > > Daniel, > > Teori yg benar juga tidak bisa dianggap kosong juga. > Dari yg gw alami sendiri (project buat mobile banking 3 thn lalu) plus > refensi internet, justru masalah UTAMA buat asymmetric encryption itu MEMANG > di performance/resource. > > Contoh ref dr > http://www.cs.umbc.edu/~wyvern/ta/encryption.html:<http://www.cs.umbc.edu/%7Ewyvern/ta/encryption.html:> > # software encryption using DES (symmetric key algorithm) is 100 times > faster than software encryption using RSA (asymmetric key algorithm) - > estimate provided by RSA Data Securities > # hardware encryption using DES (symmetric key algorithm) is anywhere from > 1,000 to 10,000 times faster than hardware encryption using RSA (asymmetric > key algorithm) > > Apalagi kalo ngomongin di mobile application, dimana resource client > tentunya tidak bisa di upgrade semudah di server. Lebih tepat nya faktor yg > tidak dapat dikontrol. > > Tapi step2 solusi yg dibikin Ferdinand sebenarnya gw ga ada kontra. > Karena proses yang berat itu, teknik ini bisa dikombinasikan dgn symmetric > encryption. Dengan tujuan seminimal mungkin data yg di encrypt secara > asymmetric, tapi secara keseluruhan system tetap cukup secure. > > Henry Girsang > > --- In jug-indonesia@yahoogroups.com <jug-indonesia%40yahoogroups.com>, > Daniel Baktiar <dbakt...@...> wrote: > > > > yang dijelaskan ferdinand itu berdasarkan pengalaman dia, bukan sekedar > > teori. > > dan itu dilihat dalam konteks ide mengirimkan pesan menggunakan rsa via > sms. > > > > 2010/6/19 Monang Setyawan <mon...@...> > > > > > > > > > > > Setahu saya, penggunaan symmetric encryption lebih karena alasan > > > performance, bukan karena menggelembungnya size. Dan hasil untuk > symmetric > > > encryption tidak selalu sama besar. > > > > > > 2010/6/18 Ferdinand Neman <new...@...> > > > > > > > > >> > > >> Perlu diingat, Encryption pake Public Key (Asymetric) pada data yang > mau > > >> dikirim, TIDAK DI SARANKAN. > > >> Karena, hasil encryption pake Public Key akan menggelembungkan SIZE > (Hasil > > >> Encryption akan jauh lebih besar dari data aslinya). > > >> > > >> JADI, encryption dan decryption itu dilakukan dengan algoritma yang > > >> Symetric, hingga hasil encryptionnya memiliki ukuran yang SAMA besar. > > >> Symetric contohnya AES "Advanced Encryption Standard" (dengan > menggunakan > > >> SALT key). > > >> > > >> NAH, Public Key hanya dipergunakan untuk mengenkripsi SALT key. Karena > > >> keynya kecil, hasil encripsi akan menggelembung dalam ukuran kecil > juga, > > >> jadi pembekakan tidak signifikan. > > >> > > >> JADI, > > >> 1. data asli (RAW) di hash dengan MD5 atau SHA1 => HASH. > > >> 2. RAW di encrypt dengan AES ditambah SALT (SALT bisa pre-generate) => > > >> ENCRYPTED > > >> 3. RAW di sign dengan Private Key Sender (PRKS). => SIGNATURE > > >> 4. SALT di encrypt dengan Public Key Receiver (PUKR) (yang didapat > dari > > >> Verisign atau OpenPGP) => ENCRYPTED SALT. > > >> > > >> 5. Data yang dikirim adalah. ENCRYPTED + ENCRYPTED SALT + SIGNATURE + > > >> HASH. (Public Key sebaiknya tidak di tukar-tukar langsung, tapi Public > Key > > >> diambil dari trusted vendor, semacam Verisign atau OpenPGP). > > >> > > >> 6. ENCRYPTED + ENCRYPTED SALT + SIGNATURE + HASH diterima disisi > Receiver. > > >> 7. ENCRYPTED SALT di decrypt dengan Private Key Receiver (PRKR) => > SALT > > >> 8. ENCRYPTED di decrypt dengan AES + SALT => RAW. (sampai disini data > bisa > > >> dipakai, tapi untuk amannya di verify dulu). > > >> 9. RAW di verify dengan SIGNATURE + Public Key Sender (PUKS) (yang > didapat > > >> dari Verisign atau OpenPGP). => BOOLEAN. > > >> 10. Bila #9 = TRUE, RAW di hash dengan MD5 atau SHA1 => HASH NEW. > > >> 11. HASH dibandingkan dengan HASH NEW => BOOLEAN. > > >> 12 RAW sudah di verify dan diyakinkan bahwa datanya orisinil dan tidak > > >> tampered. Silahkan di embat. > > >> > > >> Beberapa skenario mungkin berbeda (biasanya cuma beda urutan), tapi > > >> prinsipnya sama. > > >> > > >> KESIMPULANNYA, PKI (Public Key Infrastructure) itu tidak hanya > > >> mengandalkan Public/Private key saja dalam data transmission. Ia juga > > >> memanfaatkan Symetric Enc/Decription. Dan dalam kasus data yang sangat > > >> sensitif, membutuhkan > > >> trusted source dimana kedua pihak bisa consult public key. > > >> > > >> Salam. > > > >> > > >> Ferdinand Neman > > >> ---- > > >> Developer Team Lead, System Analyst, > > >> System Designer and Solution Architect > > >> > > >> http://www.linkedin.com/in/fneman > > >> > > >> 2010/6/18 Thomas Wiradikusuma (milis) <wiradikusuma.mi...@...> > > >> > > >>> > > >>> > > >>> Mungkin ilustrasinya begini kali: > > >>> > > >>> Disclaimer: ini agak ngawur, tapi basic idenya bener. > > >>> > > >>> Public key: gembok > > >>> Private key: kunci utk buka gembok > > >>> > > >>> Jadi kita bagi-bagi gembok ke semua orang yg mau ngirim data ke kita. > > >>> Trus mereka gembok deh datanya, trus kirim ke kita. Berhubung cuma > > >>> kita yg pegang kuncinya, cuma kita yg bisa buka. > > >>> > > >>> > > >>> On 6/18/10, Leo Mifare <leomif...@... <leomifare%40gmail.com>> > > >>> wrote: > > >>> > Hi all, > > >>> > > > >>> > I want to ask regarding PKI RSA Encryption/Decryption.. > > >>> > RSA is a PKI cryptography example, and there are two keys, namely > > >>> Private > > >>> > Key and Public Key.. > > >>> > I'm a little bit confused regarding it.. > > >>> > Public Key dapat didistribusikan secara bebas, sedangkan Private > Key > > >>> harus > > >>> > tetap dijaga privately (it means that nobody is allowed to know > this > > >>> key, > > >>> > except me :) ) > > >>> > > > >>> > Actually the usage of both keys is like this : > > >>> > ◠Signing > > >>> > Use private key to “sign†data > > >>> > ◠Verification > > >>> > Use public key to verify “signature†> > >>> > ◠Encryption > > >>> > Use public key to encrypt data > > >>> > ◠Decryption > > >>> > Use private key to decrypt data > > >>> > > > >>> > Jadi jika Public Key and Private Key disimpulkan, maka penggunaan > > >>> keduanya > > >>> > adalah sbb : > > >>> > ◠Private Key : Sign Data and Decrypt Data > > >>> > ◠Public Key : Verify Signature and Encrypt Data > > >>> > > > >>> > Klo diimplementasikan seperti apa yach?. > > >>> > Misalkan ada 2 orang sahabat, assume that their name is A and B. > > >>> > A holds *Private Key*, and B holds *Public Key* > > >>> > Yang jadi pertanyaan saya, bagaimana jika A ingin melakukan Encrypt > and > > >>> > Verify, dan juga sebaliknya, bagaimana B dapat melakukan Decrypt > and > > >>> Sign?..-- > > >>> > > >> > > >> > > > > > > > > > -- > > > "Don't worry about what anybody else is going to do. The best way to > > > predict the future is to invent it." - Alan Kay > > > > > > > > > > >
