HN Debrief

LLMs won't break symmetric crypto

  • AI
  • Security
  • Cryptography
  • Infrastructure

The post’s claim is narrow: large language models are not about to break mainstream symmetric cryptography such as AES or SHA-2. The core reason, as commenters framed it, is that symmetric crypto does not rest on one elegant mathematical assumption the way RSA, Diffie-Hellman, or elliptic-curve systems do. Modern block ciphers and hashes are built to destroy exploitable structure through repeated mixing and nonlinear steps. If there is no hidden shortcut, the remaining attack is brute force, and that just scales with key size.

If you use mature symmetric primitives, the bigger near-term AI risk is not a magical break of AES. It is AI making implementation flaws, bad randomness, and weak custom designs much easier to find and exploit, so the practical move is to avoid bespoke crypto and harden the surrounding system.

Discussion mood

Mostly confident and mildly dismissive of the idea that LLMs will crack AES-class symmetric crypto anytime soon. The confidence came from the long track record of failed attacks on mainstream ciphers and from the view that AI is more likely to uncover implementation bugs or weak bespoke designs than a deep structural break in battle-tested primitives.

Key insights

  1. 01

    AI is already useful on crypto plumbing

    The near-term win is not breaking AES. It is catching the dumb but catastrophic mistakes around it, like broken release builds, bad randomness, and library bugs that humans missed for years. That shifts AI from a speculative cryptanalysis tool to a very real auditing tool for wallets, ZK code, and security-critical glue code.

    Put AI-assisted review on cryptographic implementations, build pipelines, and randomness handling now. If you run custom security code, assume cheap automated scrutiny is coming before any breakthrough against the underlying cipher.

      Attribution:
    • dboreham #1
    • modeless #1
    • krupan #1
  2. 02

    Symmetric and asymmetric crypto face different failure modes

    AES and SHA-2 are not hanging off a single unsettled math problem in the way factoring, discrete log, or elliptic-curve discrete log are. Their design goal is the opposite. They try to avoid clean algebraic structure so attackers cannot reduce the problem to a neat theorem or shortcut. That makes “AI helps math, math breaks crypto” much more relevant to RSA and ECDH than to block ciphers and hashes.

    Separate your crypto risk model by primitive. Watch AI and quantum progress most closely where your systems still depend on factoring or discrete-log assumptions, not where they rely on standard symmetric primitives.

      Attribution:
    • tptacek #1 #2 #3
  3. 03

    The historical break list for block ciphers is short

    Computer-era mainstream symmetric ciphers have a surprisingly strong record. RC4 was the recurring exception, and commenters treated its popularity as a historical accident driven by software speed and export-era browser constraints, not as evidence that block ciphers are routinely fragile. Even DES was framed less as a conceptual failure than as a design with parameters that aged badly, especially key and block size.

    Do not generalize from RC4 or MD5 to “crypto always falls eventually.” When evaluating risk, distinguish outdated or quirky legacy designs from mature modern standards that have absorbed decades of attack effort.

      Attribution:
    • cyberax #1
    • tptacek #1 #2
    • adrian_b #1
  4. 04

    Custom symmetric crypto usually fails at the margin

    What actually moves in symmetric design is the security margin. Designers choose how many rounds are enough to resist known attacks while staying fast, and that is where mistakes live. An LLM might help prove that a lightweight or homegrown cipher cut that margin too thin. That is a very different claim from saying it will suddenly find a universal shortcut through AES.

    Be especially skeptical of lightweight, niche, or performance-tuned custom ciphers. If a system depends on shaving rounds or inventing its own primitive, treat AI-assisted analysis as a real threat.

      Attribution:
    • teravor #1
    • tptacek #1
    • inigyou #1

Against the grain

  1. 01

    Unknown shortcuts remain the real wild card

    There is no proof that modern cryptosystems require the work people currently assume. Past breaks often came from better algorithms, not more compute. That means a model-driven jump in cryptanalysis cannot be dismissed just because brute force is infeasible. The strongest version of this argument is not “LLMs guess the key.” It is “LLMs help invent a better attack.”

    Avoid writing strategy that treats current hardness assumptions as settled fact. Keep migration paths open, especially for long-lived encrypted data that may outlast today’s attack model.

      Attribution:
    • PlasmaPower #1 #2
  2. 02

    A trained model on plaintext-ciphertext pairs is still imaginable

    One commenter argued that dismissing “LLMs” misses the broader point that a large non-language model could be trained directly on many plaintext-ciphertext examples to predict key bits. Others treated this as hand-waving because no architecture was offered that beats SAT solvers or decades of failed analysis. Still, it is the clearest pushback against overfitting the argument to today’s chat models.

    Do not anchor too hard on the phrase “language model.” When assessing future risk, track purpose-built ML systems for cryptanalysis separately from consumer chatbots.

      Attribution:
    • danielmarkbruce #1 #2 #3
  3. 03

    Attackers will go around the math

    For most real systems, subpoenaing a provider or hacking the endpoint is easier than breaking RSA or AES. That is a blunt reminder that cryptographic strength rarely dominates actual compromise paths once keys live in servers, browsers, HSM integrations, or user devices.

    Spend security budget in proportion to likely breach paths. Strong primitives do not compensate for weak endpoint security, provider trust, or operational key exposure.

      Attribution:
    • biosboiii #1

In plain english

AES ↩
Advanced Encryption Standard, the most widely used modern symmetric block cipher.
brute force ↩
Trying every possible key or input until the right one is found.
cryptanalysis ↩
The study of methods for breaking cryptographic systems or reducing their security.
DES ↩
Data Encryption Standard, an older symmetric block cipher now obsolete mainly because its key size is too small.
Diffie-Hellman ↩
A method for two parties to agree on a shared secret over a public channel, usually based on hard math problems.
ECDH ↩
Elliptic Curve Diffie-Hellman, a version of Diffie-Hellman that uses elliptic curves for key exchange.
elliptic-curve discrete log ↩
The problem of recovering a secret number from elliptic curve operations, assumed hard and used in public-key cryptography.
HSM ↩
Hardware security module, a dedicated device for generating, storing, and using cryptographic keys more safely.
LLM ↩
Large language model, a type of AI system trained on huge text datasets to generate and analyze language.
RC4 ↩
An old stream cipher once widely used on the web that was later found to have serious weaknesses.
RSA ↩
A widely used public-key cryptosystem whose security is tied to the difficulty of factoring large numbers.
security margin ↩
The extra safety built into a cryptographic design, often by adding more rounds than the minimum thought necessary.
SHA-2 ↩
Secure Hash Algorithm 2, a family of cryptographic hash functions used to verify data integrity.
symmetric cryptography ↩
Encryption where the same secret key is used to encrypt and decrypt data.
ZK ↩
Zero-knowledge, a class of cryptographic techniques that let one party prove something without revealing the underlying secret.

Reference links

Reference and background

  • RSA Factoring Challenge
    Mentioned as a reminder that public prize incentives for breaking hard crypto-related math did not suddenly become easier in the LLM era.
  • Integer factorization
    Linked to support the point that factoring hardness is still an open algorithmic question rather than a proved limit.

Media reference