After coming back to this part in my project I would really like to understand AES encryption with better understanding. As another member here pointed out the code below has glaring security holes which I want to fix and make secure. I do not know too much about AES encryption but its Panarea that interests me and I want to learn more about, I understand the concept but would politely ask a senior developer to help me out on this one. I want to understand where to put the IV and any other methods to ensure max security on this thanks.
public Cipher getCipherEncrypt(final byte[] key) throws Exception {
AES algorithm get its security from key and iv. AES supports 3 types of key sizes. (129, 192, 256). 256 is more secured. These are key bytes size.
You have used very short key and exposed it. It should be kept in secret so that no one have access to it.
Secondly to add more randomness in the cipher output, we use IV. IV should also be of 16 bytes and random w.r.t to mode and padding used.
Normally we don't hand out complete examples, but when it comes to security, I think it's best to have a clear example because there's a lot of bad code floating out there. Have a look here:
Let us know if you need some explanation.
Yeah that was my primary concern, obtaining a solid fool proof example that I can learn from and dissect later; I found a lot on the subject combing the web , but its more of a piece by piece together thing I find and those pieces sometimes don't fit well with one another, so the example that complete so I can see the inner workings is much appreciated
I updated the code with comments. Please review them carefully. Make sure you understand them, and make sure to look up the technical terms I'm using.
IV, key, password, salt, stream cipher, block cipher, authenticated encryption, counter mode, etc. are important things to know about when dealing with encryption.
An extra note about authenticated encryption (The reason we're using "AES/GCM/NoPadding" and not "AES/CBC/PKCS5Padding"):
When you encrypt something, that's just a transformation to make the data appear random to whomever is not authorized to read it. The problem is that messages can be forged by attackers using very smart techniques. It's important that before you decrypt a message and read it's content, you must make sure that the encrypted message really was encrypted by a trusted person and not by an attacker. This is what authentication does. AES-GCM will refuse to even try to decrypt the message if it notices a mismatch between the key and the ciphertext. AES-CBC and other forms of unauthenticated encryption will happily try to decrypt the message, and in the best case give you random junk, and in the worst case will give you a readable message from an attacker giving you misleading info.
Both of these are used to randomize the output of a cryptographic function.
Salts are used so that if you derive two keys from the same password, both will appear completely different.
IVs are used so that if you encrypt the same message twice with the same key, both will appear completely different.
Technically this means that if you derive a new key from a password every time you want to encrypt a message, the randomization has already happened when you provided a salt, and the IV is not necessary.
If you store keys (and their salts) into a database or key store for later use, then you MUST generate a random IV for every message that you encrypt using that key.