Crypting text with Java and salt

[Koot Jart]

Hi!

I'm writing a small stand alone Java application. One part of application is, that it is supposed to encrypt a piece of plaintext and save that to a file. I'm using Java's crypto package for encrypting with AES-algorithm. My application does not have any user identification. Only that one file is encrypted with password.

Encrypting is done pretty simple way. User gives a password for encrypting and it is used as a key.

I have been adviced, that "salt" should be used. In practice this would mean, that password and salt are combined and then used as a key. This would require, that salt should be save somewhere.

My application should work so, that I can copy encrypted file to an other computer and open it there with my application (if I know the password). This is not possible, if I use unique salt.

Conclusion off all this is, that using salt for better encryption is not possible. Or have I understood something wrong?

[Henry Wong]

I have been adviced, that "salt" should be used. In practice this would mean, that password and salt are combined and then used as a key. This would require, that salt should be save somewhere.

Generally, the salt is stored with the encrypted text. It is also generally stored in clear form -- not encrypted. Believe it or not, there is no reason to protect the salt.

My application should work so, that I can copy encrypted file to an other computer and open it there with my application (if I know the password). This is not possible, if I use unique salt.

Which is why the salt has to be stored with the encrypted file (or as part of the encrypted file) in clear text form. This way, you can get the salt, combine it with the password, and decrypt the file.

Conclusion off all this is, that using salt for better encryption is not possible. Or have I understood something wrong?

The purpose of a salt is to make it difficult to tell if files are the same. Without the salt, you can tell if two files are the same without decrypting it. With a salt, a random salt is generated, stored with the file (say the beginning, and not encrypted) followed with the encypted text.

You can encrypted the same file many times, and you should get different results. Of course, to decrypt, you need the salt to do it, which you can get from the file (say the beginning) and then decrypt the rest of the file with it.

Henry

[Koot Jart]

Thanks for you answer Henry!

Generally, the salt is stored with the encrypted text. It is also generally stored in clear form -- not encrypted. Believe it or not, there is no reason to protect the salt.

Ok. This is what I have been told.

Which is why the salt has to be stored with the encrypted file (or as part of the encrypted file) in clear text form. This way, you can get the salt, combine it with the password, and decrypt the file.

But can you tell me how this would help me for better security? If I store the salt with encrypted file, then I have to do some kind of parser, which will parse salt from file and combine it with password. Then attacker can take my code, check how parser works and use that to for his brute force attack.

The purpose of a salt is to make it difficult to tell if files are the same. Without the salt, you can tell if two files are the same without decrypting it. With a salt, a random salt is generated, stored with the file (say the beginning, and not encrypted) followed with the encypted text.

I do understand purpose of this. But in my application this is not so relevant. I'm just encrypting a piece of plaintext (which lenght will vary anyway) and then store that encrypted text to a file. Attacker won't really benefit about the file size info anyway.

Br
Uuno

[Henry Wong]

But can you tell me how this would help me for better security? If I store the salt with encrypted file, then I have to do some kind of parser, which will parse salt from file and combine it with password. Then attacker can take my code, check how parser works and use that to for his brute force attack.

Security is only as good as the weakest link. If you can do a brute force attack, without the salt, adding a salt is not going to help here. Your problem is the key.

As for why certain people recommend using the salt, it has to do with the ability to decrypt a file by matching patterns between encrypted files. With some algorithms (which I don't think AES is one of them), it is theortically possible to determine what changed in a file (or what parts of the file has changed) by looking at the encrypted file diffs.

The salt adds a random key to it, hence, solves this problem. You can argue that you know the salt, but so what? The purpose is to elimate the common patterns. With a key change, the encrypted file will change dramtically, even if the clear text doesn't change, or changes only a bit.

I do understand purpose of this. But in my application this is not so relevant. I'm just encrypting a piece of plaintext (which lenght will vary anyway) and then store that encrypted text to a file. Attacker won't really benefit about the file size info anyway.

Well, this is a different question. You asked what was a salt, which we answered. As for whether it is useful for your purposes, that is a issue that you need to take up with your manager, peers, client, etc.

Henry

[Koot Jart]

Thanks again for your answer Henry!

There are certain things, that are mandatory for my application.

- It has to be possible to move encrypted file to the other computer. And of course open it there with same password using my application.

Security is only as good as the weakest link. If you can do a brute force attack, without the salt, adding a salt is not going to help here. Your problem is the key.

With this kind of application, brute force attack is always possible, if attacker knows the source code of application. I think there is nothing what I can do with this. Or is there? Only thing what can be done, is to use strong password.

Of course I could improve security very much, if encrypted file was tied to only one computer. But this is not possible. It must be possible to move files between computers.

[Henry Wong]

With this kind of application, brute force attack is always possible, if attacker knows the source code of application. I think there is nothing what I can do with this. Or is there? Only thing what can be done, is to use strong password.

Just because a brute force attack is always possible, doesn't mean that it is always possible...

For example, let's say someone figured out how to break your algorithm in an hour (average) -- using only a brute force algorthm. If the key was 16 bits longer, then that hour becomes more than 5 years. If the key was another 16 bits longer, then it becomes more than 300,000 years. (hope I did my math right)

So, a brute force attack is possible, but is 300,000 years really possible?

Since the AES algorithm, uses at least 128 bits, it should be plenty secure. It's probably easier to break your system, by breaking into the datastore where the passwords are stored, or use a keylogger to examine what users are typing, than to try to use a brute force attack.

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

[Koot Jart]

Just because a brute force attack is always possible, doesn't mean that it is always possible...

Heh, yes Henry brute force attack is always possible. You are right

Since the AES algorithm, uses at least 128 bits, it should be plenty secure.

Actually I'm using 256 bit encryption. What I'm worried about is reverse engineering attack. Not really simple brute force attack.

[Henry Wong]

Originally posted by Uuno Turhapuro:

Actually I'm using 256 bit encryption. What I'm worried about is reverse engineering attack. Not really simple brute force attack.

You have to clarify what you mean by a "reverse engineering attack".

If you mean someone finding an algorithm, to decrypt the file without the key, or with only part of the key... Keep in mind that the best minds in the world have been trying to break AES, and has not been successful so far.

Henry

[Henry Wong]

And it looks like your other topic...

https://coderanch.com/t/420295/Security/Crypting-Java-security

Which started out with a different question has converged somewhat, as is basically discussing the same thing.

Henry

[Koot Jart]

You have to clarify what you mean by a "reverse engineering attack".

If you mean someone finding an algorithm, to decrypt the file without the key, or with only part of the key... Keep in mind that the best minds in the world have been trying to break AES, and has not been successful so far.

I use AES for encryption and also decryption. In practice this means following. I have method

Encryption(String plain, String key)

which takes in plaintext and key (key = users password). Method does encryption using Java's standar crypto package and AES algorithm.

For decryption I have method

Decryption(String key, String path_to_encrypted_file) 

This method is also using Java's crypto package and AES algorithm, but now for decrypting.

Now attacker can decompile my Java-code. Check how method Decryption works and then do brute force attack simply by trying all possible passwords as a place of String key.

If user has used very strong password, it will be not possible to have succesfull brute force attack in reasonable time, but if password is weak, then this kind of brute force attack is possible.

[Henry Wong]

Now attacker can decompile my Java-code. Check how method Decryption works and then do brute force attack simply by trying all possible passwords as a place of String key.

So?!? The attacker still has to reverse engineer AES -- which the best minds in the world hasn't done yet. And as people already mentioned, with a brute force attack, the world could be gone by the time the file is decrypted.

If user has used very strong password, it will be not possible to have succesfull brute force attack in reasonable time, but if password is weak, then this kind of brute force attack is possible.

With a good hashing algorithm, you can always have a strong key, even if the user's password is weak. Regardless, I don't think there is any proof that AES is affected by this -- and even if it is... Okay, so the attacker can get the data, in a million years, instead of in a zillion years.

Now... You can make the argument that the attacker doesn't attack the key, but the original password (actually you did, I have to learn to read better), but that is not an encryption issue. You have to solve that by forcing your users to pick passwords, with restrictions. Maybe have the code that sets the password check for a length, check for a least one number, check for at least one punctuation, etc. -- disallowing the password if not acceptable.

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

[Henry Wong]

Now... You can make the argument that the attacker doesn't attack the key, but the original password (actually you did, I have to learn to read better), but that is not an encryption issue....

This actually reminds me of something that happened many years ago... One of my clients asked me to double the keysize of the encryption that they were using. Basically, I said... Why? the current size is 128 bits, that's 16 bytes. It's probably 10 bytes longer than the password that the encryption is protecting. If I were to break this system, I'll go after the password, not the key that protects it -- that's the weak link.

Henry

[Koot Jart]

Henry: You have propably allready noticed, that I'm not native english speaker. May be I have been using wrong words, but I think now we are talking right things.

So?!? The attacker still has to reverse engineer AES -- which the best minds in the world hasn't done yet. And as people already mentioned, with a brute force attack, the world could be gone by the time the file is decrypted.

No, attacker don't have to reverse engineer AES. He can use same Java's crypto part functions what I have been using. He can see from the code that I'm using AES for decrypting and can do same things what I have been doing.

Now... You can make the argument that the attacker doesn't attack the key, but the original password (actually you did, I have to learn to read better), but that is not an encryption issue.

This is actual point. I have been talking all the time password attack. Anyway, attack where attacker is using my code for trying different passwords. Maybe reverse engineering is not the correct term with this kind of attack.

You have to solve that by forcing your users to pick passwords, with restrictions. Maybe have the code that sets the password check for a length, check for a least one number, check for at least one punctuation, etc. -- disallowing the password if not acceptable.

Actually, I have allready done this. It is not forcing user to use strong passwords, but it recommends to this.

Br
Uuno

[Henry Wong]

Actually, I have allready done this. It is not forcing user to use strong passwords, but it recommends to this.

Well, then you are done... there is nothing more to do. The only improvement is probably to force the user to use strong password.

The encryption is not the weak link, so improving it won't improve security. Changing the algorithm, or the size, or even whether to use a salt won't help here.

Henry

[Henry Wong]

This is actual point. I have been talking all the time password attack. Anyway, attack where attacker is using my code for trying different passwords. Maybe reverse engineering is not the correct term with this kind of attack.

Well, not to rub salt on this -- pun intended...

You didn't really get to the point all that quick. The original topic was about salting the keys to the AES algorithm, and how would that improve security.

Henry

[Koot Jart]

Hi Henry!

You didn't really get to the point all that quick. The original topic was about salting the keys to the AES algorithm, and how would that improve security.

Well yes. I mean that I was talking all the time password attack. Not any other kind of attacks.

[Koot Jart]

Henry, one more thing:

Hyv�� Joulua ja Onnellista Uutta vuotta!

Pid� lippu korkealla tulevaisuudessakin ja vastaile tyhmiin kysymyksiin yht� k�rsiv�llisesti kuin teit minunkin kanssani.

Parhain Terveisin
Uuno

[Paul Clapham]

Originally posted by Uuno Turhapuro and run through Google Translate by Paul Clapham:
Merry Christmas and Happy New Year!

Keep the flag flying in future, and answered questions tyhmiin same patience as you did to mine with me.

Yours Sincerely,
Uuno

Thank you Uuno, and a happy holiday season to you from all the staff at the Ranch.

[fred rosenberger]

Originally posted by Uuno Turhapuro:
Henry, one more thing:

Hyv�� Joulua ja Onnellista Uutta vuotta!

Pid� lippu korkealla tulevaisuudessakin ja vastaile tyhmiin kysymyksiin yht� k�rsiv�llisesti kuin teit minunkin kanssani.

Parhain Terveisin
Uuno

Please remember that this is an English only site. If you post something in another language, at MINIMUM, you must provide a translation. In any case, non-English posts are subject to deletion.

[Koot Jart]

Please remember that this is an English only site. If you post something in another language, at MINIMUM, you must provide a translation. In any case, non-English posts are subject to deletion.

Sorry about this. I was not saying anything mean. Only just Merry Christmas and thanking Henry for his answers.

Br
Uuno
[ December 17, 2008: Message edited by: Koot Juurt ]