This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Encryption and decipherment and so on can be a really dicey subject to work in front of some of the masters we have here at Java Ranch: Real encryption is fiendishly difficult to implement reliably. What you are likely talking about is a more beginnerish simple computer science exercise that is not hard to code, and if you think about it char++ will scramble the brain of casual curiosity seekers, but ( though you may think otherwise right now ) is not considered encryption.
Simple XOR against a random string ( google for fourmilab.ch ) is my prefered approach, temp buffers and so on are not hard to figure out if you can phrase the question as you did. String even has a built in hashcode method which you should look at. Simon Singh's frequency chart is an extremely good place to start reading, if you intend to do some real encipherment studies, but be forewarned - the books by this author are extremely engaging and will keep you occupied for at least one read through at a minimum. Check out also Cartouche for Ramses Google for "ROT-13", and try to write a simple lookup-table, mapping one character value to another character value, along with some ultra-breakable 'shifting index' approaches, google for The Vigen�re cipher is named for Blaise de Vigen�re .
"The differential equations that describe dynamic interactions of power generators are similar to that of the gravitational interplay among celestial bodies, which is chaotic in nature."
If this is for a school project though, I really think you shouldn't use the standard Java encryption package. My guess is that the assignment is that you learn how to implement encryption, not use existing libraries. Nicholas Jordan's post will help you out; implementing ROT-13 is quite easy to implement indeed.
Joined: Jul 10, 2007
I wish it was a school project. I will definitly look up some crypto methodology and best practices after this project.
Joined: Sep 17, 2006
Well, my arena of expertise is field operations generally and if your task is My requirement says the userid and password shall be encrypted. then you really need to check out Pat Farrell's response to my beginnersih encryption posted in:
I don't want to scare you off with how much this guy actually knows, but he will certianly weigh in on this one if he thinks you are trying to mix beginnerish with encryption ( which is called enciperment by the keepers of Kar Toumb car tome ) and if you really want to have some beginner fun, try working it the other way: map word meaings to simple character stuff such as String and so on.
Be sure and mail us a post card from the land of the lost when you figure out you are lost, we will help you get back on track, from the wide track of where you are think you are going to where you actually need to be.
Suffice it to quote Schneier A Self-Study Course in Block-Cipher Cryptanalysis:
The only way to learn cryptanalysis is through practice. A student simply has to break algorithm after algorithm, inventing new techniques and modifying existing ones. Reading others' cryptanalysis results helps, but there is no substitute for experience.
Breaking a cipher doesn't necessarily mean finding a practical way for an eavesdropper to recover the plaintext from just the ciphertext.
In academic cryptography, the rules are relaxed considerably.
Breaking a cipher simply means finding a weakness in the cipher that can be exploited with a complexity less than brute-force.
Never mind that brute-force might require 2 ^ 128 encryptions; an attack requiring 2 ^ 110 encryptions would be considered a break.
Breaks might also require unrealistic amounts of known or chosen plaintext 2 ^ 56 blocks|or unrealistic amounts of storage: 2 ^ 80. Simply put, a break can just be a "certificational weakness": evidence that the cipher does not perform as advertised.
Originally posted by Adam Teg: My requirement says the userid and password shall be encrypted.
For casual use, most folks leave the userid in the clear, and push the userid through a one-way hash, say SHA1 or SHA256 to generate a HMAC. There are lots of RFC standard ways to do this.
The approach means that if a user calls in and says "I lost my password" your tech support has to say "Can't tell you what it is, but I can change it to a temporary value, you can log in and change it to something you can remember"
Good design never lets anyone ever recover a password.
Joined: Sep 17, 2006
I have additional thinking about your goal. This may be shocking, but you can find worse on the book rack at the grocery store.
There are three types of people (narrowly for our burden of explaination):
The third type is shipped out of Cold Clown Harbor on Diesel Engines. There is no such thing as beginner cryptograpy, like hot ice and reliable sales disclosure, the real world is better modeled by Lorimar's fantasy Brother Backstabbing Brother series than by the Fantasia of Dreamland's Beginner Cryptography cassette tape.
You need to immediatley isolate Best Practices as distinct and a separate goal from any concept of writing beginner crypto, which you should relabel novice enciperment. Henry knows Best Practices in Java, or can find them for you; Pat is a fluent in the real world aspects of this, I have to go for now and leave you in their guidance.
When you can describe effectively the smell of burning human flesh, I will let you tell me that you are doing beginner crypto.