I have a cipher text which is encrypted using AES-128 Algorithm. I want to know the following things to decrypt the cipher.
- IV (Initialization Vector)
- Padding Method
- Encryption Key
How do I find the padding method used in the encryption?
In general, you cannot, because padding makes sure the plaintext can always be recovered, so any valid padding method produces equally valid plaintext. For instance, suppose the last (decrypted) block is, in hexadecimal notation:
01:02:03:04:05:06:07:08:09:0A:0B:0C:0D:FF:00:00
The "natural" interpretation is that the padding method here might be "add an FF byte, then pad the rest with zeroes". But it could equally well have been "put the message at the end, insert an FF byte before, then pad with random non-FF bytes at the beginning", so that the message is in fact 00:00
. Or it could have been "append a 05 byte, then pad with non-05 bytes", giving the message 01:02:03:04
. You would rightly argue that the last two padding methods are unusual, but they are admissible.
In short, if you know absolutely nothing about the plaintext and do not make assumptions about possible padding methods, then you simply cannot know for sure which padding method was used. In other words, you cannot decrypt your message reliably without knowing the padding method. You can come up with a padding method that will literally produce any message you want (an easy way is to add a constant xor operation beforehand, though this is stretching the definition of "padding method").
However, in practice, there are only a handful of block cipher padding methods used in the real world, and they are easy to recognize - bit padding, which consists of adding a "1" bit (usually, a 0x80
byte for byte-oriented implementations) and padding with zero bits, PKCS #7, which adds N bytes of value N where N is the number of padding bytes required (from 1 to a whole block's worth, up to a maximum of 255 bytes), X.923 byte padding, and a few variants.
If you know features of your plaintext, it gets even easier, as you might be able to work out the end of the plaintext without needing to consult the padding. For instance, the plaintext could have a length record at the start indicating how long it is, in which case you can just read that and skip the padding entirely (assuming it is a standard padding method, of course). It might include a terminating character or symbol, the last block might not matter (if it carries redundancy data), etc, etc...
Or you can just try each one and see if what you get makes sense. That works, too.
This is assuming you only have the ciphertext, the ability to decrypt it (but not strip off the padding), and no metadata. Usually implementations will either hardcode the padding method used in their software (meaning if you know where your ciphertext comes from, you can look up the padding method there) or output it along with the ciphertext and IV in order to allow the receiver to actually decrypt the message properly, in which case it is given to you.
And, of course, if you have only the ciphertext and not even the IV or decryption key, then the answer is, of course, that you cannot know. Because if you could, then it would mean that features of the plaintext are not properly hidden by the encryption scheme used, meaning that scheme is (very) broken.