Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
If I encrypt a text X using key A with the AES algorithms, and then decrypt the result using key B, would the obtained plain text Y length be the same as X's? If the answer is no, is there any encryption algorithm in which this happens?
Note that I want to encrypt a plain text in a way that that if it is decrypted with the wrong key the length of the obtained plain text is the same as the original one.
The length of the decrypted bytes should always be a multiplicative of the block size, no matter if a correct key is used or not. There might of course be a situation where the decryption with the wrong key results in an output that looks like it uses a valid padding and by removing the padding the length is unequal to the original length. But that certainly isn't the usual case.
It depends on the mode of operation and the padding method (if used).
CTR, OFB, and CFB modes will always produce a plaintext length after decryption that is equal to the original, even if an incorrect key or IV is used.
Authenticated encryption modes are specified to return no plaintext if the key is incorrect or the ciphertext has been tampered with.
For other modes that require padding (CBC, PCBC, ABC, etc), the implementation can produce results that are unexpected if not coded properly. The unpadding algorithm may be separate from the cipher, and may not have knowledge of the block size of the cipher, and allow removing 240 bytes of padding, even though the block size for AES is only 16 bytes. This may be incorrect to you, but not to the code. It also depends on the padding method used, and if the unpad code explicitly checks for correctness of the padding bytes before removing them.
ISO/IEC padding starts at the end and goes backwards till it finds a 1 bit, then removes that and the 0 bits at the end. An incorrect key will probably result in a longer decrypted plaintext using the wrong key than the original.
ANSI and PKCS padding uses the final byte as the amount of bytes to truncate, but are specified differently as to the content of the other padding bytes. Implementations may not even look at those other bytes, and only read the final byte for the padding byte count, which can have a value of 0 to 255, most likely resulting in a shorter decrypted plaintext using the wrong key than the original. It is improbable the rest of the padding bytes will match the padding mode specification, and if they are checked, the unpad code may simply return all the plaintext.
