Numbers used by cryptographers to show that they are working in good faith
In cryptography, nothing-up-my-sleeve numbers are any numbers which, by their construction, are above suspicion of hidden properties. They are used in creating cryptographic functions such as hashes and ciphers. These algorithms often need randomized constants for mixing or initialization purposes. The cryptographer may wish to pick these values in a way that demonstrates the constants were not selected for a nefarious purpose, for example, to create a backdoor to the algorithm.[1] These fears can be allayed by using numbers created in a way that leaves little room for adjustment. An example would be the use of initial digits from the number π as the constants.[2] Using digits of π millions of places after the decimal point would not be considered trustworthy because the algorithm designer might have selected that starting point because it created a secret weakness the designer could later exploit—though even with natural-seeming selections, enough entropy exists in the possible choices that the utility of these numbers has been questioned.
Digits in the positional representations of real numbers such as π, e, and irrational roots are believed to appear with equal frequency (see normal number). Such numbers can be viewed as the opposite extreme of Chaitin–Kolmogorov random numbers in that they appear random but have very low information entropy. Their use is motivated by early controversy over the U.S. Government's 1975 Data Encryption Standard, which came under criticism because no explanation was supplied for the constants used in its S-box (though they were later found to have been carefully selected to protect against the then-classified technique of differential cryptanalysis).[3] Thus a need was felt for a more transparent way to generate constants used in cryptography.
Card that was hidden in a sleeve
"Nothing up my sleeve" is a phrase associated with magicians, who sometimes preface a magic trick by holding open their sleeves to show they have no objects hidden inside.
Examples
Ron Rivest used the trigonometric sine function to generate constants for the widely used MD5 hash.[4]
The U.S. National Security Agency used the square roots of the first eight prime integers to produce the hash constants in their "Secure Hash Algorithm" functions, SHA-1 and SHA-2.[5] SHA-1 also uses 0123456789ABCDEFFEDCBA9876543210F0E1D2C3 as its initial hash value.
The Blowfish encryption algorithm uses the binary representation of π (without the initial 3) to initialize its key schedule.[2]
RFC 3526 describes prime numbers for internet key exchange that are also generated from π.
The AES candidateDFC derives all of its arbitrary constants, including all entries of the S-box, from the binary expansion of e.[7]
The ARIA key schedule uses the binary expansion of 1/π.[8]
The key schedule of the RC5 cipher uses binary digits from both e and the golden ratio.[9]
Multiple ciphers including TEA and Red Pike use 2654435769 or 0x9e3779b9 which is ⌊232/ϕ⌋, where ϕ is the golden ratio.
The BLAKE hash function, a finalist in the SHA-3 competition, uses a table of 16 constant words which are the leading 512 or 1024 bits of the fractional part of π.
The key schedule of the KASUMI cipher uses 0x123456789ABCDEFFEDCBA9876543210 to derive the modified key.
The Salsa20 family of ciphers use the ASCII string "expand 32-byte k" or "expand 16-byte k" as constants in its block initialization process.
Bcrypt uses the string "OrpheanBeholderScryDoubt" as an initialization string[10][11]
Counterexamples
The Streebog hash function S-box was claimed to be generated randomly, but was reverse-engineered and proven to be generated algorithmically with some "puzzling" weaknesses.[12]
The Data Encryption Standard (DES) has constants that were given out by NSA. They turned out to be far from random, but instead made the algorithm resilient against differential cryptanalysis, a method not publicly known at the time.[3]
Dual_EC_DRBG, a NIST-recommended cryptographic pseudo-random bit generator, came under criticism in 2007 because constants recommended for use in the algorithm could have been selected in a way that would permit their author to predict future outputs given a sample of past generated values.[1] In September 2013 The New York Times wrote that "internal memos leaked by a former NSA contractor, Edward Snowden, suggest that the NSA generated one of the random number generators used in a 2006 NIST standard—called the Dual EC DRBG standard—which contains a back door for the NSA."[13]
Although not directly related, after the backdoor in Dual_EC_DRBG had been exposed, suspicious aspects of the NIST's P curve constants[14] led to concerns[15] that the NSA had chosen values that gave them an advantage in finding[16] private keys.[17] Since then, many protocols and programs started to use Curve25519 as an alternative to NIST P-256 curve.
Limitations
Bernstein and coauthors demonstrate that use of nothing-up-my-sleeve numbers as the starting point in a complex procedure for generating cryptographic objects, such as elliptic curves, may not be sufficient to prevent insertion of back doors. For example, many candidates of seemingly harmless and "uninteresting" simple mathematical constants exist, such as π, e, Euler gamma, √2, √3, √5, √7, log(2), (1 + √5)/2, ζ(3), ζ(5), sin(1), sin(2), cos(1), cos(2), tan(1), or tan(2). For these constants, there also exists several different binary representations to choose. If a constant is used as a random seed, a large number of hash function candidates also exist for selection, such as SHA-1, SHA-256, SHA-384, SHA-512, SHA-512/256, SHA3-256, or SHA3-384.
If there are enough adjustable parameters in the object selection procedure, combinatorial explosion ensures that the universe of possible design choices and of apparently simple constants can be large enough so that an automatic search of the possibilities allows construction of an object with desired backdoor properties.[18]
^Rivest, R. L. (1994). "The RC5 Encryption Algorithm"(PDF). Proceedings of the Second International Workshop on Fast Software Encryption (FSE) 1994e. pp. 86–96.
