Should AES.decrypt(ct, wrong_key) return blank or wrong result? I am trying to use AES as cipher for an application I am building. 
I am using a JavaScript library (https://code.google.com/p/crypto-js/) to perform encryption and decryption with AES. 
When I perform decryption, this happens: 

AES.decrypt(ct, right_key) == 'message decrypted !' //true

AES.decrypt(ct, wrong_key) == '' //true


The problem is that I am using this decryption in a process in which there shouldn't be any way to determine if the key was right or wrong. I would like something like this to happen: 

log(AES.decrypt(msg, wrong_key)) // 'random string fsdijw'


So that the result is 'compliant' to the expected result but it's not the expected result, and there is no way to understand if the key was right or wrong depending on the result of the decryption. 
I asked my professor and he told me that AES is probably bad implemented in that library, but he didn't understand my problem so clearly. 

I wonder if the behavior described in the first snippet of code is expected or actually AES has been bad implemented in that library. 
If it was expected, is there any other cipher algorithm that doesn't allow to understand if the key was right or wrong from the result of decryption?
AES is a block cipher and would return wrong data when a wrong key is used. It only works on a single block of data (16 bytes). The default CBC mode of operation enables you to encrypt multiple blocks of data. The padding then enables you to encrypt plaintexts of arbitrary length. The padding has to be removed somehow after the decryption.

You're seeing a blank output, because your data is short and the padding removes more bytes than necessary. Here is how the default PKCS#7 padding is implemented in CryptoJS:

unpad: function (data) {
    // Get number of padding bytes from last byte
    var nPaddingBytes = data.words[(data.sigBytes - 1) &gt;&gt;&gt; 2] &amp; 0xff;

    // Remove padding
    data.sigBytes -= nPaddingBytes;
}


So, it looks at the last byte of the decrypted byte and removes as many bytes from the ciphertext. If data.sigBytes is negative, it would handle it like 0 bytes where decrypted. If your message is longer than 255 bytes, then the decryption is guaranteed to print something, but it won't be as long as the initial plaintext. If you always want to print something then you need to decrypt without padding.

I wouldn't call this implementation wrong, because PKCS#7 padding is specified for up to 256 padding bytes, but rather data.sigBytes -= Math.min(nPaddingBytes, blocksize); would have been probably better.

Zero padding might be better suited in your case, because it's highly unlikely that a decryption with a wrong key results in a plaintext that ends with many zero bytes at the end that have to be removed. But such as padding should not be used when there is a chance that you might encrypt a plaintext which ends in 0x00 bytes.




  So that the result is 'compliant' to the expected result but it's not the expected result, and there is no way to understand if the key was right or wrong depending on the result of the decryption.


This is not generally possible with a block cipher. A decryption with wrong key can result in some arbitrary plaintext bytes that doesn't have to make up a string with valid ASCII or UTF-8 encoding and if you try to force it, you will get errors, which can be used to distinguish the correct key from a wrong key.

If you're always encoding the plaintext to Hex, then you can get away with using arbitrary keys.



Related:


Does AES specify error messages when using the wrong password to decrypt?
Is it possible to find data which makes sense when decrypted with different keys?