Real-world decryption
When decryption is both easy and hard
Data is encrypted with symmetric ciphers like AES-GCM or ChaCha20-Poly1305 in TLS, IPsec, SSH; AES-XTS in BitLocker, FileVault, LUKS; the ChaCha12-based Adiantum in legacy Android devices. Over-the-air 5G uses AES-CTR or ZUC or SNOW. These ciphers are secure and will (in my opinion) stay secure. They're also immune to quantum algorithms. Even legacy ciphers like 3DES and RC4 aren’t that unsafe, in most use cases.
There are very few cases of systems compromised due to a cryptographically weak cipher.
Even theoretical weakness is often insufficient to compromise a system.
Theory
Given a secret key, a cipher transforms plaintext data into ciphertext—the encrypted message that looks like random bits. Breaking a cipher usually means retrieving the plaintext from ciphertext, via plaintext-recovery attacks. If you know the secret key, then you can directly compute plaintext from any ciphertext. Therefore, key-recovery attacks are even more powerful.
Symmetric ciphers (whether they support authentication or not) are designed to stay secure even if the attacker
Knows the cipher algorithm and its implementation.
Possesses enormous compute and storage capabilities.
Obtains a gigantic list of plaintext–ciphertext pairs.
Can choose plaintext data and obtain its ciphertext, via an “encryption oracle.”
Ciphers are also designed such that “decryption oracle” wouldn’t help an attacker in finding the secret key—but obviously they could decrypt any message. Decryption oracles that tell if a ciphertext is valid may also be exploited, as padding oracle attacks showed.
Practice
A system may still satisfy operational security goals even if the cipher is weak, and in unusual cases even if the attacker knows the key. That’s because security goals can be less simple than “prevent an attacker from recovering, by all means necessary, the plaintext at any times.” These are examples I’ve encountered:
Unknown plaintext format: Imagine you use AES-CTR with a key a 32-bit rather 128-bit, but you have no signal on the plaintext format. For all you know, it may be random-looking bytes. For a single (unauthenticated) ciphertext, every candidate key thus produces an equally plausible candidate plaintext. Ironically, you thus need some prior information about the payload in order to fully recover it.
Unknown cipher: What if you don’t know the cipher used? If you know it’s some open standard you may “brute force” the ciphers—there aren’t thousands of them. But what if it’s a secret, proprietary cipher? Reverse engineer it from the software/hardware you have? If it runs on an FPGA or ASIC, you may be able to use it in your attack (brute force or other), but if you’ve just a handful of devices then you can’t parallelize the attack. And if you can’t emulate or execute the cipher at all, then even the secret key doesn’t help.
Ticking clock: Imagine you’re dealing with a weak cipher—either its key is short and bruteforceable (and/or breakable via time-memory trade-offs like rainbow tables), or you have a cryptanalytic way to recover the cipher or the key. But you may have to deadlines:
The limited time in which to carry out the attack, for example due to a cryptoperiod or because you have limited access to the system you’re attacking. It could be hours, or just seconds. You may also not be able to run CPU- or memory-intensive processes.
The secret lifetime: the plaintext information becomes worthless after a certain amount of time (and/or becomes public after a certain time.)
These are examples of operational constraints that make it harder to break a cipher, even when it’s breakable in theory. The other way, secure ciphers don’t protect against exposed keys, reused nonces, implementation bugs, protocol flaws, or compromised endpoints.
Featured image: Gustave Doré, L’Énigme (detail)