1

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:

  1. Encrypting fairly random (binary) data, such as IDs or even other randomly-generated keys.

  2. 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:

  1. Key-stretch the passphrase/key k using PBKDF2(SHA-512, k, salt, Niter, |M|)
  2. 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.

  • I don't know of any tool that doesn't verify its encryption in some way. It doesn't make much sense to me not to verify decryption. If you're using secure algorithms I'm not sure what the problem is. – RoraΖ Sep 26 '14 at 11:52
  • @raz: Consider storing random bytes. The problem is what happens after the attacker unlocks the random bytes. If the decryption is non-verifiable, then (m)any key unlocks any encrypted data, so attacker has no way of knowing when he actually broke it (because the plaintext/key is non-distinguishable from the random gibberish bytes). This prevents the attacker from verifying the key offline (e.g. until the decryption succeeds, using resources HE posses), and forcing him to attack on YOUR terms (with only 3 attempts) - see my example with the auto-destructing system above. – leden Sep 26 '14 at 18:12
  • If your crypto is breakable then you're already doing something wrong. I guess my point is that with strong enough encryption, the likelihood of an attacker breaking that encryption doesn't measure up to the convenience of verifying that encryption. – RoraΖ Sep 26 '14 at 18:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.