Prime Numbers

Algorithm 8.1.6 (ECC key exchange). Two individuals, Alice and Bob, agree on a public elliptic curve E and a public point P E whose point order is n. (In many scenarios, n is prime, or admits of a large prime factor.) This algorithm produces a mutual key.

That the mutual key is unique follows directly from the group rules, as

[KB]([KA]P ) = [KBKA]P = [KAKB]P = [KA]([KB]P ).

Again the notion of the di culty of Bob, say, discovering Alice’s private key KA is presumably the di culty of EDL. That is, if EDL is easy, then the ECC key exchange is not secure; and, it is thought that the converse is true as well. Note that in ECC implementations, private keys are integers, usually roughly the size of p (but could be larger than p—recall that the group order #E can itself slightly exceed p), while public keys and the exchanged mutual key are points. Typically, some bits of a mutual key would be used in, say, a block cipher; for example, one might take the bits of the x-coordinate.

A primary result in regard to the EDL problem is the so-called “MOV theorem,” which states essentially that the EDL problem over Fp is equivalent to the normal DL problem over FpB , for some B [Menezes et al. 1993]. There is a practical test for the estimated level of security in an ECC system—call this level the MOV threshold—see [Solinas 1998]. In practice, the MOV threshold B is “about 10,” but depends, of course, on the prevailing complexity estimate for the DL problem in finite fields. Note, however, that “supersingular” curves, having order #E = p+1, are particularly susceptible, having EDL complexity known to be no worse than that of the DL problem in Fpk , some k ≤ 6 [Menezes et al. 1993]. Such curves can be ruled out a priori for the reason stated.

There is also the so-called Semaev–Smart–Satoh–Araki attack, when the order is #E = p, based on p-adic arithmetic. (The 1998 announcement in [Smart 1999] caused a noticeable ripple in the cryptography field, although the theoretical knowledge is older than the announcement; see [Semaev 1998], [Satoh and Araki 1998].) More modern attacks, some of which involve the real-timing of elliptic ladders, are discussed in may references; for example, see V. M¨uller’s site [M¨uller 2004].

Incidentally, the question of how one finds elliptic curves of prime order (and so having elements of prime order) is itself interesting. One approach is

just to generate random curves and assess their orders via Algorithm 7.5.6. Another is to use Algorithm 7.5.9 or 7.5.10 to generate possible orders, and when a prime order is found, go ahead and specify a curve with that order. But there are clever variants of these basic approaches (see Exercise 8.27). It should be remarked that some cryptographers accept curves of order #E = f r, where f may consist of small prime factors while r is a large prime. For such curves, one still prefers to find points of the prime order r, and this can be done very simply:

Algorithm 8.1.7 (Find a point of prime order). Given an elliptic curve

Ea,b(Fp) of order #E = f r, where r is prime, this algorithm endeavors to find a point P E of order r.

The algorithm is admittedly almost trivial, but important in cryptography applications. One such application is elliptic signature. There is a standard elliptic-curve digital signature scheme that runs like so, with the prerequisite of a point of prime order evident right at the outset:

Algorithm 8.1.8 (Elliptic curve digital signature algorithm (ECDSA)).

This algorithm provides functions for key generation, signing, and verification of messages. A message is generally denoted by M , an integer, and it is assumed that a suitable hash function h is in hand.

1. [Alice generates key]

Alice chooses a curve E, whose order #E = f r with r a “large” prime; Alice finds point P E of order r, via Algorithm 8.1.7;

Alice’s signature is the pair (R, s), transmitted with message M ;

3. [Bob verifies]

Bob obtains Alice’s public key (E, P, r, Q); w = s−1 mod r;

u1 = h(M )w mod r; u2 = Rw mod r;

(x0, y0) = [u1]P + [u2]Q; v = x0 mod r;

if(v == R) Bob accepts signature; else Bob rejects signature;

This algorithm is modeled on an older DSA standard, and amounts to the natural elliptic-curve variant of DSA. Modern details and issues are discussed in [Johnson et al. 2001]. The hash value h(M ) is, technically speaking, supposed to be e ected via another standard, the SHA-1 hash function [Juriˇsi´c and Menezes 1997]. Those authors also discuss the interesting issue of security. They conclude that a 1024-bit DSA system is about as secure as a 160-bit ECDSA system. If valid, such an observation shows once again that, on our current knowledge, the EDL problem is about as hard as a computational number-theoretical problem can be.

The current record for an EDL computation pertains to the “Certicom Challenge,” for which an EDL was solved in 2002 by C. Monico et al. for an elliptic curve over Fp with p being a 109-bit prime. The next challenge of this type on the list is a 131-bit prime, but under current knowledge of EDL di culty, the 131-bit case is perhaps two thousand times harder than the 109-bit case.

Incidentally, there is a di erent way to e ect a signature scheme with elliptic curves, which is the El Gamal scheme. We do not write out the algorithm—it is less standard than the above ECDSA scheme (but no less interesting))—but the essentials lie in Algorithm 8.1.10. Also, the theoretical ideas are found in [Koblitz 1987].

We have mentioned, in connection with RSA encryption, the practical expedient of using the sophisticated methods (RSA, ECC) for a key exchange, then using the mutually understood key in a rapid block cipher, such as DES, say. But there is another fascinating way to proceed with a kind of “direct” ECC scheme, based on the notion of embedding plaintext as points on elliptic curves. In this fashion, all encryption/decryption proceeds with nothing but elliptic algebra at all phases.

Theorem 8.1.9 (Plaintext-embedding theorem). For prime p > 3 let E denote an elliptic curve over Fp, with governing cubic

y2 = x3 + ax + b.

Let X be any integer in [0, p − 1]. Then X is either an x-coordinate of some point on E, or on the twist curve E whose governing cubic is gy2 = x3 +ax+b,

s = X + aX + b mod p,

Y = s(p+1)/4 mod p,

then (X, Y ) is a point on either E, E , respectively, as

Y 2 ≡ s, −s (mod p),

where in the latter case we take the governing cubic for E to be −y2 = x3 + ax + b.

This theorem is readily proved via the same twist algebra that we encountered in Theorem 7.5.2 and Exercise 7.16, and leads to the following algorithm for direct-embedding encryption:

Algorithm 8.1.10 (Direct-embedding ECC encryption). This algorithm allows encryption/decryption using exclusively elliptic algebra, i.e., with no intermediary cipher, via the direct embedding of plaintext onto curves. We assume that Alice and Bob have agreed upon a public curve Ea,b(Fp) with its twist curve E , on which lie respectively public points P, P . In addition, it is assumed that Bob has generated respective public keys PB = [KB]P, PB = [KB]P , as in Algorithm 8.1.6. We denote by X a parcel of plaintext (an integer in [0, . . . , p − 1]) that Alice wishes to encrypt for Bob.

1. [Alice embeds plaintext X]

Alice determines the curve E or E on which X is a valid x-coordinate (and, if y-coordinates are relevant, computes such number Y ) via Theorem 8.1.9, taking the curve to be E if X is on both curves;

QB = PB or PB.

Alice chooses random r [2, p − 2];

Alice transmits a parcel (encrypted message, clue, bit) as (U, C, d);

2. [Bob decrypts to get plaintext X]

Bob inspects d to determine on which curve elliptic algebra will proceed; (X, Y ) = U − [KB]C; // Private key applied with elliptic subtract. Bob now recovers the plaintext as the x-coordinate X;

This method will be recognized as an El Gamal embedding scheme, where we have made some improvements over previous renditions [Koblitz 1987], [Kaliski 1988]. Note that the last part of Theorem 8.1.9 allows Algorithm 8.1.10 to proceed e ciently when the field characteristic has p ≡ 3 (mod 4). In practical implementations of Algorithm 8.1.10, there are two further substantial improvements one may invoke. First, the y-coordinates are not needed if one uses Montgomery coordinates (Algorithm 7.2.7) throughout and carefully applies Algorithm 7.2.8 at the right junctures. Second, the “clue” point C of the algorithm e ectively doubles the transmitted data size. This, too, can be avoided by carefully setting up a random number exchange protocol, so that the random number r itself is deterministically kept in synchrony by the two parties. (The authors are indebted to B. Garst for

this observation, which in fact has led to a U. S. Patent [Crandall and Garst 2001].) See Exercise 8.3 for more detail on such enhancements. If properly done, one obtains a fairly e cient, elegant direct-embedding scheme with— asymptotically speaking—no data expansion.

8.1.4Coin-flip protocol

In cryptography, a protocol is essentially an algorithm specifying—in a certain order—the steps that involved parties must take. We have seen key-exchange and related protocols already. Here we investigate an intriguing cultural application of number-theoretical protocols. How can one toss a coin, fairly, over the telephone? Or play poker among n individuals, playing “blind” on a network? We assume the worst: That no party trusts any other, yet a decision has to be reached, as one would so reach it via a coin toss, with one party calling heads or tails. It turns out that such a remote tossing is indeed possible, using properties of certain congruences.

Incidentally, the motivation for even having a coin-flip protocol is obvious, when one imagines a telephone conversation—say between two hostile parties involved in a lawsuit—in which some important result accrues on the basis of a coin flip, meaning a random bit whose statistics cannot be biased by either party. Having one party claim they just flipped a head, and therefore won the toss, is clearly not good enough. Everyone must be kept honest, and this can be done via adroit application of congruences involving primes or certain composites. Here is one way to proceed, where we have adapted some ideas from [Bressoud and Wagon 2000] on simple protocols:

Algorithm 8.1.11 (Coin-flip protocol). Alice and Bob wish to “flip a fair coin,” using only a communication channel. They have agreed that if Bob guesses correctly, below, then Bob wins, otherwise Alice wins.

1. [Alice selects primes]

Alice chooses two large primes p < q, forms the number n = pq, and chooses a random prime r such that nr = −1;

2.[Alice sends Bob partial information] Alice sends Bob n and r;

3.[Bob chooses]

Bob makes a choice between “the smaller prime factor of n is a quadratic residue mod r” and “the larger prime factor of n is a quadratic residue mod r” and sends this choice to Alice;

4. [Alice announces winner]

Alice announces whether Bob is correct or not, and sends him the primes p, q so that Bob can see for himself that she is not cheating;

It is interesting to investigate the cryptographic integrity of this algorithm; see Exercise 8.8. Though we have cast the above algorithm in terms of winner and loser, it is clear that Alice and Bob could use the same method just to establish a random bit, say “0” if Alice wins and “1” if Bob wins. There

are many variants to this kind of coin-flip protocol. For example, there is a protocol in [Schneier 1996] in which four square roots of a number n = pq are generated by Alice and sent to Bob, with Bob having generated a random square modulo n. This scenario is not as simple as Algorithm 8.1.11, but it is replete with interesting issues; e.g., one can extend it to handle the peculiar Micali scenario in which Bob intentionally loses [Schroeder 1999]. There are also algorithms based on Blum integers and, generally, the fact of a product pq allowing multiple roots (see Exercise 8.7). These ideas can be extended in a natural way to a poker-playing protocol in which a number of players claim what poker hands they possess, and so on [Goldwasser and Micali 1982].

8.2 Random-number generation

The problem of generating random numbers goes back, of course, to the dawn (1940s, say) of the computer age. It has been said that to generate random numbers via machine arithmetic is to live, in the words of J. von Neumann, “in a state of sin.” Though machines can ensure nearly random statistics in many senses, there is the problem that conventional machine computation is deterministic, so the very notion of randomness is suspect in the world of Turing machines and serial programs. If the reader wonders what kind of technology could do better in the matter of randomness (though still not “purely” random in the sense of probability theory), here is one exotic example: Aim a microwave receiving dish at the remote heavens, listening to the black-body “fossil” radiation from the early cosmos, and digitize that signal to create a random bitstream. We are not claiming the cosmos is truly “random,” but one does expect that a signal from remote regions is as “unknowable” as can be.

In modern times, the question of true randomness has more import than ever, as cryptographic systems in particular often require numbers that are as random, or as seemingly random, as can be. A deterministic generator that generates what looks to an eavesdropper like random numbers can be used to build a simple cryptosystem. Create a random bitstream. To encrypt a message, take the logical exclusive-or of bits of the message with bits of the random bitstream. To decrypt, do the exclusive-or operation again, against the same random bitstream. This cryptosystem is unbreakable, unless certain weaknesses are present—such as, the message is longer than the random stream, or the same random stream is reused on other messages, or the eavesdropper has special knowledge of the generator, and so on. In spite of such practical pitfalls, the scheme illustrates a fundamental credo of cryptography: Somehow, use something an eavesdropper does not know.

It seems that just as often as a new random-number generator is developed, so, too, is some older scheme shown to be nonrandom enough to be, say, “insecure,” or yield misleading results in Monte Carlo simulations. We shall give a brief tour of random number generation, with a view, as usual, to the involvement of prime numbers.

8.2.1Modular methods

The veritable workhorse of the random number generation industry has been the linear-congruential generator. This method uses an integer iteration

xn+1 = (axn + b) mod m,

where a, b, m are integer constants with m > 1, which recursion is to be ignited by an initial “seed,” say x0. To this day there continue to appear research results on the e cacy of this and related generators. One variant is the multiplicative congruential generator, with recursion

xn+1 = (cxn) mod m,

where in this case the seed x0 is assumed coprime to m. In applications requiring a random() function that returns samples out of the real interval [0, 1), the usual expedient is simply to use xn/m.

Recurrences, like the two above, are eventually periodic. For random number generation it is desirable to use a recursion of some long period. It is easy to see that the linear-congruential generator has period at most m and the multiplicative congruential generator has period at most m− 1. The linear case can—under certain constraints on the parameters—have the full period m for the sequence (xn), while the multiplicative variety can have period m − 1. Fundamental rules for the behavior of such generators are embodied in the following theorem:

Theorem 8.2.1 (Lehmer). The linear-congruential generator determined by

xn+1 = (axn + b) mod m

has period m if and only if

(1)gcd(b, m) = 1,

(2)p|a − 1 whenever prime p|m,

(3)4|a − 1 if 4|m.

Furthermore, the multiplicative congruential generator determined by

xn+1 = (cxn) mod m

has period m − 1 if and only if

(1)m is prime,

(2)c is a primitive root of m,

(3)x0 ≡0 (mod m).

Many computer systems still provide the linear scheme, even though there are certain flaws, as we shall discuss.

First we give an explicit, standard linear-congruential generator:

Algorithm 8.2.2 (32-bit random-number generator (Knuth, Lewis)).

This algorithm provides seeding and random functions for a certain generator known to have fairly good statistical behavior. We take M = 232 as the generator modulus, and will speedily e ect operations modulo M by logical “and” (&) with M −1. One first calls the seed() procedure, then calls random() successively to get random numbers.

Note that the “and” operation with M − 1 is simply the taking of the low 32 bits of the number involved. Along similar lines, the popular generator

xn+1 = (16807xn) mod M31,

where M31 = 231 − 1 is a Mersenne prime, has enjoyed a certain success in passing many (but not all) experimental tests [Park and Miller 1988], [Press et al. 1996].

An interesting optimization of certain congruential generators has been forwarded in [Wu 1997]. The recursion is

xn+1 = (230 − 219)xn mod M61,

where the fact of M61 being a Mersenne prime allows some rapid arithmetic.

Algorithm 8.2.3 (Fast, 61-bit random generator). This algorithm provides seeding and random functions for the Wu generator, modulus M = 261 − 1 and multiplier c = 230 − 219. Though modular multiplications occur in principle, the explicit operations below are relegated to addition/subtraction, left/right shifts (<< / >>, respectively), and logical “and” (&) which acts as a certain mod operation.

1. [Procedure seed] seed() {

Choose starting seed x; // x is an integer in [1, M − 1]. return;

}

2. [Function random] random() {

x = (x >> 31) + ((x << 30)&M ) − (x >> 42) − ((x << 19)&M ); if(x < 0) x = x + M ;

}

In practice, this algorithm can be impressive, to say the least. For example, using input parameters b = 264, r = 30, s = 6, so that we shall iterate

x0 = v6 − v30 − c,

with mod, carry, and shift understood from Algorithm 8.2.5, the period turns

out to be

P ≈ 10578,

which is one of myriad striking examples of the following theorem:

Theorem 8.2.6 (Marsaglia). The random-number generator of Algorithm

8.2.5 has period

P = ϕ(br − bs + 1).

Thus, the period for our previous explicit example is really

ϕ 264·30 − 264·6 + 1 = 264·30 − 264·6 ≈ 10578,

the argument of ϕ being prime. Note that a number produced by the generator can repeat without the subsequent number repeating; it is the vector v internal to the algorithm that is key to the length of the period. As there are on the order of br possible vectors v, the Marsaglia theorem above makes some intuitive sense.

Another iterative generator is the discrete exponential generator (also known as the power generator) determined by

xn+1 = gxn (mod N ),

for given g, x0, N . It has been studied by [Blum et al. 1986], [Lagarias 1990], [Friedlander et al. 2001], [Kurlberg and Pomerance 2004] and some rigorous results pertaining to security are known. It is often of interest to generate a secure random bit with as little computation as possible. It had been known that if just one bit is chosen from each xn, then this is in a sense secure, but at the cost of much computation to generate each bit. In [Patel and Sundaram