The Math That Protects Your Money: Why Encryption Is Physically Impossible to Break

Every financial transaction you make — paying with a card, logging into your bank, sending a wire transfer — rides on top of mathematics that would take longer to break than the universe has existed. Not figuratively. Literally.

When people hear "encrypted," they usually imagine a lock. And locks can be picked, given enough time and the right tools. So the mental model most people carry is: encryption is hard to break, but not impossible — and with enough computing power, a determined attacker could get through.

This mental model is wrong, and understanding why it's wrong matters. Not just for abstract reasons, but because the financial system's security depends on people making correct choices about encryption — and those choices are increasingly being made by companies, lenders, and fintech platforms that don't fully understand what they're doing.

Why Finance Runs on Encryption

Money, at its core, is information. A bank account balance is a number. A transaction is a set of numbers — amount, sender, recipient, timestamp. Credit card data is a number. Before digital finance, protecting money meant protecting physical objects. After digital finance, protecting money means protecting information.

Information, unlike physical objects, can be copied perfectly and moved at the speed of light. A thief who takes your wallet gets one wallet. A thief who intercepts unencrypted financial data in transit gets a perfect copy of every byte — while the original arrives at its destination looking untouched. You won't know anything was taken.

This is why encryption isn't optional in financial systems. It's not a feature. It's the precondition for digital money existing at all.

Where encryption operates in finance:

• TLS (Transport Layer Security) — encrypts data in transit between your browser and a bank's servers. That padlock in your address bar. Without it, anyone between you and your bank on the network path could read your session.
• AES encryption of stored data — your bank's database of account numbers, balances, and transaction history is encrypted at rest. If an attacker obtains the database file, they get ciphertext without the keys.
• End-to-end payment encryption — card transactions are encrypted at the point of swipe, decrypted only at the processor, encrypted again in storage. The merchant never sees your actual card number in a compliant system.
• PKI and digital signatures — public key infrastructure authenticates the parties in any transaction, ensuring you're actually talking to your bank and not a convincing imitation.
• Hardware Security Modules (HSMs) — physical tamper-resistant devices that store the master keys. Major financial institutions keep their most sensitive key material in hardware that physically destroys itself if opened.

All of this depends on one foundational property: that the encryption cannot be reversed without the key in any practical timeframe. Understanding why that property holds requires understanding what a key actually is.

What a Key Actually Is

Encryption transforms readable data (plaintext) into scrambled data (ciphertext) using an algorithm and a key. The key is a number — a large, randomly generated number that controls exactly how the transformation works. Decryption reverses the process, but only if you have the key.

The key is not a password. A password is typically a short sequence of human-readable characters. A cryptographic key is a random string of binary digits — ones and zeros — generated by a hardware random number generator designed to produce values that are genuinely unpredictable.

The security of modern encryption rests entirely on the key remaining secret. The algorithm itself — AES, RSA, ChaCha20 — is public. Security researchers, academics, and attackers all know how these algorithms work. The assumption in modern cryptographic design is that the algorithm itself is known to the adversary. Security comes only from the key.

This design principle — "security through obscurity is not security" — means there's no magic to hide. The protection is purely mathematical: even knowing the algorithm in full detail, an attacker without the key must either guess it or find a weakness in the math.

Key sizes are measured in bits. A 128-bit key is a number between 0 and 2^128 − 1. A 256-bit key is a number between 0 and 2^256 − 1.

The question of whether encryption is "strong" is fundamentally a question of how many possible keys exist and how hard it is to try them.

The Scale of the Numbers

This is where most explanations fail, because the numbers involved are so large they stop feeling real. Resist that impulse. The numbers are real, and the scale is the point.

AES-128 uses a 128-bit key. The number of possible keys is 2^128.

Write that out: 340,282,366,920,938,463,463,374,607,431,768,211,456.

Three hundred forty undecillion. Let's compare that to some more intuitive quantities:

• The number of grains of sand on all of Earth's beaches is estimated at about 7.5 × 10^18 — 7.5 quintillion. The AES-128 key space is about 45 billion times larger than all the grains of sand on Earth.
• Your odds of winning the Powerball lottery are 1 in 292 million. The odds of guessing a random AES-128 key correctly on the first try are roughly the same as winning Powerball 15 times in a row.
• The odds of being struck by lightning in any given year are approximately 1 in 1.2 million. Randomly guessing a correct AES-128 key is like being struck by lightning and simultaneously winning the Powerball. Twenty times. While being struck by lightning again.

Even at the speed of modern computing: the fastest supercomputers on Earth can perform around 10^18 operations per second. If every supercomputer ever built were assigned to guess AES-128 keys, operating continuously since the Big Bang (13.8 billion years ago), they would have checked approximately 10^45 keys. The AES-128 keyspace has 3.4 × 10^38 keys. Wait — 10^45 is actually larger than 3.4 × 10^38.

That means AES-128 is theoretically exhaustible with enough supercomputers over cosmological timescales. It's the reason AES-256 exists.

AES-256 uses a 256-bit key. The number of possible keys is 2^256.

This number is approximately 10^77 — seventy-seven zeros. The number of atoms in the entire observable universe is estimated at approximately 10^80. The AES-256 key space contains a number of possible keys within three orders of magnitude of the number of atoms in all the stars, planets, and gas clouds that have ever existed.

Put differently: if you could label every atom in the observable universe with a unique AES-256 key, you'd run out of atoms before you covered one-tenth of one percent of the possible keys.

Thermodynamically Impossible

Here is where the argument moves from "practically infeasible" to "physically impossible."

In 1961, physicist Rolf Landauer established a principle now bearing his name: any logically irreversible computation — including flipping a bit — requires a minimum amount of energy, regardless of how efficient the hardware is. At room temperature (around 300 Kelvin), the Landauer minimum is approximately 3 × 10^−21 joules per bit operation.

This isn't a hardware limitation. It's a consequence of thermodynamics — the same physics that says heat flows from hot to cold and perpetual motion machines can't exist. No computer, no matter how advanced, can perform a bit operation using less than this energy. This is the floor.

Now apply it to AES-256.

To try every possible key — 2^256 keys — would require at minimum 2^256 bit operations. At the Landauer minimum, that's:

2^256 × 3 × 10^−21 joules ≈ 3.5 × 10^56 joules of energy.

The Sun outputs 3.8 × 10^26 watts. Over its entire remaining lifetime — roughly 5 billion years — the Sun will produce approximately 6 × 10^43 joules of energy in total.

To brute-force AES-256 at perfect thermodynamic efficiency would require roughly 3 trillion times the Sun's total remaining lifetime energy output.

This is not a matter of waiting long enough or building better computers. You cannot build a computer that violates the Landauer limit any more than you can build a machine that violates the conservation of energy. The mathematics of AES-256 doesn't create a hard problem — it creates a problem that the laws of physics themselves prohibit solving by exhaustion.

This is what "thermodynamically impossible" means, and this is why the term "unbreakable," when applied to properly implemented 256-bit encryption, isn't marketing language. It's a statement about physics.

RSA Is Different — and Why That Matters

AES is a symmetric cipher — the same key encrypts and decrypts. It's fast, efficient, and used for bulk data: the contents of your bank database, the payload of a TLS session, the data on your laptop's encrypted drive.

RSA works differently. It uses a pair of keys — a public key and a private key — that are mathematically related but cannot be practically derived from each other. Anything encrypted with the public key can only be decrypted by the private key, and vice versa. You can publish your public key to the world; only you can decrypt what's sent to you.

RSA's security rests not on the size of a key space but on the computational difficulty of factoring large numbers — specifically, the difficulty of taking a number that is the product of two large primes and finding what those primes were.

Multiplying two 1,000-digit primes together takes a computer a fraction of a second. Factoring the result back into its components takes, with the best known algorithms, an astronomically long time. The security of RSA is the asymmetry between multiplication (easy) and factoring (hard).

RSA key sizes are measured in bits, but they don't compare directly to symmetric key sizes. An RSA-2048 key (2,048 bits) is considered roughly equivalent in security to an AES-112 key. RSA-4096 is roughly equivalent to AES-140.

The disparity between RSA and AES key sizes is not intuitive. A 2,048-bit RSA key sounds much larger than a 128-bit AES key, but provides less effective security. This surprises people and leads to misconfigured systems.

Common Misconceptions

"If a computer is fast enough, it can break encryption."

Speed helps when the key space is exhaustible. Increasing computing speed by a factor of a million still doesn't help against AES-256, because the key space doesn't shrink — you're still trying to enumerate 10^77 possibilities with a million-times-faster computer. You've changed your impossible task by a factor of a million. It's still impossible.

"Quantum computers will break all encryption."

Grover's algorithm, run on a sufficiently powerful quantum computer, can reduce the effective security of a symmetric cipher by half — turning AES-256's 256-bit security into 128-bit security. This is why cryptographers recommend AES-256 rather than AES-128 for post-quantum readiness. AES-256 survives a quantum attack. AES-128 might not.

Shor's algorithm, however, can efficiently factor large numbers — which means it can break RSA. This is the genuine quantum threat to current cryptography, and the reason the National Institute of Standards and Technology (NIST) finalized a suite of post-quantum cryptographic standards in 2024. The transition away from RSA is already underway in security-forward financial systems.

"End-to-end encryption means no one can intercept my data."

It means no one can read intercepted ciphertext without the key. It says nothing about what happens at the endpoints — the devices where data is decrypted to be used. Malware on your device that reads the screen or logs keystrokes bypasses the encryption entirely. The protection is in transit and at rest, not at the point of use.

"If they used 'military-grade encryption,' it's secure."

This is a marketing phrase. "Military-grade" most commonly refers to AES-256, which is indeed used by US government systems for classified data. But the phrase says nothing about implementation — key management, certificate validation, software vulnerabilities, human error. Every major financial data breach in recent years has involved failures of implementation or key management, not failures of the underlying cryptographic math. The math is sound. The engineering around it is where things go wrong.

Where Encryption Fails in Practice

The unbreakability of well-implemented encryption shifts the attack surface to everything surrounding it.

Key management is where most failures occur. A key that is stored unencrypted, transmitted insecurely, or used beyond its intended lifetime can be compromised without breaking the cipher. Financial institutions that encrypt data at rest but store the encryption keys in the same database have defeated the purpose entirely.

Certificate authorities validate the public keys in TLS. If a certificate authority is compromised or issues fraudulent certificates, an attacker can intercept encrypted traffic by presenting a valid-looking certificate. This is why certificate transparency logs, certificate pinning, and CA selection matter.

Implementation bugs — the OpenSSL Heartbleed vulnerability in 2014 exposed private keys in the memory of affected servers, not because anyone broke AES but because a boundary check was missing. The encryption was perfect. The code around it was not.

Social engineering and credential theft are the most efficient attacks. You don't break AES-256 by trying all 10^77 keys. You call an employee, claim to be from IT, and ask them to reset their password. The math holds. Human behavior doesn't always.

The financial industry's encryption is, in the aggregate, sound. The incidents that make headlines are almost always one of these surrounding failures — not a cryptographic break.

Why This Matters for Borrowers and Lenders

For borrowers: when you submit financial information online — a loan application, banking credentials, credit data — the first question to ask is not "is this site encrypted?" but "what are they doing with my data after it arrives?" Encryption protects data in transit. It says nothing about who has access to it once decrypted, how long it's retained, or who it's sold to. The lock on the door matters. So does who has the key inside.

For lenders and fintech platforms: the minimum bar is not optional. TLS 1.3. AES-256 for data at rest. RSA-4096 or elliptic curve equivalents for key exchange. Hardware security modules for key storage. And annual audits of implementation — not just configuration, but the human and procedural elements around the cryptography.

The math is the easy part. Every financial platform has access to the same cryptographic primitives. What differentiates them is whether they implement those primitives correctly and build responsible data practices around them.

Encryption is a necessary condition for financial security. It is not sufficient.

Sources

1. AES (Advanced Encryption Standard) — NIST FIPS PUB 197 (2001); csrc.nist.gov; 128-bit and 256-bit key sizes
2. Rolf Landauer, Landauer Limit — Landauer, R., "Irreversibility and Heat Generation in the Computing Process", IBM Journal of Research and Development, Vol. 5, No. 3 (1961), pp. 183–191; minimum energy per bit operation ~3 × 10^−21 joules at 300 K
3. RSA-AES key equivalence (RSA-2048 ≈ AES-112 bits security): NIST Special Publication 800-57 Part 1 Rev. 5, Recommendation for Key Management (2020) — csrc.nist.gov
4. Grover's algorithm (quantum speedup on symmetric ciphers — halves effective key length): Lov Grover, "A Fast Quantum Mechanical Algorithm for Database Search", Proceedings of STOC (1996)
5. Shor's algorithm (efficient quantum factoring of RSA): Peter W. Shor, "Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer", SIAM Journal on Computing, Vol. 26, No. 5 (1997)
6. NIST post-quantum cryptography standards (finalized 2024) — FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA): csrc.nist.gov
7. OpenSSL Heartbleed vulnerability (2014) — CVE-2014-0160; buffer over-read in TLS heartbeat extension exposing private key material from server memory