Can encrypted data be hacked? How encryption really fails

Yes, but rarely by breaking the encryption itself. Modern algorithms such as AES-256 and properly sized RSA or elliptic-curve keys have no known practical attack. Real breaches happen because keys are stolen, data is grabbed before it is encrypted or after it is decrypted, implementations have bugs, or the password protecting a key is weak. Knowing which route applies tells you where to spend your security effort.

Five ways encrypted data gets exposed

Breaking the maths: brute force

A 128-bit AES key has 2 to the power 128 possible values. Trying them all is beyond any computer that exists or is on the horizon, and a 256-bit key adds an enormous margin on top; our guide on whether AES-128 is still secure works through the numbers. So the honest answer to "can you decrypt AES-256?" is no, not without the key.

Brute force succeeds only against keys that are too short or algorithms that are too old. DES, with its 56-bit key, was withdrawn by NIST in 2005, years after searching every key had become practical. RSA is the interesting case, because factoring keeps improving. In September 2026 an 862-bit RSA challenge number was factored using about 4,900 GPU-days of computing, which the researcher put at about $400,000 at market prices, and an 896-bit one fell about two weeks later. The researcher behind the first record estimated that a 1,024-bit key would now cost roughly $30 million to factor, while 2,048-bit keys remain about a billion times harder and effectively unaffected (Eric Lu). Anything still using 1,024-bit RSA should be replaced.

Guessing the password behind a key

Many things described as encrypted, such as password-protected PDFs, ZIP files, phone backups and password managers, derive their key from a password. An attacker who gets the file doesn't attack AES at all; they guess passwords offline and try each one. A strong cipher behind a weak password is a weak system.

The defences are long passphrases and slow key derivation, which makes every guess expensive; our guide to password hashing explains how the same techniques protect login databases. Phones add hardware on top. Apple, for example, entangles the passcode with a key built into the device, so guesses must run on the phone itself, and calibrates each attempt to take about 80 milliseconds.

Stealing the key

If an attacker has the key, the strength of the algorithm is irrelevant. Keys leak in ordinary ways:

• hard-coded in a mobile app or website JavaScript, where anyone who unpacks the code can find them;
  
  
• committed to a code repository, copied into logs, or included in backups;
  
  
• stored on the same server, or in the same database, as the data they protect;
  
  
• held by insiders, including former staff whose access was never removed.
  
  

Software bugs can hand keys over too. Heartbleed, disclosed in April 2014, was a flaw in OpenSSL's heartbeat feature that let anyone read chunks of a server's memory; the researchers who found it were able to extract their own servers' private keys (heartbleed.com). The defence is disciplined key management: keys in a key-management service or hardware module, used by as few systems as possible, logged, and rotated so that one leak doesn't expose everything.

Attacking before encryption or after decryption

Data has to be decrypted to be used, and the devices where that happens are usually easier to attack than the cipher. Malware, keyloggers, malicious browser extensions and screen-capture tools all work on data in its plain form. End-to-end encrypted messages, for instance, are readable on the phones at each end, and spyware on either phone reads them there.

Can an encrypted phone be hacked?

Phone encryption is strongest when the phone is switched off or has just restarted. Once you unlock it, the operating system decrypts data for apps. On Android, credential-encrypted storage becomes available after you unlock the device, and on iPhones most third-party app data uses a protection class whose key stays in memory from the first unlock until the phone restarts (Apple Platform Security). So a lost phone that is switched off is well protected, while a running, unlocked phone with malware on it is not. Use a strong passcode, install updates promptly and avoid apps from unknown sources.

The same principle applies to paid video. Once a player decrypts a lecture, it is pixels on a screen, which is why our guides on what decryption is and why DRM alone can't stop piracy focus on what happens after decryption.

Exploiting implementation bugs

Sound algorithms are regularly undermined by the code around them. These well-documented cases each broke encryption without breaking its maths:

The lesson for any team is the same: use well-maintained cryptographic libraries and platform defaults, patch quickly, never write your own cipher code, and retire old protocols and key sizes on schedule.

Can AI or quantum computers break encryption?

AI

There is no public evidence that AI can break AES or factor 2,048-bit RSA keys. The September 2026 factoring records are a useful illustration: AI coding agents did much of the engineering, porting and tuning factoring software for GPUs, but the maths was the same general number field sieve, and both researchers said 2,048-bit RSA is unaffected. AI's real effect is on the other routes in this article. It helps attackers write tools faster, craft more convincing phishing messages and hunt for bugs, which makes patching, multi-factor login and strong passwords more important, not less.

Quantum computers

A large, error-corrected quantum computer running Shor's algorithm would break RSA and elliptic-curve cryptography. Estimates of the machine needed keep shrinking, though nothing close has been built. Symmetric encryption such as AES with 128-bit or longer keys is expected to stay safe. The risk today is "harvest now, decrypt later", where recorded traffic is stored until such a machine exists, which is why browsers already add post-quantum key exchange. See post-quantum cryptography for the timeline.

What this means for video protection

Paid lectures are usually encrypted in transit and at rest, and nobody pirating them breaks AES. They take one of the other routes in this article instead:

• A copied key or playback link. If keys or licences go to anyone who replays a copied request, the encryption adds little.
  
  
• A modified app, rooted phone or emulator. These let an attacker watch an app while it decrypts, or switch its protections off.
  
  
• Screen recording or a second phone. Once a lecture is decrypted, it is pictures and sound, and no cipher protects those.
  
  
• One paid account shared by a group. A shared login decrypts the lecture exactly as the paying student would.
  
  

So when a platform says its lectures are "AES-256 encrypted", ask what happens after decryption: which of these routes it covers, what happens on rooted phones and in desktop browsers, and whether a copy that leaks anyway can be traced back to the account it came from. Our guides to dynamic watermarking and stopping account sharing look at two of those gaps.

Key takeaways

• Properly used modern encryption isn't broken by brute force; AES-256 can't be decrypted without the key.
  
  
• Real failures come from weak passwords, stolen keys, attacks on devices before encryption or after decryption, and implementation bugs.
  
  
• Short keys are the exception: 1,024-bit RSA is now within reach of well-funded attackers.
  
  
• AI mainly speeds up the attacks around encryption; quantum computers threaten RSA and ECC, not AES.
  
  
• For video, the realistic threats are copied keys, tampered apps, recordings and shared accounts, so controls must cover all four.
  
  

VidSafe protects coaching institutes' lectures with VidSafe proprietary encryption, screen- and camera-recording detection, account-sharing prevention, PDF watermarking, RASP, and visible and invisible watermarks that are extremely hard to remove, even after heavy re-encoding.

Frequently asked questions

Can encryption be broken?

Modern encryption used correctly has not been broken in practice: there is no known way to recover AES keys or to factor 2,048-bit RSA keys with today's computers. Encryption fails through other routes: weak passwords, stolen or leaked keys, bugs in software, outdated algorithms such as DES or 1,024-bit RSA, and attacks on devices where data is already decrypted. Fixing those is where security effort pays off.

Can AI break encryption?

Not directly. No AI system has been shown to break AES or to factor RSA keys of the sizes recommended today. AI coding agents have helped researchers engineer faster factoring runs, but on numbers far smaller than 2,048-bit keys and without changing the underlying maths. The bigger impact is indirect: AI helps attackers write malware, phishing messages and exploits faster, so patching, multi-factor login and strong passwords matter more.

Can an encrypted phone be hacked?

Yes, while it is unlocked and running. Phone encryption protects data when the phone is off or has not been unlocked since restarting. After you unlock it, data is decrypted for apps, so malware, a malicious app, or someone using the unlocked phone can read it. Keep a strong passcode, install updates promptly and avoid apps from unknown sources.

Can you decrypt AES-256 without the key?

No. Searching all 2 to the power 256 possible keys is physically out of reach, and the best known attacks on the full cipher are barely faster than trying every key. Data encrypted with AES-256 is recovered without authorisation only through other routes: guessing the password the key was derived from, stealing the key from where it is stored or used, or capturing the data on a device after it has been decrypted.