[Cryptography] mathematical constants

[Jon Callas]

> On Jun 7, 2026, at 15:53, Pierre Abbat <phma at bezitopo.org> wrote:
> 
> Is there a place where we can collect mathematical constants for use as 
> nothing-up-my-sleeve numbers? Pi has been used in MD2 and Blowfish, SHA-1 uses 
> square roots of primes, Twistree (hash function I invented) uses two 
> representations of exp(4), and many cryptographic algorithms use φ. I thought 
> of computing the 2-adic sum of all factorials, and found that the alternating 
> sum of all factorials (which converges in all p-adic systems) is equal to the 
> Gompertz constant (in the same way that you can add all positive integers and 
> get -1/12).

What's the goal here? 

(By the way, at least one of the things you mention -- Blowfish -- are not really using them as NUMS constants at all. In Blowfish, there's a buffer that's initialized with them because otherwise it would be zero. Pi is a convenient thing to fill it with. It's a similar thing with SHA-1, but that leads to the comments below.)

I think there are two things that are in tension here. One is the idea behind NUMS, which is an argument that algorithm parameters are not weak. Whatever "weak" means. The other is that we want the most secure algorithm possible. Whatever "most" and "secure" mean.

If there are any options in the NUMS selection, then there's always a chance there could be some sort of backdoor. (Even in the case of only one selection there's a chance, but let's put that aside for now.) Assume Alice wants an advantage on attacking the algorithm; it seems likely that whatever the set of NUMS options are, Alice will pick the most favorable one. There's also positive and negative versions of this. Alice might pick the parameters that are secretly weak, or avoid parameters that are secretly strong.

If there are no options on the selection, then we're declaring that we don't want a more secure parameter than the agreement. In effect, we are saying that the risk of a backdoor is greater than the risk of weak parameters; moreover we're saying that we accept the weaknesses of the agreement and reject improvements declaring them essentially a stalking horse for backdoors. 

These are in tension -- you can't have both laudable goals at the same time. You can't have both the most secure algorithm and only one parameter choice. (I go further and assert that we can't ever know that there are no hidden flaws in the single NUMS selection. On top of that, an enterprising jester could start a whispering campaign that the single NUMS was created with some secret cabal that reserved the flaw for themselves. I'm not sure there's a way out of that hall of mirrors once there are people who wander in.)

There's a real-world case where both of these are true, even. That's Lucifer/DES. We know that Lucifer was a 64-bit block cipher with weak S-boxes and that it was transformed into a 56-bit block cipher with strong S-boxes and that the resultant cipher, DES, is overall more secure than Lucifer. (There's also a lot I glossed over here, starting with the word "secure" when we try to compare the effect of a shorter key against improved cryptanalysis.)

When I was working on Threefish, we selected our rotation constants (which in an ARX SP-network are the analogues of S-boxes) with an evolutionary algorithm that used random values taken from a PRNG that was simply initialized. We flat out said in the papers that we are giving transparency in the process and showing all the work, but we can't ever prove that there was nothing up our sleeve. (Though not in those words, of course.)

I think that NUMS is a really great concept that's easy to say and easy to agree is a great concept. However, the more that we examine what it means, the more we wander into a hall of mirrors. It's good to know there's nothing up the designer's sleeve, and we also want to know there's nothing in the designer's shoe, or palmed in their left hand, or casually hooked to the lining of their jacket, or what. We also don't know that the adversary isn't advocating for NUMS because that's the weakest parameter set.

In the real world there are a lot of things that have unknown provenance. We don't know what the selection was for any of the NIST elliptic curves. We don't know why the primes picked in SHA-1 were picked. Heck, we don't know why Blowfish uses digits of pi and not digits of e or phi, or what. (I also think that picking pi is pretty close to NUMS because the properties we want that bitstring to have are provably met by pi, and it's pretty much the number on the top of just about anyone's head.)

I think it's indeed interesting to have a catalogue of useable arbitrary constants that are useful. A survey of cryptographically interesting constants would be a fun book to read and fun to write. Yet I'm not sure what it gains us. What am I missing?

	Jon