• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Enryption with Java

 
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Sheriff
Posts: 67753
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
"Javamies", please check your private messages for an important administrative matter.
 
author
Posts: 23958
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Ranch Hand
Posts: 225
Eclipse IDE Debian Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 225
Eclipse IDE Debian Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Rancher
Posts: 4804
7
Mac OS X VI Editor Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 26
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 26
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi!
I hope everybody noticed my name change. I used to be Javamies, now I'm Uuno Turhapuro.
 
author
Posts: 3285
13
Mac OS X Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes and thank you for following our policy
 
Pat Farrell
Rancher
Posts: 4804
7
Mac OS X VI Editor Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 225
Eclipse IDE Debian Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 4804
7
Mac OS X VI Editor Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Whoever got anywhere by being normal? Just ask this exceptional tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic