aspose file tools*
The moose likes Java in General and the fly likes Enryption with Java Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Enryption with Java" Watch "Enryption with Java" New topic
Author

Enryption with Java

Koot Jart
Greenhorn

Joined: Sep 25, 2008
Posts: 25
Hi!
I'm implementing a small Java application and part of that I need to encrypt (and of course decrypt) some text. I'm using Java Crypto package and AES algorithm in crypting.

When doing encyption I'm using password as crypting key. I think this is not a good idea. If somebody uses weak password, it is very easy to break crypted file.

I'm going to change my crypting class so, that it uses password to generate a long key. After this I can use that long key for encrypting. Do you think this is a good idea in general?
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61653
    
  67

"Javamies", please check your private messages for an important administrative matter.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18990
    
  40

When doing encyption I'm using password as crypting key. I think this is not a good idea. If somebody uses weak password, it is very easy to break crypted file.


There are two concerns here. First, weak passwords. Second, weak keys. You can take a strong password, and create a weak key.

Keep in mind that passwords are text -- they use letters and numbers (and punctuations). These fall in a very specific range in ASCII. If you just take the bytes from the string to create the key. The key will be weak, even if the password is strong.


Now... IMHO, you need to have them both strong. If you have a weak key, obviously, it can be broken...

You can, in theory, take any password, run it through a MD5 + SHA256 + etc., and you get a strong key. However, you can decompile the class files, figure out the algorthm on generating the key, and then try to break it from there. This is why you also need a strong password.


Sorry for the rant. Hopefully, I didn't detour the topic too much.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Carey Evans
Ranch Hand

Joined: May 27, 2008
Posts: 225

There are some things you can do to improve password-based encryption keys, like using PBKDF2 to derive the key bytes from the password characters. Together with a random salt or initialisation vector for the password, and when using CBC mode with another initialisation vector for the encryption, this at least means that you can't use rainbow tables to break the weak passwords.

I think this is right:Your biggest problem is where to store the password and salt or the key bytes.
Carey Evans
Ranch Hand

Joined: May 27, 2008
Posts: 225

I should explain the use of the salt with the key. You don't need to keep it secret; you just need to make sure it's very random, and generate a new salt every time the password is generated or changed. This ensures that you get a completely different secret key, even for the same password, and even for weak passwords.

In particular, this means that you can't generate a simple list of one secret key for each weak password; for my example, you would need to generate 340,282,366,920,938,463,463,374,607,431,768,211,456 secret keys for each password.
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4659
    
    5

Originally posted by Henry Wong:
You can, in theory, take any password, run it through a MD5 + SHA256 + etc., and you get a strong key. However, you can decompile the class files, figure out the algorthm on generating the key, and then try to break it from there. This is why you also need a strong password.


There is little to be gained by using a string of hash functions. Even in theory, it adds very little.

Much better to require a pass phrase, not a password. Hash that and use the result as the key.

Filter against the usual list of known terrible passwords
At least eliminate the list in CERT weak password list

Most attempts to make people use "strong" passwords fail. Humans are terrible at remembering arbitrary strings of letters and numbers. So they end up using something like p4ssw0rd which is not much stronger than "password"

With a pass phrase, the user can pick one, say "the king is a fink" and have a prayer of remembering it.

I don't agree with Henry's observation that you can just decompile the code. While true, its not important. Keeping the algorithm secret is just SBO Security By Obscurity. It doesn't work.

The only real security is to use trusted, well publicized algorithms with strong keys.
Koot Jart
Greenhorn

Joined: Sep 25, 2008
Posts: 25
Hi again and thanks for your answers!

Actually I think I have to be a little bit more specific. My application is J2ME application, that is just writing a crypted file to phone's memory. It is not an application that would need user identification. Password is just used to generate a key for encrypting and decrypting purposes.

Carey Evans wrote:
I should explain the use of the salt with the key. You don't need to keep it secret; you just need to make sure it's very random, and generate a new salt every time the password is generated or changed. This ensures that you get a completely different secret key, even for the same password, and even for weak passwords.


How I can make complitely random salt? If salt is different every time, how decrypting is then done? I can generate whole new key based on password, but I should be able to generate that same key when decrypting that file.
Koot Jart
Greenhorn

Joined: Sep 25, 2008
Posts: 25
Hi!
I hope everybody noticed my name change. I used to be Javamies, now I'm Uuno Turhapuro.
Martijn Verburg
author
Bartender

Joined: Jun 24, 2003
Posts: 3274
    
    5

Yes and thank you for following our policy


Cheers, Martijn - Blog,
Twitter, PCGen, Ikasan, My The Well-Grounded Java Developer book!,
My start-up.
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4659
    
    5

Originally posted by Uuno Turhapuro:
How I can make complitely random salt? If salt is different every time, how decrypting is then done? I can generate whole new key based on password, but I should be able to generate that same key when decrypting that file.


You call a secure random number generator. Java has one.

You store the salt in the clear. You do not have to store the cipher key, you just use it to encipher, and use it again to decipher.

Sometimes its helpful to put a known string in the cleartext so you can quickly tell if the decipher worked. If you do this, you should also use an IV and store it also in the clear.
Carey Evans
Ranch Hand

Joined: May 27, 2008
Posts: 225

Originally posted by Pat Farrell:
Sometimes its helpful to put a known string in the cleartext so you can quickly tell if the decipher worked. If you do this, you should also use an IV and store it also in the clear.

And since a lot of documents are likely to start with a known string anyway, like <xml version="1.0"?> or "PK\x03\x04", in my opinion you should should always use a cipher mode that takes an IV, like AES/CBC/PKCS5Padding.

I don't know whether it matters if you use the same IV for the password and the cipher.
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4659
    
    5

Originally posted by Carey Evans:
I don't know whether it matters if you use the same IV for the password and the cipher.


To be effective, you must use a unique IV for each stream you encipher. Reusing the IV is a major source of weakness in the process.

Or more precisely, you can never reuse an IV for a specific key.
 
wood burning stoves
 
subject: Enryption with Java