The technique is called a nothing-up-my-sleeve number, borrowed from stage magic. Instead of picking a constant and asking the world to take it on faith, the designer derives it from something with no plausible degrees of freedom: the fractional digits of a square root, the binary expansion of pi, a counter that just goes 1, 2, 3. If the constant came from the cube root of the seventeenth prime, the designer had almost no room to search for a value with a hidden property, because there is only one such value.
MD5 takes its 64 round constants from the sine function, computing the integer part of the absolute value of sin(i) times 2 to the 32nd for each round index. SHA-256 uses the fractional parts of the square roots of the first eight primes for its initial hash state, and the cube roots of the first sixty-four primes for its round constants. Blowfish fills its substitution boxes with the hexadecimal digits of pi. ChaCha20's constant is not a number in any mathematical sense at all: it is the ASCII string expand 32-byte k, which anybody can decode by eye.
None of these choices make the algorithms stronger in a provable sense. They make them auditable. A reviewer can recompute the constants from the stated rule in a few lines of code and confirm that no other value was substituted along the way.
The problem this was invented to solve
In 1975, IBM submitted a cipher to the US National Bureau of Standards that became DES. The NSA participated in the review, and the version that emerged had a shortened key and modified substitution boxes. The S-box values came with no published derivation and no explanation. For roughly two decades, a widespread assumption in the academic community was that the modifications hid a backdoor.
The truth turned out to be close to the opposite. When Biham and Shamir published differential cryptanalysis in 1990, DES proved unusually resistant to it. Don Coppersmith of IBM confirmed in 1994 that the design team had known about the attack in the 1970s, that the S-boxes had been tuned specifically to resist it, and that they had been asked to keep the technique quiet. The constants were strengthened, not weakened. Nobody outside could tell the difference, and that is the entire point.
An unexplained constant is indistinguishable from a maliciously chosen one. DES's S-boxes were tuned to resist an attack that would not be published for fifteen years, and the community spent those fifteen years suspecting a backdoor. Secrecy about a design rationale costs trust even when the rationale is good.
The case that made everyone care again
Dual_EC_DRBG was a random number generator standardised by NIST in 2006. Its security rested on two elliptic curve points, P and Q, published as fixed constants with no derivation.
At a rump session in 2007, Dan Shumow and Niels Ferguson presented a short and devastating observation: if anyone knows a scalar d such that P equals d times Q, then observing roughly 32 bytes of the generator's output lets them recover its internal state and predict every subsequent output. Nothing in the standard proved that no such d existed. Nothing in the standard explained where P and Q came from.
In 2013, documents released by Edward Snowden and subsequent reporting by Reuters indicated the NSA had paid to have the generator made the default in a widely deployed commercial cryptography library. NIST withdrew the algorithm in 2014. This is the clearest documented case of what unexplained constants make possible, and it is why the Dual_EC story is now the standard reference in every argument about constant selection.
Rigidity, and why the NIST curves are still argued about
The elliptic curves NIST standardised in 2000, including P-256, were generated from seed values that get hashed through SHA-1 to produce the curve parameters. This is a real verifiability property: given the seed, anyone can confirm the curve was produced by the stated procedure. What was never published is where the seeds themselves came from. They are unexplained hexadecimal strings.
Daniel Bernstein and Tanja Lange formalised the relevant property under the name rigidity. A curve generation process is rigid when the design criteria are stated in advance and are tight enough that the designer had essentially no freedom in the outcome. Curve25519 is the reference example: the parameters follow from a small set of published criteria plus "take the smallest value that satisfies them," leaving nothing for a designer to search over. The Brainpool curves took a different route to the same goal, deriving their seeds from the digits of pi and e.
| Constant | Stated origin | What a reviewer can check |
|---|---|---|
| SHA-256 round constants | Cube roots of the first 64 primes | Recompute all 64 in a few lines; any substitution is visible |
| ChaCha20 constant | ASCII text | Read it directly, no computation needed |
| AES S-box | Multiplicative inverse in GF(2^8) plus a fixed affine map | Regenerate the whole table from the algebraic rule |
| Curve25519 parameters | Smallest value meeting published criteria | Re-run the search and confirm the same curve appears |
| NIST P-256 seed | Not published | Curve derives verifiably from the seed; the seed derives from nothing |
| Dual_EC points P and Q | Not published | Nothing. This was the vulnerability. |
Why the technique proves less than it appears to
Here is the uncomfortable part, and it is worth stating plainly because the practice is often described as though it settled the question.
A designer who wants a backdoored constant does not have to abandon the nothing-up-my-sleeve style. They have to search across the space of plausible-sounding derivations. Pi or e or the golden ratio. Digits in hex or decimal or binary. Skip the first digit, or the first sixteen. Square root, cube root, natural log. Round up, round down, truncate. Each of those choices is individually innocuous and jointly they form a large search space.
Bernstein and colleagues demonstrated this concretely in work published under the name BADA55, where they constructed curves that satisfy a "nothing up my sleeve" style justification while secretly being chosen by the designer, including one whose parameters spell a chosen hexadecimal string. The lesson is not that the practice is worthless. It is that the strength of the guarantee depends entirely on how narrow the stated rule is, and that "derived from pi" on its own is a much weaker statement than it sounds.
A constant with a published derivation constrains the designer in proportion to how few reasonable derivations existed. One rule, stated before the search, constrains a lot. A rule selected after seeing the results constrains almost nothing.
What this means when you are choosing between implementations
Most people evaluating an encrypted messenger or a storage product will never inspect a round constant. The property still matters, because it propagates into questions you can ask without a cryptography background.
- Are the primitives standard and widely analysed? A product built on AES-GCM, ChaCha20-Poly1305, SHA-2 or SHA-3, and X25519 inherits decades of scrutiny of exactly this kind. A product with a proprietary cipher has none of it, whatever the marketing says.
- Is the parameter provenance documented anywhere? Specifications that explain where their numbers come from are written by people who expect to be checked.
- Can you reproduce the shipped binary from the published source? Constant selection is a design-time trust problem, and reproducible builds are the build-time equivalent. Both ask the same question: can an outsider confirm that what was published is what is running.
- Is randomness generated by the operating system? The Dual_EC failure was a random number generator failure. Modern CSPRNG practice is to use the kernel's source rather than an application-level construction, which removes the entire category.
The older principle underneath
All of this is a corollary of a rule stated in the nineteenth century. Kerckhoffs's principle holds that a cryptosystem's security must rest on the key alone, and that everything else about the system can be public without loss. An unexplained constant sits in an awkward middle: it is public, but its rationale is not, and the rationale is where the security might actually live.
The systems that have aged best are the ones that closed that gap. Their designers published the criteria first, derived the values second, and made the whole procedure cheap for a stranger to repeat. That is a weaker guarantee than a mathematical proof and a much stronger one than a datasheet. For a field where the failure mode is silent and can persist for decades, the ability to recompute somebody else's numbers is worth the constraint it imposes on the design.
If you want the neighbouring pieces of this story, our write-ups on elliptic curve cryptography and formal verification of protocols cover the two directions this leads: what the curve parameters actually do, and what it takes to prove a protocol correct rather than merely unbroken so far.