untuk klarifikasi kepada monang dan henry girsang. coba perhatikan thread di sini. http://tech.groups.yahoo.com/group/jug-indonesia/message/71725
saya mengomentari posting oleh hendry suwanda (hendry_...@...), lalu ferdinand (ot...@...) mengomentari komentar saya. 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:<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 >>> > > >>> > > >>> > >>> >>> >> > > > -- > "Don't worry about what anybody else is going to do. The best way to > predict the future is to invent it." - Alan Kay > >
