Crypting with Java and security

[Koot Jart]

Hi!

I wan't to test my ideas with your guys, who are more experienced than I am.

I'm writing a small stand alone Java application. Lets call this application JavaSecure. JavaSecure is application, which should encrypt a piece of plaintext and then save that to a file. Of course decrypting that file should be also possible. I'm using Java's crypto package for encrypting with AES-algorithm. There is no user identification, only password used as a seed of key, when encrypting is done.

There is one mandatory thing for JavaSecure. It should be possible to open encrypted file in other computer, if user knows the password for the file and have JavaSecure installed. This way it is possible for me to create encrypted file, send it via email to my friend, then call to my friend and tell him the password. After that my friend can open file using JavaSecure.

There is one bad thing with this kind of application. That is reverse engineering and brute force attack. If somebody has possibility to check source code, he can see how key is generated. Then that person can write application that is using decrypting method and just trying all possible passwords until correct one is founded. This is possible, if used password is very short. But with strong passwords it is not possible.

What I'm asking from you guys. Is it possible to avoid these kind of brute force attacts? I know it is possible with other kind of applications, that can use salt and user identification. But I don't think it is possible for me, because it must be possible to open encrypted file in other computer using only password. Only thing that makes encrypted file secure is password, that is strong enough.

Best Regards
Uuno

[Ulf Dittmer]

I don't understand what you think can be recovered by reverse engineering the code. The key is not part of the code, so all the code might reveal is what algorithm is used for encryption (AES, TripleDES, etc.) That doesn't give the attacker much to work with.

Brute force attacks are always possible - there's nothing you can do to prevent someone who has the ciphertext to try all keys imaginable. But that's not a practically feasible attack, unless you're with a 3-letter agency. And even they would have a hard time with AES (assuming there's no backdoor).

[Henry Wong]

What I'm asking from you guys. Is it possible to avoid these kind of brute force attacts? I know it is possible with other kind of applications, that can use salt and user identification. But I don't think it is possible for me, because it must be possible to open encrypted file in other computer using only password. Only thing that makes encrypted file secure is password, that is strong enough.

The purpose of using encryption is not to prevent "brute force attacks" from happening -- it's just not possible. The purpose of encryption -- of which AES is probably one of the best right now -- is to make it such that if a brute force attack is done...

By the time the data is decrypted, or when computers are fast enough to do it at a reasonable amount of time, all parties that may be interested in the data are long dead. And the data has been considered useless long ago, as both the Morlocks and Eloi have their own problems.

Henry
[ December 14, 2008: Message edited by: Henry Wong ]

[Pat Farrell]

The whole point of using strong ciphers (AES, etc.) is that the only strength is in the key. The algorithm is published. Anyone can find it. Anyone can run it to decipher the enciphered text.

But without the key, its impossible for a long time. Done right, the sun will go supernova first.

But it has to be a strong key, using a password in ASCII doesn't cut it. You have to take the user's input and make it strong, usually by running it through a hash such as SHA1.

The key is the only strength. If you lose it, forget it, etc. you are cooked.

AES128 is approved for use by the US Government for Secret data. It is possible that the NSA could crack it. Its unlikely that a minor security agency, say ISI in Pakistan has the budget to break it. MI-5/6 in the UK, Mossad in Israel, perhaps. How to break it using brute force is well known, but takes cubic dollars and many machines and many years.

[Pat Farrell]

Originally posted by Ulf Dittmer:
algorithm ...TripleDES,.

You really should not consider TrippleDES. DES is obsolete. AES is much faster than TrippleDES and is considered as strong. Plus, DES is cursed with the known weak keys.

Just use AES and forget DES.

[Henry Wong]

Originally posted by Pat Farrell:

You really should not consider TrippleDES. DES is obsolete. AES is much faster than TrippleDES and is considered as strong. Plus, DES is cursed with the known weak keys.

Just use AES and forget DES.

Just throwing in my 2 cents in defence of TripleDES, as I think that it may have been unfairly criticized....

DES has *not* been broken -- in the tradition sense. There is some proof that with certain keys, you can narrow down the answer faster, with a known set of patterns. And you can probably make the argument, that it has been "broken" with a brute force search, with a very powerful computer, over the span of a day.

The main weakness is purely the size of the key. Tripling the size of the key (or doubling depending on the 3DES setup) drastically improves the protection. If it takes a day to break DES, with it's 56 bit key -- it will take 2 to the power of 56 days longer (if you use the version of 3DES that only double the keys).

Now, I agree that it is not the best algorithm, but it's not a bad choice either. Heck, if you are the paranoid type, then I recommend that you don't throw everything in one basket. How about using AES for one project, and 3DES for another? This way, if decades from now, someone actually breaks either algorithm -- only half the applications that you wrote over the decades are compromised...

Henry
[ December 15, 2008: Message edited by: Henry Wong ]

[Pat Farrell]

Originally posted by Henry Wong:
DES has *not* been broken

The main weakness is purely the size of the key. Tripling the size of the key (or doubling depending on the 3DES setup) drastically improves the protection. If it takes a day to break DES, with it's 56 bit key -- it will take 2 to the power of 56 days longer (if you use the version of 3DES that only double the keys).

DES was broken by the EFF last century 22 hours and 15 minutes. This is not instant, but it was broken. At the time, a really fast PC was a P3-750. Today, a desktop PC has a quad processor, each at more than 2 GHz. (The EFF hack was a FPGA, but the relative speeds of the technology still apply). So a really fast PC today is roughly ten times faster. That takes the EFF hack down to two hours. Granted, no one will bother, the point was made.

Far more important, DES is obsolete. It was declared obsolete on 19 May 2005, when FIPS 46-3 was officially withdrawn. While 3DES is still accepted, its far slower, and not stronger than just using AES.

There is no reason to use DES, its gone. There is no advantage to 3DES.

There is a process ongoing now to replace AES with something better. But for now, just use AES. Its no harder to use, its faster than 3DES, its a standard, its well understood. The standard Java libraries contain AES.

The EFF hack was against 56 bit DES. Most naive use of DES uses only 48 bits, which greatly simplifies the attack, and speeds it up by 2^8

While two key 3DES was popular back in the mid-90s, there is no reason to use it today, again using it simplifies and speeds up the attack.

Its really simple, no new code should use DES or 3DES.

[Koot Jart]

Thanks for your answers guys. Those make things clearer for me. One question to Pat:

But it has to be a strong key, using a password in ASCII doesn't cut it. You have to take the user's input and make it strong, usually by running it through a hash such as SHA1.

I don't quite understand this. If I use SHA1 to make a "hash", why can't possible attacker do the same? Attacker can read source code, he knows what I'm using. How does this help me?

Currently what I'm doing is, that I take password as seed, run it through method that makes it 32 characters long "random" string and do encrypting after that with Java's crypto package. I think encrypting is now 32*8=256 bytes.

Br
Uuno

[Pat Farrell]

Originally posted by Uuno Turhapuro:
If I use SHA1 to make a "hash", why can't possible attacker do the same? Attacker can read source code, he knows what I'm using. How does this help me?

Currently what I'm doing is, that I take password as seed, run it through method that makes it 32 characters long "random" string and do encrypting after that with Java's crypto package. I think encrypting is now 32*8=256 bytes.

The reason you hash it is to make it a better key, the hash will use more of the key space. Consider if the password is entered in US-ASCII. There are a number of problems that make this not good (tm) :

There are no characters in US-Ascii that use the high order bit, So to start, you don't have 256 possible values, you have 128.

The first 31 characters in ASCII are not printable, so users are not likely to use them

the last character is usually handled as delete, so you can not enter that either.

so you have only 96 possible byte values out of 256. Not good

then, humans don't like to use passwords with special characters or even digits, so the likely key characters are only [a-ZA-Z] or 52 characters.

humans can't remember strong passwords, so its likely to be far less random than calculated.

By encouraging your users to use long passwords or phrases, and putting it through a SHA, you greatly improve the entropy of the result.

Granted, if Mallet has the source code, they know what you are doing. But you can strengthen the code against dictionary attacks by using a HMAC rather than a pure SHA, and its easy. Just read in a prefix and suffix string from a Java property file that is not visible to Mallet, and calculate

val = sha1(prefix + passphrase + suffic);
[ December 16, 2008: Message edited by: Pat Farrell ]