Android, JAVA

SMS Kriptografi dengan Algoritma Blowfish pada Android

Written by Resika Arthana · 1 min read >

Materi ini disampaikan sebagai tugas UAS pada perkuliahan di Jurusan Manajemen Informatika – Universitas Pendidikan Ganesha.

Secara default, SMS dikirim dalam bentuk plain text (meskipun di encoding/decoding dengan PDU) tanpa terenkripsi dari pengirim ke penerima SMS. Jika ada sniffing/penyadapan di jalur komunikasi, maka teks SMS akan sangat mudah dibaca oleh penyadap.

Tantangan anda adalah membuat aplikasi yang bisa mengenkripsi SMS yang akan dikirim, menjadi chipertext dengan algoritma kriptografi yang anda pilih sendiri. Sehingga Teks SMS yang lewat pada jalur komunikasi dan masuk ke operator seluler adalah dlm bentuk chipertext(susah ditebak isi SMSnya). Pada penerima SMS, dilakukan Deskripsi teks SMS yang berupa  chipertext sehingga bisa dibaca secara normal oleh penerima SMS.

Berikut adalah contoh aplikasi SMS kriptografi dengan Algoritma Blowfish pada Android.

Apa itu algoritma Blowfish

[wikipedia] Blowfish merupakan algoritma kunci simetrik cipher blok yang dirancang pada tahun 1993 oleh Bruce Schneier untuk menggantikan DES. Pada saat itu banyak sekali rancangan algoritma yang ditawarkan, namun hampir semua terhalang oleh paten atau kerahasiaan pemerintah Amerika. Schneier menyatakan bahwa blowfish bebas paten dan akan berada pada domain publik. Dengan pernyataan Schneier tersebut blowfish telah mendapatkan tempat di dunia kriptografi, khususnya bagi masyarakat yang membutuhkan algoritma kriptografi yang cepat, kuat, dan tidak terhalang oleh lisensi.

Keberhasilan blowfish dalam menembus pasar telah terbukti dengan diadopsinya blowfish sebagai Open Cryptography Interface (OCI) pada kernel linux versi 2.5 keatas. Dengan diadopsinya blowfish, maka telah menyatakan bahwa dunia open source menganggap blowfish adalah salah satu algoritma yang terbaik. Kesuksesan blowfish mulai memudar setelah kehadiran algoritma-algoritma dengan ukuran blok yang lebih besar, seperti AES. AES sendiri memang dirancang untuk menggantikan DES. Sehingga secara keseluruhan AES lebih unggul dari DES dan juga blowfish.

selengkapnya tentang blowfish[official] :  http://www.schneier.com/blowfish.html

Tampilan Menu Aplikasi SMS Kriptografi(Enkripsi dan Deskripsi) dengan algoritma Blowfish pada Android

Menu Kirim SMS. SMS yang dikirim akan di enkripsi dengan algoritma Blowfish dengan key yang sudah ditentukan

SMS diterima oleh handphone biasa tanpa aplikasi Deskriptor Algoritma Blowfish dalam bentuk chipertext (non human readable)

Teks SMS biasa bisa dibaca dengan aplikasi Android yang mendecrypt chiperttext menjadi plaintext

Source Code Algoritma  Blowfish

Tertarik? Silakan download dibawah ini. Aplikasi ini jauh dari sempurna, karena tidak ada yang sempurna di dunia ini, mari sempurnakan yang ada 😉

Source Code Blowfish

Download Source Code Lengkap : SMS Kriptografi(Enkripsi dan Deskripsi) dengan Blowfish Algorithm (6434)

 

Written by Resika Arthana
I Ketut Resika Arthana, staff dosen di Undiksha. Juga sebagai ketua divisi pengembangan sistem informasi di UPT TIK - Undiksha. Selain itu, juga sebagai co-founder PT. Hooki Global Kreasi. Bidang ilmu ditekuni : pemrograman, datamining, user experience dan IOT Profile

43 Replies to “SMS Kriptografi dengan Algoritma Blowfish pada Android”

  1. Sorry …source code anda sangat bagus..tapi saya mau bertanya..pas saya membuat aplikasi sms dengan metode RSA dengan cara anda berhasil..tapi proses dekripsi nya …teks yang muncul berupa simbol..Kenapa ya??harap dibalas atau email..terima kasih

  2. ane butuh bgt source code ini gan.tapi ane gak tau giman cara buka program ini,,mohon bantuanx gan,,,please,,ane mohon bgt

  3. Selamat Petang

    Resika Arthana Mini Project sama dengan anda cuma Encripsi Saya tu adalah RSA. Kamu boleh tolong saya codingnya

    daripada

    ngliangshen

    ngliangshen@gmail.com

    Android (Mobile Client) Access Login checking by RSA key Bit Length (1024 to 2048 bit) is a barrier before moving to the server checking the password and username if match transmitting back
    RSA key lengths
    When you create an RSA key pair, you specify a key length in bits, as generally you would for other algorithms. Specifically, the key length of an RSA key specifies the number of bits in the modulus. In our RSA encryption example, we specified a key length of 2048 bits. But in practice, what RSA key length should we choose?
    First the short answer:
    • a RSA key length of 1024 bits is sufficient for many medium-security purposes such as web site logins;
    • for high-security applications1 or for data that needs to remain confidential for more than a few years, you should use at least a 2048-bit key, and consider having a contingency plan for migrating to larger key sizes;
    • to keep data confidential for more than the next two decades, RSA recommends a key size larger than 2048 bits (see below).
    So, why not just make the key much longer, say 4096 bits or even 8192 bits? Well, as usual, there’s no such thing as a free lunch. A larger key increases the maximum number of bytes that we can encrypt at once, and also the security of the encryption. But it has a serious problem in practice:
    With every doubling of the RSA key length, decryption is 6-7 times times slower.
    Figure 1 shows how decryption time increases with modulus length. The timings were made on a 2GHz Pentium.

    Figure 1: RSA decryption time by key length.
    The key length also affects the speed of encryption, but it’s usually the speed of decryption that we’re more concerned about because (a) that’s the part that takes place on the server, and (b) decryption is much much slower than encryption, because the decryption exponent is huge (whereas the encryption exponent is typically small).
    If we use a 4096-bit modulus, it takes around a second of CPU time to decrypt a block of data. Even if you were able to sacrifice this amount of CPU to every log on, it leaves us with the problem that an attacker can effectively burn a second of CPU time on our server by firing some random data at it. With a 1024-bit key length, decryption takes just 25 milliseconds; with suitable restrictions on the rate of login attemps (and thus decryptions) we allow per remote client, protecting against a “CPU burn” attack is more feasible.
    How secure is an n-bit RSA key?
    As ever, judging the security of a key of a given size is a complex issue. With current knowledge, “breaking” an RSA key by brute force effectively means factoring the modulus. The largest number that has been factored publically to date is RSA-640, a 640-bit number put up as a challenge by RSA and factored in 2005. This number took “only” around 350 CPU hours (using a cluster of 80 2.2 GHz Opterons). Put another way, you can rent that CPU time from Amazon for about 50 dollars. This is a simplistic view: it doesn’t take into account memory and data transfer requirements. And the experimental software used by the team isn’t exactly a “plug and play RSA cracker”: it surely requires considerable configuration by somebody well versed in number theory.
    Factoring RSA 512-bit keys is now squarely within the reach of anyone who is determined enough. As testimony to this, several 512-bit RSA keys used to sign the operating systems of Texas Instruments calculators were recently factored, reportedly within “several months”.
    So what about 1024-bit keys? Generally, this size will keep your data safe now from an adversary with modest resources. But it’s not sufficient for keeping data confidential much into the future, or for keeping it secret from an adversary prepared to devote a few million dollars to the problem. To see why, we’ll look below at some estimates on the difficulty of breaking 1024-bit RSA encryption.
    One estimate is made by Shamir & Tromer (2003) in their hypothetical TWIRL device. They suggested that for “a few dozen million US dollars”, a hardware device could be built to break a 1024-bit RSA key within around a year. Franke et al (2005) similarly estimate a cost of 200 million dollars2 for a machine to factorise a 1024-bit number in one year. If these cost estimates are accurate, it’s safe to assume that the NSA has built such a machine (unless they have another way of breaking RSA more efficiently). And by Moore’s Law alone, we’d assume that their machine takes considerably less than a year.
    Based on Shamir & Tromer’s estimate, Kaliski (2003)— see reference in footnote 1— recommends the following RSA key lengths depending on how long data is intended to remain confidential:
    Recommended RSA key sizes depending on lifetime of confidential data.
    Lifetime of data RSA key size
    Up to 2010 1024 bits
    Up to 2030 2048 bits
    Up to 2031 onwards 3072 bits
    Shamir & Tromer considered hardware because they estimated that a solution in software would not scale beyond around 500 bits. Thorsten Kleinjung (one of the tem that broke RSA-640) estimates that around 8.4 million CPU years are needed to factorise a 1024-bit number in software3 (his estimate is specifically 8.4 million uniprocessor PCs, taking into account memory and data transfer requirements). Using my favourite crude approximation, that’s a million or so dollars of rented CPU time in 2009. It’s not clear if and how this would scale to, say, several thousand 256-core machines (bearing in mind that that could be a fairly modest botnet by, say, 2020).
    Ferguson & Schneier (2003) in Practical Cryptography are actually more conservative than the RSA recommendations:
    “The absolute minimum size for n is 2048 bits or so if you want to protect your data for 20 years. […] If you can afford it in your application, let n be 4096 bits long, or as close to this size as you can get it.” (p. 233)
    They also recommend checking that your software supports keys up to 8192 bits, “just in case”. To my knowledge, Sun’s RSA implementation does in principle support this size, but at present it is impractical performance-wise.
    ________________________________________
    1. RSA recommend 1024-bit keys for “enterprise keys” and 2048-bit keys for “root keys” (used for signing). See, for example, Kaliski, B. (2003), TWIRL and RSA Key size.
    2. Franke, J. et al (2005), SHARK: A Realizable Special Hardware Sieving Device for Factoring 1024-Bit Integers in Cryptographic Hardware and Embedded Systems � CHES 2005, Springer.
    3. See Kleinjung, T. Estimates for factoring 1024-bit integers

  4. Thank you, I’ve just been searching for information about this subject for a while and yours is the greatest I’ve discovered so far.

    However, what in regards to the conclusion? Are you certain concerning the source?

  5. I’m no longer positive where you’re getting your information, however great topic. I must spend some time studying more or understanding more. Thank you for fantastic info I used to be on the lookout for this info for my mission.
    .-= earn money by forex power trading´s last 1 ..1 =-.

  6. mohon maaf sebelumnya, bila saya ingin ubah algoritmanya menjadi AES128 apakah saya hanya tinggal ganti package nya saja?
    terima kasih sebelumnya.

  7. you are really a excellent webmaster. The website loading speed is amazing.

    It seems that you are doing any distinctive trick.
    In addition, The contents are masterwork. you have done a excellent activity
    on this matter!

  8. mf knp projectnya hanya bsa dienkripsi namun setelah msk ke baca sms memesukkan perintah key “rey10248” akan tetapi tidak bsa mengembalikan tulisan sms yg semula..hanya terdapat peringatan “tidak ada sms yg dpt dipecahkan dg key tersbut…mhn pencerahannya gan

  9. Hey there! I’m at work surfing around your blog from my new iphone
    3gs! Just wanted to say I love reading through your blog and look forward to all your posts!

    Keep up the superb work!

  10. Terrific article. I’d been looking at continuously this blog page with this particular fascinated! Handy information and facts in particular the best area 🙂 My spouse and i take care of such facts a lot. I used to be in search of this specific specified information to get a long time. Many thanks along with enjoy.. download minecraft

  11. I hardly comment, but after browsing through a few of the responses on SMS Kriptografi dengan Algoritma Blowfish pada Android | IT 4 our life.
    I actually do have some questions for you if it’s okay.
    Is it only me or do a few of the remarks look like they are coming from brain dead
    people? 😛 And, if you are posting on additional
    places, I would like to follow anything fresh you have to post.
    Could you post a list of every one of your social networking pages like your twitter feed, Facebook page
    or linkedin profile?

  12. Attractive component to content. I simply stumbled upon your website
    and in accession capital to say that I acquire in fact loved account your weblog
    posts. Any way I’ll be subscribing for your feeds or even I
    fulfillment you get right of entry to persistently
    quickly.

  13. Just desire to say your article is as astounding. The clarity in your
    put up is simply cool and that i can suppose you’re knowledgeable in this
    subject. Fine together with your permission allow me to take hold of
    your feed to stay up to date with approaching post.
    Thank you a million and please continue the rewarding work.

  14. Having read this I believed it was very informative.
    I appreciate you finding the time and effort to put this
    information together. I once again find myself personally
    spending way too much time both reading and commenting. But so what,
    it was still worth it!

  15. Dance contests for cash prizes had been standard in dance halls and attracted teenagers
    and younger adults. The legendary story of this
    musical household’s escape from Nazi Austria is likely one of
    the finest-liked tales in latest history. It doesn’t appear to be there’s a lot
    of a profound meaning anymore.

Leave a Reply

Your email address will not be published. Required fields are marked *

Page optimized by WP Minify WordPress Plugin