The Riemann Hypothesis Explained: Primes, Zeta and Cryptography

The Riemann hypothesis is the claim that every non-trivial zero of the Riemann zeta function has real part exactly 1/2. If true, it pins down how far the count of primes can stray from its average. It is still unproved, and neither a proof nor a disproof would, by itself, break RSA or elliptic curve cryptography.

This post goes one level deeper than our overview of unsolved math problems and what AI can and cannot do. We count the primes up to a million by hand and by machine, compute the first zeros of the zeta function, state the hypothesis in plain words and in Lean, and then answer the question security people actually ask: what changes for cryptography if someone proves it.

One honest note first. Safeguard builds single purpose security models, and our own benchmarks page says general purpose models beat ours on mathematics. Nothing here claims Safeguard solves mathematics problems. The numbers below come from the cited sources and from short scripts you can run yourself.

Key takeaways

• The prime number theorem, proved in 1896 by Hadamard and de la Vallée Poussin, says the number of primes up to x is roughly x divided by ln x. Up to one million there are exactly 78,498 primes.
• The logarithmic integral li(x) is a much better estimate: li(10^6) is about 78,627.5, an error of about 130. The Riemann hypothesis is equivalent to saying the error never grows faster than about √x times ln x.
• The zeta function has "trivial" zeros at −2, −4, −6 and so on, and infinitely many "non-trivial" zeros in the strip between real part 0 and 1. The first sits at 1/2 + 14.1347...i.
• Platt and Trudgian proved with rigorous interval arithmetic in 2020 that every zero up to height 3 × 10^12 lies on the line. By the standard counting formula that is roughly 12.4 trillion zeros. It is still not a proof, because infinitely many zeros lie higher up.
• RSA's security rests on the difficulty of factoring large numbers, and elliptic curve security on the difficulty of discrete logarithms. Neither assumption is the Riemann hypothesis. A proof would not hand anyone a factoring algorithm.
• Prime generation for RSA already works without the hypothesis. NIST FIPS 186-5 specifies Miller-Rabin rounds (for example 4 or 5 rounds for 1024-bit primes) and an optional Lucas test.
• Miller's 1976 deterministic primality test needs the generalised Riemann hypothesis. Rabin's randomised version (1980) and the AKS test (Annals of Mathematics, 2004) do not.
• The analogue for curves over finite fields is already a theorem (Hasse 1934, Weil in the 1940s), and it is why elliptic curve group sizes are predictable.
• Clay pays $1 million only for a solution published in a qualifying outlet, at least two years old and generally accepted. It does not accept direct submissions.
• Lean's mathlib states the hypothesis formally. No group, with or without AI, has published a proof.

A dated timeline of the hypothesis and its neighbours

Dates here were checked against the sources listed at the end. Where a source gives only a year, we give only a year.

What does the prime number theorem say?

A prime is a whole number greater than 1 with no divisors other than 1 and itself: 2, 3, 5, 7, 11 and so on. Euclid already knew there are infinitely many. The harder question is how many there are below a given size. Mathematicians write π(x) for the number of primes less than or equal to x. (This π has nothing to do with 3.14159; it is just the traditional letter.)

Gauss noticed as a young man, and said in an 1849 letter to an astronomer, that π(x) is well approximated by the logarithmic integral li(x), the area under the curve 1/ln t from 0 to x. Bombieri's official Clay problem description recounts this. The cruder, more familiar form of the same idea is that π(x) is roughly x divided by ln x, where ln is the natural logarithm.

The prime number theorem makes this precise: the ratio of π(x) to x / ln x tends to 1 as x grows. Chebyshev proved bounds of the right order in the 1850s. Hadamard and de la Vallée Poussin proved the full theorem independently in 1896, building on Riemann's approach through the zeta function.

Worked example 1: counting the primes up to a million

Here is the count, done with a plain sieve of Eratosthenes (the script is in the walkthrough below) and checked against the OEIS table of π(10^n), sequence A006880.

Read the million row:

1. The true count is 78,498.
2. The simple estimate x / ln x gives 1,000,000 / 13.8155 = 72,382. It is low by 6,116, or about 7.8 percent.
3. li(10^6) is about 78,627.5. It is high by about 130, or 0.17 percent.
4. The last column, √x times ln x, is 1,000 × 13.8155 = 13,815.5. The actual error of li is about one hundredth of that.

That last comparison is the whole point of the Riemann hypothesis. Bombieri states it directly: the hypothesis is equivalent to the claim that π(x) = li(x) + O(√x log x). In words, the error in Gauss's estimate never grows faster than a constant times the square root of x times its logarithm. The table is consistent with that, but a table can never prove it, for reasons we come to below.

Worked example 2: how many 1024-bit primes are there?

The same theorem tells a cryptographer how hard it is to find a prime. Near a number N, roughly one integer in ln N is prime.

1. A 1024-bit number is about 2^1024. Its natural logarithm is 1024 × ln 2 = 1024 × 0.6931 ≈ 709.8.
2. So about one in 710 integers of that size is prime. If you only test odd numbers, about one in 355 is.
3. The count of 1024-bit primes is about 2^1023 divided by 709.8, which is roughly 1.27 × 10^305.

This is why RSA key generation is fast and why nobody can guess your primes by listing them. The estimate needs only the prime number theorem, proved in 1896, not the Riemann hypothesis.

What is the zeta function?

For a number s with real part greater than 1, the Riemann zeta function is the infinite sum

ζ(s) = 1 + 1/2^s + 1/3^s + 1/4^s + ...

At s = 2 this is 1 + 1/4 + 1/9 + 1/16 + ..., which Euler showed equals π²/6 ≈ 1.6449. You can check that numerically with the script below: mpmath prints 1.6449340668482264365.

The Euler product: where the primes come in

Euler also found that, for real part of s greater than 1, the same function equals a product over all primes p of 1 / (1 − p^−s). Bombieri's problem description calls this the celebrated Euler product and notes its first appearance in Euler's 1748 book. The product works because every whole number factors into primes in exactly one way. Expanding each factor as a geometric series and multiplying them out produces every term 1/n^s exactly once.

That identity is the bridge. Facts about where ζ(s) is zero or large translate into facts about the primes.

Extending the function to the whole plane

The sum only converges when the real part of s is greater than 1. Riemann showed in 1859 that ζ(s) extends to every complex number except s = 1, where it has a simple pole, and that it satisfies a symmetry called the functional equation. Bombieri gives it in the symmetric form

π^(−s/2) Γ(s/2) ζ(s) = π^(−(1−s)/2) Γ((1−s)/2) ζ(1 − s)

where Γ is the gamma function, the continuous version of the factorial. The equation relates the value at s to the value at 1 − s, a mirror image across the vertical line with real part 1/2. Lean's mathlib proves an equivalent version as the theorem riemannZeta_one_sub.

Trivial and non-trivial zeros

A zero is a value of s where ζ(s) = 0. There are two kinds.

• Trivial zeros. ζ(s) is zero at s = −2, −4, −6 and every other negative even integer. They come from the gamma factor in the functional equation and are well understood. mpmath confirms ζ(−2) = 0.
• Non-trivial zeros. All other zeros lie in the "critical strip", the band of complex numbers with real part strictly between 0 and 1. There are infinitely many. Because of the functional equation and the fact that ζ takes real values on the real line, they come in symmetric sets: if 1/2 + δ + it is a zero, so are 1/2 − δ + it and their mirror images below the real axis.

The vertical line with real part exactly 1/2 is called the critical line.

Worked example 3: the first five zeros

These are the first five non-trivial zeros above the real axis, computed with mpmath's zetazero function. The first three match the values printed in mpmath's own documentation.

Every one has real part 0.5. How many such zeros are there up to height T? Riemann sketched, and it was later proved, that the number N(T) of non-trivial zeros with imaginary part between 0 and T is approximately

N(T) ≈ (T / 2π) · ln(T / 2πe) + 7/8

Bombieri quotes Riemann's version, (T/2π) log(T/2π) − T/2π, which is the same leading term. Try T = 100:

1. T / 2π = 100 / 6.2832 = 15.915.
2. T / 2πe = 15.915 / 2.71828 = 5.855, and ln 5.855 = 1.7672.
3. 15.915 × 1.7672 = 28.127, plus 0.875 gives 29.002.

There are in fact 29 non-trivial zeros with imaginary part below 100, and all 29 lie on the critical line. Plug in T = 3 × 10^12 and the same formula gives about 1.236 × 10^13, roughly 12.4 trillion zeros. Keep that number in mind for the verification section.

What exactly does the Riemann hypothesis claim?

In plain words: every non-trivial zero of the zeta function lies exactly on the vertical line with real part 1/2. None of them is even slightly to the left or right.

Clay's own summary puts it the same way: it asserts that all the "non-obvious" zeros are complex numbers with real part 1/2. Riemann himself was cautious. In Bombieri's translation, he wrote that "it is very likely that all zeros are real" (stated for his function ξ(t), whose real zeros correspond to zeros of ζ on the critical line), and added that he had set aside the search for a rigorous proof after some quick unsuccessful attempts because it was not needed for his immediate goal.

Why the position of the zeros controls the primes

Riemann's paper gives an exact formula for a weighted version of π(x) as a main term minus a sum over all non-trivial zeros ρ. Each zero contributes a wave whose size grows like x raised to the real part of ρ. If every zero has real part 1/2, every wave grows like √x, and the error in the prime count stays near √x times a logarithm. If even one zero had real part 0.6, its wave would grow like x^0.6, and the primes would deviate from li(x) by far more than anyone has observed. Bombieri's phrase is that the failure of the hypothesis "would create havoc in the distribution of prime numbers".

So the hypothesis is really the statement that the primes are as regular as they could possibly be.

The generalised Riemann hypothesis

The zeta function is the simplest member of a large family called L-functions. Dirichlet L-functions, for instance, count primes in arithmetic progressions such as 4k + 1. The generalised Riemann hypothesis (GRH) says the same thing for all of them: every non-trivial zero has real part 1/2. Bombieri notes that, as of his writing, not a single case of the hypothesis is known for any L-function of this global kind. The extended version for Dirichlet L-functions is the one that matters for primality testing, as we will see.

The statement in Lean

Mathlib, the community mathematics library for the Lean proof assistant, defines the hypothesis as a proposition in the file Mathlib/NumberTheory/LSeries/RiemannZeta.lean:

def RiemannHypothesis : Prop :=
  ∀ (s : ℂ) (_ : riemannZeta s = 0) (_ : ¬∃ n : ℕ, s = -2 * (n + 1)) (_ : s ≠ 1), s.re = 1 / 2

Its doc comment notes that constructing a term of this type is worth a million dollars. Read the definition left to right: for every complex number s, if ζ(s) = 0, and s is not one of the trivial zeros −2, −4, ..., and s is not 1, then the real part of s is 1/2. The definition states the problem. It does not prove anything. Anyone claiming a machine checked proof would need to produce a term of this type that Lean's kernel accepts with no sorry placeholders.

How much has been verified numerically, and why is that not a proof?

What has been checked

Numerical verification has a long and careful history.

• Riemann himself. Bombieri notes that the first computation of the first few zeros already appears in Riemann's unpublished notes.
• 1.5 billion zeros (1986). van de Lune, te Riele and Winter showed that the first 1.5 billion zeros are simple and on the line. Bombieri explains the method: count the zeros in a rectangle with an exact contour integral, count the sign changes of a real function on the critical line, and if the two counts agree, every zero in that range is on the line.
• Far up the line. Andrew Odlyzko's tables publish the first 100,000 zeros to within 3 × 10^−9, the first 100 to over 1,000 decimal places, the first 2,001,052 zeros, and blocks of 10,000 zeros starting at zero number 10^12 + 1, 10^21 + 1 and 10^22 + 1. Bombieri reports that Odlyzko's calculations confirmed the hypothesis for over 3 × 10^8 zeros at heights up to 2 × 10^20, and that the spacing between zeros matches the statistics predicted by Montgomery and Dyson.
• Up to height 3 × 10^12 (2020). Dave Platt and Tim Trudgian verified, rigorously with interval arithmetic, that all zeros with imaginary part between 0 and 3 × 10^12 have real part 1/2. Using the counting formula above, that is about 12.4 trillion zeros. Clay's page says the hypothesis has been checked for the first 10,000,000,000,000 solutions, which is consistent with this order of magnitude.
• A positive proportion on the line. Selberg (1942) proved that a positive fraction of zeros lie on the line. Levinson pushed this past one third (1974) and Conrey past two fifths (1989). Bombieri summarises: more than 40 percent of non-trivial zeros are simple and satisfy the hypothesis.

Why trillions of checks prove nothing

There are infinitely many zeros. Checking 12 trillion of them is checking 0 percent of an infinite set. That alone would be enough, but number theory has a sharper warning.

Look again at the li(x) − π(x) column in our table. It is positive in every row. In fact li(x) overestimates π(x) for every x anyone has ever computed directly. It would be natural to conjecture that it always does. It does not. Littlewood proved that the error oscillates in both directions, by at least li(√x) · ln ln ln x according to Bombieri's description, so the sign flips infinitely often. The flips simply happen at sizes far beyond tables like ours. A pattern that holds in every row you can print is still not a theorem.

Bombieri also points out that if a counterexample to the Riemann hypothesis exists, it is expected near unusually large peaks of the zeta function on the critical line, and those peaks only occur at heights far above where the early computations stopped. So the absence of counterexamples at modest heights says less than it seems.

None of this suggests the hypothesis is false. Most experts believe it, and Bombieri lists strong structural evidence: the proved analogue for curves over finite fields, the 40 percent result, the density theorems that make off-line zeros rare, and the random matrix statistics. It is evidence. A proof is a different kind of object.

What would a proof change for RSA and elliptic curve cryptography?

This is where a lot of popular writing goes wrong, in both directions. Here is the careful version.

What RSA actually depends on

RSA picks two large random primes p and q, publishes their product n = p × q, and keeps p and q secret. Its security depends on the assumption that nobody can factor n in a reasonable time. Its correctness depends on generating real primes.

The Riemann hypothesis is a statement about how primes are distributed on average and how much they fluctuate. It does not say anything about the structure of a particular product of two primes, and it is not an algorithm. There is no known argument that a proof would yield a fast factoring method. The best known classical factoring algorithms do not assume the hypothesis, and their running times are not limited by it.

Could a future proof's techniques inspire new algorithms? Nobody can rule that out for deep new mathematics, but that is speculation, not a consequence of the statement. If someone says a proof "breaks encryption", ask which step of which algorithm it speeds up.

What prime generation depends on

Generating an RSA key needs two things the hypothesis touches only lightly:

1. Enough primes to find quickly. The prime number theorem, proved unconditionally in 1896, already guarantees about one prime in 710 near 2^1024. That is all key generation needs.
2. A reliable primality test. Standards use randomised tests whose error bounds are proved without the hypothesis.

NIST FIPS 186-5, published 3 February 2023, specifies exactly this. Appendix B.3 requires an approved probabilistic primality test, either several rounds of Miller-Rabin alone or Miller-Rabin followed by a single Lucas test. It allows optional trial division by small primes first, with a limit L between 10^3 and 10^5. Table B.1 sets the minimum rounds when generating RSA primes:

Two details in the standard are worth knowing. First, the round counts are small because a random large odd number that passes Miller-Rabin is overwhelmingly likely to be prime; FIPS 186-5 Appendix C.1 notes that for k of at least 51 bits the probability that a number surviving t rounds is composite is at most 4^−t. Second, FIPS warns that "error probability" has two meanings: the chance that a generated number is composite, and the chance that a composite survives testing. The first matters to whoever generates a key, the second to whoever validates someone else's.

None of these numbers rest on the Riemann hypothesis. A proof would not change Table B.1.

What elliptic curve cryptography depends on

Elliptic curve cryptography works in the group of points on a curve such as y² = x³ + ax + b over a finite field with p elements. Its security rests on the elliptic curve discrete logarithm problem. Again, that is not the Riemann hypothesis.

But here is the twist. There is a Riemann hypothesis that elliptic curve cryptography uses every day, and it is already proved. Bombieri's problem description explains that curves over finite fields have their own zeta functions, and the analogue of the hypothesis for them states that the zeros have a fixed absolute value. For curves of genus 1, which are elliptic curves, Hasse proved it in 1934. Weil proved it for all curves in the 1940s, and Deligne proved the general version for varieties over finite fields in 1974 and 1980.

For an elliptic curve E over a field with p elements, the consequence is Hasse's bound: the number of points #E is within 2√p of p + 1.

Worked example 4: Hasse's bound on a small curve

Take the curve y² = x³ + 2x + 3 over the integers modulo 97.

1. p = 97, so p + 1 = 98.
2. 2√97 = 2 × 9.849 = 19.70.
3. Hasse's bound says #E lies between 98 − 19.70 and 98 + 19.70, that is, between 79 and 117.
4. Counting directly (for each x from 0 to 96, count the y values that satisfy the equation, then add the point at infinity) gives #E = 100. The difference from p + 1 is 2, well inside the bound.

At cryptographic sizes, p is around 2^256, and the bound tells you the group size to within about 2^129 before you count. Curve designers still compute the exact count to make sure it has a large prime factor, but they know in advance roughly what it will be. This is a case where a proved Riemann hypothesis really is inside the cryptography. The open, classical one is not.

What would actually break RSA and elliptic curves

The real threat to both is a large, fault tolerant quantum computer running Shor's algorithm. Shor's paper, posted to arXiv on 30 August 1995, gives polynomial time quantum algorithms for factoring and discrete logarithms. That is why NIST has standardised post-quantum algorithms and published IR 8547 (initial public draft, 12 November 2024), which describes the expected transition away from quantum vulnerable algorithms. Our post on quantum computers and the post-quantum migration covers that work in detail.

Decision table: what changes, and what to do

How do primality tests depend on the Riemann hypothesis?

The Fermat test, and why it is not enough

Fermat's little theorem says that if n is prime, then a^(n−1) ≡ 1 (mod n) for every a not divisible by n. So if 2^(n−1) mod n is not 1, n is composite. The trouble is the converse fails. Some composites, called Carmichael numbers, pass for every base coprime to them. The smallest is 561 = 3 × 11 × 17, and indeed 2^560 mod 561 = 1.

Worked example 5: Miller-Rabin catches 561

Miller-Rabin strengthens Fermat by looking at the square roots along the way. FIPS 186-5 Appendix B.3.1 gives the procedure: write n − 1 = 2^a × m with m odd, compute z = b^m mod n, then square repeatedly, and declare n composite unless the sequence starts at 1 or hits n − 1 before reaching 1.

1. n − 1 = 560 = 2^4 × 35, so a = 4 and m = 35.
2. With base b = 2: z = 2^35 mod 561 = 263. That is neither 1 nor 560.
3. Square: 263² mod 561 = 166. Not 560.
4. Square: 166² mod 561 = 67. Not 560.
5. Square: 67² mod 561 = 1.

We reached 1 without passing through 560 = n − 1. That means 67 is a square root of 1 modulo 561 other than ±1, which cannot happen modulo a prime. So 561 is composite, and base 2 is a "witness". The Fermat test was fooled; Miller-Rabin was not.

Miller 1976: deterministic, if GRH holds

Gary Miller's paper, titled exactly "Riemann's hypothesis and tests for primality" (Journal of Computer and System Sciences, December 1976), showed that if the extended Riemann hypothesis holds, every composite n has a witness among the small bases, few enough that testing them all runs in polynomial time. That gives a deterministic test: try every base up to the bound, and if none is a witness, n is prime. Bombieri's Clay description lists Miller's deterministic polynomial time primality test as one of the consequences of a general Riemann hypothesis.

So here is a case where the hypothesis matters to computing: the correctness of Miller's deterministic test is conditional on GRH.

Rabin 1980: randomised, and unconditional

Michael Rabin's "Probabilistic algorithm for testing primality" (Journal of Number Theory, February 1980) took the same check and picked bases at random. The error bound for this version is proved outright; no hypothesis needed. FIPS 186-5 says its Miller-Rabin tests "are versions of a procedure due to M.O. Rabin, based in part on ideas from Gary L. Miller". This randomised form, with a DRBG choosing the bases, is what standards and libraries use.

AKS 2004: deterministic, unconditional, polynomial

In "PRIMES is in P", Manindra Agrawal, Neeraj Kayal and Nitin Saxena of IIT Kanpur gave an unconditional deterministic polynomial time algorithm that decides whether a number is prime. The Annals of Mathematics lists it as received 24 January 2002, accepted 21 March 2003, and published online in September 2004 (volume 160, pages 781 to 793). It settled a theoretical question without the Riemann hypothesis. In practice it is much slower than Miller-Rabin, so key generation does not use it.

Deterministic bases for 64-bit numbers

SymPy's documentation says its isprime is definitive below 2^64, using fixed Miller-Rabin bases "known to have no counterexamples in their range", and runs a strong BPSW test above that. That is a fact checked by computation over a finite range, not a consequence of the hypothesis.

Comparison of primality tests

Step by step: explore primes, zeros and primality tests yourself

This walkthrough reproduces every number above on a laptop. It uses only Python and OpenSSL, nothing destructive. Run it in a fresh virtual environment so you know exactly what you installed.

1. Create an isolated environment and install two libraries.

python3 -m venv rh-env
source rh-env/bin/activate
pip install mpmath sympy
pip show mpmath sympy | grep -E '^(Name|Version)'

We used mpmath 1.3.0 and SymPy 1.14.0. Record your versions; numerical results should match, but you want to know what produced them.

2. Count the primes up to a million with a sieve.

# primes.py
import math
from mpmath import li

def sieve(n):
    is_p = bytearray([1]) * (n + 1)
    is_p[0] = is_p[1] = 0
    for i in range(2, int(n ** 0.5) + 1):
        if is_p[i]:
            is_p[i*i::i] = bytearray(len(is_p[i*i::i]))
    return is_p

for x in [10**3, 10**4, 10**5, 10**6, 10**7]:
    count = sum(sieve(x))
    print(x, count, round(x / math.log(x), 1), round(float(li(x)), 1))

python primes.py
# 1000000 78498 72382.4 78627.5   (the million row)

Cross-check with SymPy's prime counting function:

python -c "from sympy import primepi; print(primepi(10**6))"
# 78498

3. Compute the first zeros of the zeta function.

python - <<'EOF'
from mpmath import mp, zetazero, zeta
mp.dps = 20
for n in range(1, 6):
    print(n, zetazero(n))
print("zeta(2) =", zeta(2))
print("zeta(-2) =", zeta(-2))
EOF

You should see 0.5 + 14.1347...i for the first zero and 1.6449... for ζ(2). mpmath's documentation shows how to confirm each value is a zero by evaluating ζ at it and getting 0.0 after rounding.

4. Estimate how many zeros lie below a height.

python - <<'EOF'
from mpmath import mpf, pi, e, log
for T in [mpf(100), mpf(3e12)]:
    print(T, (T / (2*pi)) * log(T / (2*pi*e)) + mpf(7)/8)
EOF
# 100 -> about 29.0; 3e12 -> about 1.236e13

5. Run Miller-Rabin by hand on 561.

python - <<'EOF'
n = 561
d, s = n - 1, 0
while d % 2 == 0:
    d //= 2; s += 1
z = pow(2, d, n); seq = [z]
for _ in range(s - 1):
    z = z * z % n; seq.append(z)
print(f"{n-1} = 2^{s} * {d}", seq, "Fermat:", pow(2, n - 1, n))
EOF
# 560 = 2^4 * 35 [263, 166, 67, 1] Fermat: 1

6. Use a library's primality check and prime generator.

python -c "from sympy import isprime; print(isprime(561), isprime(1000003))"
# False True

openssl prime 561
# 561 is not prime
openssl prime 1000003
# 1000003 is prime
openssl prime -generate -bits 64

The OpenSSL 3.0 manual notes that the -checks option is ignored. On macOS the bundled openssl may be LibreSSL, which also supports prime; run openssl version to see which you have.

7. Check the Lean statement, optionally. If you followed the Lean setup in our unsolved math problems post, add import Mathlib and #check RiemannHypothesis to a file in a mathlib project. Lean prints RiemannHypothesis : Prop. It typechecks because it is a statement. A proof would be a term of that type.

8. Treat the toolchain as software you ship. The libraries you just installed, and the cryptographic libraries in your applications, are open source dependencies with their own release histories. List what you actually run:

pip list --format=freeze > requirements-lock.txt
pip install pip-audit && pip-audit -r requirements-lock.txt

If you use Safeguard, safeguard scan --dir . scans the project directory and writes results as JSON under ./output. That is about the software around the maths, not the maths itself.

What does the Clay Millennium Prize require for a solution?

The Clay Mathematics Institute announced the seven Millennium Prize Problems at a meeting at the Collège de France in Paris on 24 May 2000. Its board designated a $7 million prize fund, $1 million for each problem. The Riemann hypothesis is one of the seven, and the Poincaré conjecture is the only one solved so far.

The current rules were adopted by Clay's board on 26 September 2018. The rules page is blunt about the process:

1. No direct submissions. Clay does not accept proposed solutions sent to it, and says it will not offer further guidance.
2. Publication in a qualifying outlet. The solution must appear in a qualifying outlet, as the rules define that term (section 6 of the rules).
3. Two years. At least two years must pass after publication.
4. General acceptance. The solution must have received general acceptance in the global mathematics community.

Only when all three conditions hold will Clay consider the solution. In other words, the prize follows the ordinary process of mathematics: publication, scrutiny by experts, time. A blog post, a preprint that experts have not accepted, a long chat transcript, or a computer search that finds no counterexamples does not qualify.

So check any "solved" headline against the rules: published in a qualifying outlet, two years old, generally accepted? A formal proof in Lean would be powerful evidence, since it removes doubt about the logic, but experts would still need to agree the formal statement matches the problem, and it would go through the same process.

What have AI and formal proof tools contributed so far?

This section uses only what the groups involved have published themselves. For the broader picture of AI on olympiad problems and new constructions, see our unsolved math problems post.

The statement is formalised

As shown above, mathlib contains a formal definition, RiemannHypothesis, together with a formal proof of the functional equation and related facts about the zeta function. The file is authored by David Loeffler. Having a precise, machine readable statement matters: it removes ambiguity about what a proof would have to establish, including the exclusions for trivial zeros and the pole.

The prime number theorem is being formalised with explicit error terms

The PrimeNumberTheoremAnd project, led by Alex Kontorovich with Terence Tao, aims to formalise in Lean the prime number theorem with the classical error term, along with related results such as primes in arithmetic progressions, with Chebotarev's density theorem as a stretch goal. Its README describes this goal and hosts a blueprint that breaks the work into pieces contributors can claim.

An AI agent completed the strong prime number theorem challenge, by its maker's account

Math Inc. reports that its autoformalization agent, Gauss, completed the challenge Tao and Kontorovich set in January 2024: to formalise the strong prime number theorem in Lean. Math Inc. says the work took three weeks, after the human project had announced intermediate progress in July 2025, and produced about 25,000 lines of Lean with over 1,000 theorems and definitions. It also says Gauss relied on natural language scaffolding supplied by human mathematicians and needed expert guidance. We report these as the company's own claims; we have not reviewed the proof ourselves.

Note what this is and is not. The prime number theorem is a theorem proved in 1896. Formalising it, with error terms, is hard engineering and real progress for formal mathematics. It is not progress toward proving the Riemann hypothesis, which is a much stronger statement about the error term.

A benchmark of formalised open conjectures

Google DeepMind's Formal Conjectures repository collects open conjectures whose statements, but not proofs, have been formalised in Lean with mathlib. Its README says the aim is to provide a benchmark for automated theorem provers and formalisation tools, to clarify the precise meaning of conjectures, and to encourage mathlib's growth. A paper describing it is cited in the repository as 2026 work on arXiv. A formal statement in a benchmark is a target, not a result.

What no one has published

No group, human or AI assisted, has published a proof that meets Clay's conditions, and no AI lab has claimed one in its own publications that we could find. Hold social media claims to the same standard: a checkable proof, a matching formal statement, and expert acceptance over time.

Where Safeguard fits, honestly

Safeguard does not do number theory, and its models do not prove theorems or compute zeta zeros. The honest link to this topic is the software that implements the cryptography discussed above: RSA and elliptic curve libraries, the new post-quantum libraries, and the Python and Lean toolchains people use to explore mathematics. Those are open source components with versions, advisories and fixes. Safeguard scans repositories, container images and SBOM files for those components, matches them against vulnerability databases, uses reachability analysis to show which vulnerable code paths an application actually calls, and can open fix pull requests (autonomous remediation ships switched off). It will not tell you whether your primes are prime or whether a proof is correct. It can tell you which of your projects ship a cryptographic library version with a known vulnerability.

Common mistakes

• "A proof of the Riemann hypothesis would break RSA." There is no known mechanism. RSA rests on factoring, and the hypothesis is not a factoring algorithm. The real long term threat is Shor's algorithm on a large quantum computer.
• "A disproof would make primes unpredictable and break key generation." A zero off the line would change error terms, not the fact that primes are plentiful. The prime number theorem is proved, and FIPS 186-5's randomised tests have unconditional error bounds.
• Confusing evidence with proof. Twelve trillion verified zeros, and the li(x) pattern that held for every computed case and is still false in general, show why.
• Mixing up the two Riemann hypotheses. The one for curves over finite fields is a theorem (Hasse, Weil, Deligne) and underlies elliptic curve group size estimates. The classical one for ζ(s) is open.
• Assuming Miller-Rabin is "proven only if RH holds". Only Miller's deterministic variant depends on GRH. The randomised version used in practice does not.
• Reading "error probability" in a standard the wrong way. FIPS 186-5 explicitly distinguishes the chance a generated number is composite from the chance a composite survives validation.
• Writing your own primality test for production keys. Use a maintained cryptographic library and keep it patched.
• Treating an AI or formalisation announcement as a solution. Check what was formalised (a statement, a known theorem, or the open problem), and whether it meets Clay's publication, time and acceptance conditions.

FAQ

What is the Riemann hypothesis in simple terms?

It is the claim that all non-trivial zeros of the Riemann zeta function lie on the vertical line with real part 1/2. If true, the error in the best estimate of the prime count, li(x), stays near √x times ln x. Up to one million, for example, there are 78,498 primes and li(x) is off by only about 130.

Has the Riemann hypothesis been proven?

No. It is one of the six unsolved Millennium Prize Problems. Platt and Trudgian verified it rigorously up to height 3 × 10^12, about 12.4 trillion zeros, but infinitely many zeros remain. No proof has been published and accepted under Clay's rules.

What are the trivial zeros of the zeta function?

They are the negative even integers −2, −4, −6 and so on, where ζ(s) = 0 because of the gamma factor in Riemann's functional equation. They are fully understood and are excluded from the hypothesis. The non-trivial zeros are the infinitely many zeros in the strip with real part between 0 and 1.

Would solving the Riemann hypothesis break encryption?

Not by any known route. RSA depends on the hardness of factoring and elliptic curve cryptography on the hardness of discrete logarithms. The hypothesis is about the distribution of primes and is not a factoring method. Large quantum computers running Shor's algorithm are the actual threat, which is why NIST is moving to post-quantum algorithms.

How does the Riemann hypothesis relate to primality testing?

Miller's 1976 deterministic test is guaranteed correct only if the extended Riemann hypothesis holds. The randomised Miller-Rabin test (Rabin 1980), which FIPS 186-5 specifies for key generation, and the deterministic AKS test (2004) do not depend on it.

How many Miller-Rabin rounds does NIST require for RSA primes?

FIPS 186-5 Table B.1 requires, for 1024-bit p and q, at least 4 rounds at error probability 2^−100 or 5 rounds at 2^−112. For 2048-bit primes it is 2 rounds at 2^−100 or 4 rounds at 2^−144. A single Lucas test can follow the Miller-Rabin rounds for extra assurance.

How much is the Riemann hypothesis prize, and how do you claim it?

Clay offers $1 million. It does not accept direct submissions. A solution must be published in a qualifying outlet, at least two years must pass, and it must have general acceptance in the mathematics community, under the rules adopted on 26 September 2018.

Has AI solved the Riemann hypothesis?

No. AI tools have helped formalise known results; for example, Math Inc. reports its Gauss agent completed the strong prime number theorem formalisation in Lean. Google DeepMind maintains a benchmark of formally stated open conjectures. None of the groups involved claims a proof of the Riemann hypothesis.

Can Safeguard models solve the Riemann hypothesis or other maths problems?

No, and we do not claim they can. Safeguard's models are single purpose security models, and our benchmarks page says general purpose models beat them on mathematics. Safeguard's role is the software around this topic: the cryptographic and scientific libraries your projects depend on.

Why supply chain hygiene still matters here

No software tool will settle the Riemann hypothesis, but every RSA key, elliptic curve signature and post-quantum handshake in production is computed by an open source library with its own release history and advisories. The same is true of the Python, Lean and numerical toolchains used to explore these questions, so the practical work for a security team is keeping those components inventoried and patched.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. For this topic, that means you can ask a general assistant which of your projects carry a given cryptographic library version, while you decide exactly what it can touch.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session. Asked to fix a lodash CVE, it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. The same approve each step flow applies when a crypto or numerics library in your project needs a version bump: the change counts only after your tests pass.

Click through it at your own pace, or open it full screen.

The third demo sets up the Safeguard runner on your own machine, approves it with its device code, and runs a scan from the terminal. On a research workstation with a Python or Lean toolchain like the one in the walkthrough, the same flow shows which installed open source packages carry known vulnerabilities, without sending the repository anywhere first.

Click through it at your own pace, or open it full screen.

To try it on your own projects, download Safeguard or read the CLI documentation.

Quick check

Sources

• Clay Mathematics Institute: Riemann Hypothesis
• E. Bombieri, Problems of the Millennium: the Riemann Hypothesis (Clay official problem description, PDF)
• Clay Mathematics Institute: Rules for the Millennium Prize Problems
• Clay Mathematics Institute: The Millennium Prize Problems
• Clay Mathematics Institute: Riemann's 1859 Manuscript
• B. Riemann, On the Number of Prime Numbers less than a Given Quantity, translated by D. R. Wilkins (Trinity College Dublin, PDF)
• MacTutor History of Mathematics: Prime numbers
• OEIS A006880: number of primes below 10^n
• A. Odlyzko: Tables of zeros of the Riemann zeta function
• D. Platt and T. Trudgian, The Riemann hypothesis is true up to 3 × 10^12 (arXiv 2004.09765)
• M. Agrawal, N. Kayal, N. Saxena, PRIMES is in P, Annals of Mathematics 160 (2004)
• G. L. Miller, Riemann's hypothesis and tests for primality, J. Comput. Syst. Sci. 13 (1976), Crossref record
• M. O. Rabin, Probabilistic algorithm for testing primality, J. Number Theory 12 (1980), Crossref record
• NIST FIPS 186-5, Digital Signature Standard (PDF)
• NIST IR 8547 (initial public draft), Transition to Post-Quantum Cryptography Standards
• P. W. Shor, Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer (arXiv quant-ph/9508027)
• Lean mathlib source: Mathlib/NumberTheory/LSeries/RiemannZeta.lean
• PrimeNumberTheoremAnd (PNT+) project on GitHub
• Math Inc.: Introducing Gauss, an agent for autoformalization
• Google DeepMind: Formal Conjectures repository
• mpmath documentation: Zeta functions and zetazero
• SymPy documentation: Number theory (isprime, primepi, mr)
• OpenSSL 3.0 manual: openssl-prime

Last reviewed: 23 October 2026.