sudah sudah.. sing sabar semuanya. ini gara2 ada 2 thread dengan judul sama persis :P
2010/6/21 Monang Setyawan <mon...@gmail.com> > > > > Pak Daniel, dari mana saya bisa tahu bahwa diskusinya spesifik tentang SMS? > Saya coba search dari awal thread ini, dan baru menemukan kata SMS di email > yang bapak kirim. Ataukah mungkin saya harus mendeduksi konteks dari thread > lain? > > Maaf kalau ngelantur :) > > 2010/6/20 Daniel Baktiar <dbakt...@gmail.com> >> >> >> >> 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: >>> # 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, 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?..-- >>> > >>> >>> > >> >>> > > ------------------------------------ ==== Buktikan Anda peduli pendidikan Indonesia. Dukung Kurikulum SMK berJava.. kirimkan surat resmi perusahaan dukungan ke moderator JUG. === Kalau mau keluar dari mailing list ini, caranya kirim sebuah email ke jug-indonesia-unsubscr...@yahoogroups.com. Jangan lupa, website JUG Indonesia adalah http://www.jug.or.id Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/jug-indonesia/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/jug-indonesia/join (Yahoo! ID required) <*> To change settings via email: jug-indonesia-dig...@yahoogroups.com jug-indonesia-fullfeatu...@yahoogroups.com <*> To unsubscribe from this group, send an email to: jug-indonesia-unsubscr...@yahoogroups.com <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
