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?
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.
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.
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.
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.
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.
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.
Just because a brute force attack is always possible, doesn't mean that it is always possible...
Since the AES algorithm, uses at least 128 bits, it should be plenty secure.
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.
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.
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....
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.
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.
Actually, I have allready done this. It is not forcing user to use strong passwords, but it recommends to this.
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 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.
Thank you Uuno, and a happy holiday season to you from all the staff at the Ranch.
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.
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.
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.