From what I observed using standard encryption tools such as OpenSSH and GPG, the decryption only succeeds when the correct password/key is provided (or at most a few others, in case of collision).
(I also verified this by decryptin a single-letter message and trying to decrypt with millions of random passwords.)
However, this is totally undesirable in the following cases:
Encrypting fairly random (binary) data, such as IDs or even other randomly-generated keys.
Multiple layer encryption (using different algorithms)
The former is a problem because a successful encryption by any means (extreme luck, systematic or brute-force attack) gives the immediate feedback/validation to the attacker - "aaah.. that's the secret that is protected". Conversely, if the attacker never knows whether the decrypted data is meaningful or not, he would be greatly disabled; e.g., consider a leakage of an encrypted, randomly-generated, password to the system/machine which launches autodestruct sequence after a few unsuccessful login attempts (such an encrypted password is of no value to the attacker, but extremely valuable to the legitimate user who might forget it at any time).
In case of a brute force attack, the latter basically weakens the whole encryption from exponentially safe to as safe as the strongest link,
because the attacker has a checkpoint after each broken layer. Thus, breaking effort (
E) is equal to
E(algo_1) + ... + E(algo_n) instead of
E(algo_1) * ... * E(algo_n).
I am not sure whether this decryption behavior is caused by the tools (perhaps they encrypt additional metadata to easily check whether decryption succeeded), or the algorithms themselves (I tested with a few, including AES256). Is there a way to use a well-established algorithm such as AES256 in a way which would not validate every encryption attempt (i.e. the tool should not be able to tell whether it decrypted correctly/incorrectly)?
If not, I have been thinking of the following:
- Key-stretch the passphrase/key k using PBKDF2(SHA-512, k, salt, Niter, |M|)
- Apply the One Time Pad encryption to the whole message M (now that the key is of equal length)
However, it suffers from the vulnerability that the ciphertext and plaintext lengths are equal. Is there a better alternative?
Note: To be truly concealing, specific metadata of the encryptioned message should also be stripped off, but this is only a minor problem compared to the one outlined above (e.g. for GnuPG, one could strip off the leading bytes "8C 0D 04"), so please don't focus too much on this one.