I am curring designing a system to encrypt/decrypt a file(txt file that contains 100,000 records). The purpose is to insert all the records into another database. Basically, I will have the encrypt program for client(users from other department) to run, and a decrypt file for the programmer to run and then insert them one by one to the database. I want to use 3DES as the encryption algorithm. I wrote the following programs as my prototype.
From the above codes, you will see the source is just a message, not a file, it's easiest way for testing the 3DES implementation. I want to put a "program" in client's pc to encrypt the file once they generated the data. However, my concern is whether I should install JRE for them individually or just to run an exe program in their pc ? I know there are many third party tools to let me convert class files into exe files. But I heard some data will be loss thru the third party converter. Is that true ?? Furthermore, do you think my code is secure enough and simple enough to implement 3DES ? Since I am new to java security, so I would like some advices from you guys.
Thanks for reading my long message, I really appreciate it.
[ January 21, 2006: Message edited by: YuenLian Wu ] [ January 21, 2006: Message edited by: YuenLian Wu ]
You're reinventing Password-Based Encryption (PBE), badly. Do some research on PBE algorithms - JCE supports at least a couple, although I don't recall exactly which ones offhand.
You're converting your ciphertext directly into a String. This is Bad. If you really must transform it into something readable/printable, use Base64. If it doesn't need to be transmitted over a String-only channel, just leave the byte alone and transmit that.
You're encrypting the whole document at once with one doFinal() call. This means you have to have the whole file in memory, twice - once for the plaintext, and once for the ciphertext. Ow. Study Cipher.update() - or better yet, CipherInputStream/CipherOutputStream, and let Java do the heavy lifting for you. (And yes, I know this is just a sample - but the whole point of a sample is to get the pathways correct)
If you rely on one password, regardless of who the customer is - then there's little point in doing this encryption. If anyone gets a hold of a copy of your program, regardless of what language you write it in and how hard you try to obfuscate it, they'll have access to your key. Five minutes later, everyone in the world can be assumed to have access to it.
If you really want to get this stuff right, I'd suggest finding a copy of Bruce Schneire et.al.'s, "Practical Cryptography". It'll help you avoid a lot of the mistakes you're about to make.
Regarding what you require of the customer - hm. The Java-to-exe path doesn't sound very efficient to me. If you think your customers won't have the JRE available, then you might want to write the client in some other language (C or C#, maybe), and distribute that. Assuming you implement the encryption correctly, the algorithms don't care what language they're invoked from.
Or, you might provide an HTTPS upload service that lets the customer transmit the file(s) directly to your server. Set up the HTTPS channel correctly, and the whole encryption issue goes away completely...
One final note - 3DES is painfully slow and no longer very secure. I'd go with AES, personally.
Good luck, Grant
In Theory, there is no difference between theory and practice.<br />In Practice, there is no relationship between theory and practice.