Is there such a cryptographic algorithm?

Question

Is there such a cryptographic algorithm that will encrypt any file with a password. But when decrypting, if the password is incorrect, the file will be decrypted, but instead of relevant data there will be "garbage". It is important to note that I'm not talking about the ability to generate a file with garbage if the password is incorrect. I mean, that would be as if built into the algorithm itself. Is there something similar that I described? And if not, which way can I dig?

Answer 1

Standard cryptographic algorithms will do this. If you use the wrong key in a standard symmetric cipher (like AES) it will decrypt the data into a random series of bytes that will look like nonsensical garbage with overwhelming probability.

A symmetric encryption/decryption function is best thought of as a pseudorandom permutation. For any given key K and any fixed block-sized input (typically block size like 128-bits or 256 bits), your Encrypt function will map each n-bit block to another n-bit block and the Decrypt function will do the reverse mapping. For a slightly different key, you'll get a completely different mapping.

That said, this inherent property is usually undesired.

So often times there's an extra check to ensure the key was correct (and if not indicate that decryption failed) -- that is they'll either make sure the padding is valid (which should rarely happen for an incorrect key -- though this will occassionally happen) or they'll check against a Message Authentication Code that verifies the key was valid.

Answer 2

Is there such a cryptographic algorithm that will encrypt any file with a password.

Cryptographic algorithms use keys, not passwords and using a password directly is not secure. The cryptographic keys are hard to remember so we use Password-Based Key Derivation Functions like PBKDF2, Scrypt, and Argon2. Better to use the last two.

The key size is determined by the algorithm like AES is a 128-bit block cipher with 128,192 and 256 bits. The key derivation algorithm will produce according to your key size. If you are fear from a possible quantum attack choose 256-bit key and be safe from Grover's algorithm.

When using passwords use passwords with high entropy like diceware. This will protect you against brute-force attacks, too.

For the Cryptographic algorithm and modes see below.

But when decrypting, if the password is incorrect, the file will be decrypted, but instead of relevant data there will be "garbage". It is important to note that I'm not talking about the ability to generate a file with garbage if the password is incorrect. I mean, that would be as if built into the algorithm itself. Is there something similar that I described? And if not, which way can I dig?

The AES is expected to be pseudorandom permutation (PRP) an incorrect key will generate all but the correct message. This means that some of the incorrect keys will include meaningful messages. If you consider that a ciphertext will map to all possible plaintext that will contain all meaningful text in any language. The longer the message (i.e.) more than one block, the harder the incorrect key will produce meaningful results.

We don't expect that a slight change in the key will result similar messages for any Cryptographicall secure cipher.

You have various options to encrypt with AES;

• ECB: One should not mention using the ECB mode at all, it is insecure since it leaks patterns and not probabilistic encryption. Some even don't call it a mode of operation

• CBC is a probabilistic encryption mode that has semantic security that requires an unpredictable nonce. Also, for CBC mode you will need to use a padding mechanism like PKCS#7 so that your messages will be multiple of the block size of the block cipher. This can lead to padding oracle attacks that are not relevant with file encryption at all. But, if you use CBC, an attacker who tries to brute-force your passwords, can check the padding to determine that the message is correct one. A similar one used in RSA DES challenges.

• CTR is also a probabilistic encryption mode more specifically CTR turns a block cipher into a stream cipher. CTR mode doesn't require padding at all. For the security of CTR mode, the IV should never be reused with the same key.

The above modes are archaic and we have better modes like Authenticated Encryption (AE) mode with some other ciphers. You should use these;

• GCM mode is defined for a cipher with 128 bits block size like AES. It is called AES-GCM and that uses AES in CTR mode for confidentiality. GCM mode also provides integrity and authentication. Never use the same IV under the same key with GCM mode. The results can be catastrophic; 1) an attacker use crib dragging to break the confidentiality 2) this can lead forgeries.

• Poly1305 is another AE mode that used with ChaCha20 stream cipher and named as ChaCha20-Poly1305.

The last two modes exist in TLS 1.3's 5 available modes.

- TLS_AES_256_GCM_SHA384
- TLS_CHACHA20_POLY1305_SHA256
- TLS_AES_128_GCM_SHA256
- TLS_AES_128_CCM_8_SHA256
- TLS_AES_128_CCM_SHA256

With the integrity and authentication, one can detect the tamper with your files.

---

One Time Pad (OTP): One-time pad is not practical and it is not useful if you are encrypting your files. It can be useful if you're communicating since it provides information-theoretic security. OTP requires key size as long as the message size and that requires presharing the OPT keystream, we prefer computationally secure.