home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / pc / crypto / cryptprg.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  337.8 KB  |  8,260 lines

  1.  
  2.  
  3.                      PUBLIC-KEY CRYPTOGRAPHY
  4.  
  5.  
  6.  
  7. James Nechvatal
  8. Security Technology Group
  9. National Computer Systems Laboratory
  10. National Institute of Standards and Technology
  11. Gaithersburg, MD 20899
  12.  
  13.  
  14. December 1990
  15.  
  16.  
  17.  
  18.  
  19.  
  20.                             PREFACE
  21.  
  22.  
  23.    This publication presents a state-of-the-art survey of public-
  24. key cryptography circa 1988 - 1990. In doing so, it covers a number
  25. of different topics including:
  26.  
  27.  
  28.        1. The theory of public-key cryptography.
  29.  
  30.        2. Comparisons to conventional (secret-key) cryptography.
  31.  
  32.        3. A largely self-contained summary of relevant mathematics.
  33.  
  34.        4. A survey of major existing public-key systems.
  35.  
  36.        5. An exploration of digital signatures and hash functions.
  37.  
  38.        6. A survey of public-key implementations in networks.
  39.  
  40.        7. An introduction to zero-knowledge protocols and
  41.           probabilistic encryption.
  42.  
  43.        8. An exploration of security issues and key sizes.
  44.  
  45.  
  46.    The treatment of public-key cryptography in this publication
  47. includes both theory and practice. Much of the existing published
  48. work, including those documents listed in the references, treats
  49. either the theory or specific systems/implementations, but not
  50. both. The viewpoint here is that the theory and practice are
  51. inseparable. 
  52.  
  53.    Any mention of commercial products is for purposes of
  54. explanation and illustration only. Also, the selection of
  55. cryptosystems and hash functions mentioned in this publication
  56. serve only to provide examples. Such identification does not imply
  57. recommendation or endorsement by the National Institute of
  58. Standards and Technology, nor does it imply that systems or
  59. functions identified are necessarily the best available for the
  60. purpose.
  61.  
  62.    The focus is on issues such as criteria for systems and
  63. protocols for usage. These are presumably long-term, in contrast,
  64. to the set of existing public-key systems which is more volatile.
  65. Thus we provide information which will hopefully be of use to
  66. implementors of systems, but the frameworks we develop are
  67. versatile enough to be relevant in a variety of settings. The
  68. latter may include, for example, both electronic mail systems and
  69. electronic fund transfer systems.
  70.  
  71.    The core of this exposition is sections 1 to 5. Sections 1 to
  72. 3 cover the fundamentals of public-key cryptography and the related
  73. topics of hash functions and digital signatures. Extensive coverage
  74. of key management is also included, with a focus on certificate-
  75. based management. Section 4 gives some examples of public-key
  76. systems and hash functions. Section 5 gives some examples of actual
  77. or proposed implementations of public-key cryptography. The major
  78. example is the International Organization for Standardization (ISO)
  79. authentication framework.
  80.  
  81.    Section 6 gives a sample proposal for a local-area network
  82. implementation of public-key cryptography. It draws heavily on the
  83. work of ISO.
  84.  
  85.    A variety of topics are covered in the appendices, including a
  86. summary of relevant mathematics and algorithms. Also included is
  87. a brief introduction to zero-knowledge protocols, probabilistic
  88. encryption and identity-based public-key systems.
  89.    
  90.    In the following, letters refer to appendices; e.g. lemma G.2.1
  91. refers to a lemma appearing in section 2 of appendix G.
  92.  
  93.    The author wishes to thank Dr. Ronald L. Rivest, Dr. Gustavus
  94. Simmons, and Dr. Dennis Branstad for providing many comments and
  95. suggestions, and Dr. Burton S. Kaliski Jr. for providing
  96. information on implementations of the RSA public-key system. The
  97. paper was edited by Miles Smid.
  98.  
  99.    This paper was supported in part by the United States Department
  100. of Computer-Aided Logistics Supports, Department of Defense.                             CONTENTS  
  101.  
  102.  
  103. 1. Cryptosystems and cryptanalysis...............................1
  104.  
  105.  
  106.    1.1 Requirements for secrecy..................................2
  107.    1.2 Requirements for authenticity and integrity...............4
  108.    1.3 Conventional systems......................................5
  109.    1.4 Example of a conventional cipher: DES.....................5
  110.    1.5 Another conventional cipher: exponentiation...............6
  111.    1.6 Public-key cryptosystems..................................7
  112.         1.6.1 Secrecy and authenticity...........................8
  113.         1.6.2 Applicability and limitations.....................10
  114.  
  115.  
  116. 2. Key management...............................................12
  117.  
  118.  
  119.    2.1 Secret-key management....................................12
  120.    2.2 Public distribution of secret keys.......................13
  121.    2.3 Management of public components in a public-key system...15
  122.         2.3.1 Use of certificates...............................16
  123.         2.3.2 Generation and storage of component pairs.........17
  124.         2.3.3 Hardware support for key management...............18
  125.    2.4 Using public-key systems for secret key distribution.....19
  126.         2.4.1 A protocol for key exchange.......................20
  127.    2.5 Protocols for certificate-based key management...........22
  128.         2.5.1 Certificate management by a central authority.....22
  129.         2.5.2 Decentralized management..........................23
  130.         2.5.3 A phone-book approach to certificates.............24
  131.  
  132.  
  133. 3. Digital signatures and hash functions........................25
  134.  
  135.  
  136.    3.1 Public-key implementation of signatures..................27
  137.         3.1.1 Signing messages..................................27
  138.         3.1.2 The issue of nonrepudiation.......................29
  139.         3.1.3 The issue of proof of delivery....................30
  140.    3.2 Hash functions and message digests.......................31
  141.         3.2.1 Usage of hash functions...........................33
  142.         3.2.2 Relation to one-way functions.....................33
  143.         3.2.3 Weak and strong hash functions....................34
  144.    3.3 Digital signatures and certificate-based systems.........35
  145.  
  146.  
  147. 4. Examples of public-key systems and hash functions............37
  148.  
  149.  
  150.    4.1 The RSA public-key scheme................................39
  151.         4.1.1 Choice of p and q.................................41
  152.         4.1.2 Further notes on implementation...................42
  153.         4.1.3 Security of RSA...................................43
  154.                4.1.3.1 Restrictions on p and q..................43
  155.                4.1.3.2 Notes on factoring.......................44
  156.         4.1.4 Low-exponent versions of RSA......................45
  157.    4.2 Other public-key systems.................................46
  158.         4.2.1 Knapsack systems..................................47
  159.         4.2.2 The ElGamal signature scheme......................49
  160.    4.3 Examples of hash functions...............................53
  161.         4.3.1 Merkle's meta-method..............................53
  162.         4.3.2 Coppersmith's attack on Rabin-type functions......56
  163.         4.3.3 Quadratic congruential hash functions.............57
  164.    4.4 Hardware and software support............................58
  165.         4.4.1 Design considerations for RSA chips...............58
  166.         4.4.2 Proposed designs for RSA chips....................59
  167.  
  168.  
  169. 5. Implementations of public-key cryptography...................61
  170.  
  171.  
  172.    5.1 MITRENET.................................................61
  173.    5.2 ISDN.....................................................62
  174.         5.2.1 Keys..............................................62
  175.         5.2.2 Calling...........................................63
  176.    5.3 ISO Authentication Framework.............................64
  177.         5.3.1 Use of certificates...............................64
  178.         5.3.2 Certification paths...............................65
  179.         5.3.3 Expiration and revocation of certificates.........66
  180.         5.3.4 Authentication protocols..........................67
  181.         5.3.5 Further notes.....................................71
  182.    5.4 DARPA-Internet...........................................71
  183.  
  184.  
  185. 6. A sample proposal for a LAN implementation...................73
  186.  
  187.  
  188.    6.1 Integration into a network...............................73
  189.    6.2 Security threats.........................................74
  190.    6.3 Security services........................................74
  191.    6.4 Security mechanisms......................................75
  192.    6.5 Criteria for cryptosystems...............................76
  193.         6.5.1 Security..........................................77
  194.         6.5.2 Numerical criteria................................77
  195.         6.5.3 Other criteria....................................78
  196.    6.6 Criteria for hash functions..............................78
  197.    6.7 Example of a LAN security framework......................78
  198.         6.7.1 Key management....................................79 
  199.       6.7.2 Component generation and storage....................79
  200.         6.7.3 Secret-key generation.............................79
  201.         6.7.4 Issuance and distribution of certificates.........80
  202.         6.7.5 Compromised or invalidated certificates...........80
  203.         6.7.6 Authentication....................................81
  204.  
  205.  
  206. Appendix A. Mathematical and computational aspects..............83
  207.  
  208.  
  209.    A.1 Computational complexity and cryptocomplexity............83
  210.    A.2 Classical complexity theory..............................84
  211.    A.3 Public-key systems and cryptocomplexity..................84
  212.    A.4 Probabilistic algorithms.................................85
  213.    A.5 Status of some relevant problems.........................86
  214.  
  215. Appendix B. Algorithms and architectures........................89 
  216.  
  217.    B.1 Technology...............................................89
  218.    B.2 Computing modes..........................................90
  219.    B.3 Some relevant algorithms and implementation..............92
  220.        B.3.1 Quadratic sieve factoring algorithm................92
  221.        B.3.2 Computations in finite fields......................93
  222.        B.3.3 Other algorithms...................................94
  223.    B.4 Application-specific architectures.......................94
  224.        B.4.1 Systolic and wavefront arrays......................94
  225.        B.4.2 Proposal for a quadratic sieve machine.............95
  226.        B.4.3 Massively parallel machines........................95
  227.  
  228.  
  229. Appendix C. The classical theory of computation.................97
  230.  
  231.  
  232.    C.1 Turing machines..........................................97
  233.    C.2 Nondeterministic Turing machines.........................98
  234.    C.3 Computational complexity.................................99
  235.  
  236.  
  237. Appendix D. The theory of probabilistic computing..............101
  238.  
  239.  
  240. Appendix E. Breaking knapsacks.................................103
  241.  
  242.  
  243. Appendix F. Birthday attacks...................................105
  244.  
  245.  
  246. Appendix G. Modular arithmetic and Galois fields...............107
  247.  
  248.  
  249.    G.1 The Euler Phi function..................................108
  250.    G.2 The Euler-Fermat Theorem................................108
  251.    G.3 Galois fields...........................................110
  252.  
  253.  
  254. Appendix H. Euclid's algorithm.................................111
  255.  
  256.  
  257. Appendix I. The Chinese Remainder Theorem......................113
  258.  
  259.  
  260. Appendix J. Quadratic residues and the Jacobi symbol...........115
  261.  
  262.  
  263.    J.1 Quadratic residues modulo a prime.......................115
  264.    J.2 The Jacobi symbol.......................................116
  265.    J.3 Square roots modulo a prime.............................117
  266.    J.4 Quadratic residuosity modulo a prime....................118
  267.  
  268.  
  269. Appendix K. Primitive roots and discrete logarithms............119
  270.  
  271.  
  272. Appendix L. Primality testing..................................123
  273.  
  274.  
  275.    L.1 The Solovay/Strassen test...............................124
  276.    L.2 Lehman's test...........................................125
  277.    L.3 The Miller/Rabin test...................................126
  278.  
  279.  
  280. Appendix M. Mathematics of RSA and other exponential systems...127
  281.  
  282.  
  283. Appendix N. Quadratic residuosity modulo a composite...........129
  284.  
  285.    N.1 Characterizing quadratic residues.......................129
  286.    N.2 The Jacobi symbol once more.............................130
  287.    N.3 Quadratic residuosity and factoring.....................132
  288.    N.4 Quadratic residuosity and Blum integers.................133
  289.  
  290.  
  291. Appendix O. An introduction to zero-knowledge..................137
  292.  
  293.  
  294. Appendix P. Alternatives to the Diffie/Hellman model...........143
  295.  
  296.  
  297.    P.1 Probabilistic encryption................................143
  298.    P.2 Identity-based schemes..................................145
  299.  
  300.  
  301. References.....................................................147                       LIST OF ILLIONS
  302.  
  303.  
  304. Figure 1. Adaptive Chosen Plaintext Attack........................3
  305.  
  306. Figure 2. Using Public-Key for Secrecy and Authenticity..........10
  307.  
  308. Figure 3. The Diffie/Hellman Key Exchange........................15
  309.  
  310. Figure 4. A Protocol for Real-Time Authentication................21
  311.  
  312. Figure 5. A Protocol for Signing with Hash Function and Secrecy..28
  313.  
  314. Figure 6. Using RSA for Authenticity and Secrecy.................40
  315.  
  316. Figure 7. The ElGamal Signature Algorithm........................51
  317.  
  318. Figure 8. One-Way Authentication Protocol........................69    1. Cryptosystems and cryptana
  319.  
  320.  
  321.    Cryptography deals with the transformation of ordinary text
  322. (plaintext) into coded form (ciphertext) by encryption, and
  323. transformation of ciphertext into plaintext by decryption. Normally
  324. these transformations are parameterized by one or more keys. The
  325. motive for encrypting text is security for transmissions over
  326. insecure channels. 
  327.  
  328.    Three of the most important services provided by cryptosystems
  329. are secrecy, authenticity, and integrity. Secrecy refers to denial
  330. of access to information by unauthorized individuals. Authenticity
  331. refers to validating the source of a message; i.e., that it was
  332. transmitted by a properly identified sender and is not a replay of
  333. a previously transmitted message. Integrity refers to assurance 
  334. that a message was not modified accidentally or deliberately in
  335. transit, by replacement, insertion or deletion. A fourth service
  336. which may be provided is nonrepudiation of origin, i.e., protection
  337. against a sender of a message later denying transmission. Variants
  338. of these services, and other services, are discussed in [ISO-87].
  339.  
  340.    Classical cryptography deals mainly with the secrecy aspect. It
  341. also treats keys as secret. In the past 15 years two new trends
  342. have emerged:
  343.  
  344.  
  345.       a. Authenticity as a consideration which rivals and sometimes 
  346.          exceeds secrecy in importance.
  347.  
  348.       b. The notion that some key material need not be secret.
  349.  
  350.  
  351.    The first trend has arisen in connection with applications such
  352. as electronic mail systems and electronic funds transfers. In such
  353. settings an electronic equivalent of the handwritten signature may
  354. be desirable. Also, intruders into a system often gain entry by
  355. masquerading as legitimate users; cryptography presents an
  356. alternative to password systems for access control.
  357.  
  358.    The second trend addresses the difficulties which have
  359. traditionally accompanied the management of secret keys. This may
  360. entail the use of couriers or other costly, inefficient and not
  361. really secure methods. In contrast, if keys are public the task of
  362. key management may be substantially simplified. 
  363.  
  364.    An ideal system might solve all of these problems concurrently,
  365. i.e., using public keys; providing secrecy; and providing
  366. authenticity. Unfortunately no single technique proposed to date
  367. has met all three criteria. Conventional systems such as DES
  368. require management of secret keys; systems using public key
  369. components may provide authenticity but are inefficient for bulk
  370. encryption of data due to low bandwidths.
  371.  
  372.    Fortunately, conventional and public-key systems are not
  373. mutually exclusive; in fact they can complement each other. Public-
  374. key systems can be used for signatures and also for the
  375. distribution of keys used in systems such as DES. Thus it is
  376. possible to construct hybrids of conventional and public-key
  377. systems which can meet all of the above goals: secrecy,
  378. authenticity and ease of key management.
  379.  
  380.    For surveys of the preceding and related topics see, e.g.,
  381. ([BRAS88],[COPP87],[DENN83],[DIFF82],[DIFF79],[KLIN79],[KONH81],
  382. [LEMP79],[MASS88],[MERK82],[POPE78],[POPE79],[SALO85],[SIMM79]).
  383. More specialized discussions of public-key cryptography are given,
  384. e.g., in ([DIFF88],[LAKS83],[MERK82b]). Mathematical aspects are
  385. covered, e.g., in ([KRAN86],[PATT87]).
  386.  
  387.    In the following, E and D represent encryption and decryption
  388. transformations, respectively. It is always required that D(E(M))
  389. = M. It may also be the case that E(D(M)) = M; in this event E or
  390. D can be employed for encryption. Normally D is assumed to be
  391. secret, but E may be public. In addition it may be assumed that E
  392. and D are relatively easy to compute when they are known.
  393.  
  394.  
  395.    1.1 Requirements for secrecy.
  396.  
  397.  
  398.    Secrecy requires that a cryptanalyst (i.e., a would-be intruder
  399. into a cryptosystem) should not be able to determine the plaintext
  400. corresponding to given ciphertext, and should not be able to
  401. reconstruct D by examining ciphertext for known plaintext. This
  402. translates into two requirements for a cryptosystem to provide
  403. secrecy:
  404.  
  405.  
  406.       a. A cryptanalyst should not be able to determine M from   
  407.           E(M); i.e., the cryptosystem should be immune to       
  408.            ciphertext-only attacks.
  409.  
  410.       b. A cryptanalyst should not be able to determine D given  
  411.           {E(Mi)} for any sequence of plaintexts {M1,M2,...};      
  412.           i.e. the cryptosystem should be immune to known-plaintext 
  413.          attacks. This should remain true even when the          
  414.           cryptanalyst can choose {Mi} (chosen-plaintext attack), 
  415.           including the case in which the cryptanalyst can inspect 
  416.          {E(M1),...,E(Mj)} before specifying Mj+1 (adaptive        
  417.           chosen-plaintext attack).
  418.  
  419.  
  420.    Adaptive chosen plaintext attack is illustrated below.
  421.  
  422.  
  423.                         ____________________
  424.                        |                    |
  425.                        |       i = 0        |
  426.                        |____________________|
  427.                                  |     ____________
  428.                                  |    |            |
  429.                                  |/___| i := i + 1 |/___
  430.                                  |\   |____________|\  /|\  
  431.                                  |                      |
  432.                         ________\|/_________            |
  433.                        |                    |           |
  434.                        |  choose M(i+1)     |           |
  435.                        |____________________|           |
  436.                                  |                      |
  437.                                  |                      |
  438.                         ________\|/_________            |
  439.                        |                    |           |
  440.                        |  compute E(M(i+1)) |           |
  441.                        |____________________|           |
  442.                                  |                      |
  443.                                  |                      |
  444.                     ____________\|/_______________      |
  445.                    |                              |     |
  446.                    | inspect E(M(1)),..,E(M(i+1)) |     |
  447.                    |______________________________|     |
  448.                                  |                      |
  449.                                  |                      |
  450.                                 \|/                     |
  451.                                 / \                     |
  452.                                /   \___________________\|  
  453.                                \   /   continue        /
  454.                                 \ /
  455.                                  |
  456.                             stop |
  457.                                 \|/
  458.  
  459.  
  460.               Figure 1. Adaptive Chosen Plaintext Attack
  461.                 
  462.  
  463.    To illustrate the difference between these two categories, we
  464. use two examples. First, suppose E(M) = M3 mod N, N = p * q, where
  465. p and q are large secret primes. Then (cf. sec. 4) it is infeasible
  466. for a cryptanalyst to determine D, even after inspecting numerous
  467. pairs of the form {M,E(M)}. However, an eavesdropper who intercepts
  468. E(M) = 8 can conclude M = 2. Thus a ciphertext-only attack may be
  469. feasible in an instance where known- or chosen-plaintext attack is
  470. not useful.
  471.  
  472.    On the other hand, suppose E(M) = 5M mod N where N is secret.
  473. Then interception of E(M) would not reveal M or N; this would
  474. remain true even if several ciphertexts were intercepted. However,
  475. an intruder who learns that E(12) = 3 and E(16) = 4 could conclude
  476. N = 19. Thus a known- or chosen-plaintext attack may succeed where
  477. a ciphertext-only attack fails.
  478.  
  479.    Deficiencies in (a), i.e., vulnerability to ciphertext-only
  480. attack, can frequently be corrected by slight modifications of the
  481. encoding scheme, as in the M3 mod N encoding above. Adaptive
  482. chosen-plaintext is often regarded as the strongest attack.
  483.  
  484.    Secrecy ensures that decryption of messages is infeasible.
  485. However, the enciphering transformation E is not covered by the
  486. above requirements; it could even be public. Thus secrecy, per se,
  487. leaves open the possibility that an intruder could masquerade as
  488. a legitimate user, or could compromise the integrity of a message
  489. by altering it. That is, secrecy does not imply authenticity/
  490. integrity.
  491.  
  492.  
  493.    1.2 Requirements for authenticity and integrity.
  494.  
  495.  
  496.    Authenticity requires that an intruder should not be able to
  497. masquerade as a legitimate user of a system. Integrity requires
  498. that an intruder should not be able to substitute false ciphertext
  499. for legitimate ciphertext. Two minimal requirements should be met
  500. for a cryptosystem to provide these services:
  501.  
  502.  
  503.       a. It should be possible for the recipient of a message to 
  504.           ascertain its origin.
  505.  
  506.       b. It should be possible for the recipient of a message to 
  507.           verify that it has not been modified in transit.
  508.  
  509.  
  510.    These requirements are independent of secrecy. For example, a
  511. message M could be encoded by using D instead of E. Then assuming
  512. D is secret, the recipient of C = D(M) is assured that this message
  513. was not generated by an intruder. However, E might be public; C
  514. could then be decoded by anyone intercepting it.
  515.  
  516.    A related service which may be provided is nonrepudiation; i.e.,
  517. we may add a third requirement if desired:
  518.  
  519.  
  520.       c. A sender should not be able to deny later that he sent a 
  521.          message.
  522.  
  523.  
  524.    We might also wish to add:
  525.  
  526.  
  527.       d. It should be possible for the recipient of a message to 
  528.          detect whether it is a replay of a previous transmission.
  529.  
  530.  
  531.    1.3 Conventional systems.
  532.  
  533.  
  534.    In a conventional cryptosystem, E and D are parameterized by a
  535. single key K, so that we have DK(EK(M)) = M. It is often the case
  536. that the algorithms for obtaining DK and EK from K are public,
  537. although both EK and DK are secret. In this event the security of
  538. a conventional system depends entirely on keeping K a secret. Then
  539. secrecy and authenticity are both provided: if two parties share
  540. a secret K, they can send messages to one another which are both
  541. private (since an eavesdropper cannot compute DK(C)) and
  542. authenticated (since a would-be masquerader cannot compute EK(M)).
  543. In some cases (e.g., transmission of a random bit string), this
  544. does not assure integrity; i.e., modification of a message en route
  545. may be undetected. Typically integrity is provided by sending a
  546. compressed form of the message (a message digest) along with the
  547. full message as a check.
  548.  
  549.    Conventional systems are also known as one-key or symmetric
  550. systems [SIMM79].
  551.  
  552.  
  553.    1.4 Example of a conventional cipher: DES.
  554.  
  555.  
  556.    The most notable example of a conventional cryptosystem is DES
  557. (Data Encryption Standard). It is well-documented (e.g.
  558. [DENN83],[EHRS78],[NATI77],[NATI80],[NATI81],[SMID81],[SMID88b])
  559. and will not be discussed in detail here, except to contrast it
  560. with other ciphers. It is a block cipher, operating on 64-bit
  561. blocks using a 56-bit key. Essentially the same algorithm is used
  562. to encipher or decipher. The transformation employed can be written
  563. P-1(F(P(M))), where P is a certain permutation and F is a certain
  564. function which combines permutation and substitution. Substitution
  565. is accomplished via table lookups in so-called S-boxes. 
  566.  
  567.    The important characteristics of DES from the standpoint of this
  568. exposition are its one-key feature and the nature of the operations
  569. performed during encryption/decryption. Both permutations and table
  570. lookups are easily implemented, especially in hardware. Thus
  571. encryption rates exceeding 40 Mbit/sec have been obtained (e.g.,
  572. [BANE82],[MACM81]). This makes DES an efficient bulk encryptor,
  573. especially when implemented in hardware. 
  574.  
  575.    The security of DES is produced in classical fashion:
  576. alternation of substitutions and permutations. The function F is
  577. obtained by cascading a certain function f(x,y), where x is 32 bits
  578. and y is 48 bits. Each stage of the cascade is called a round. A
  579. sequence of 48-bit strings {Ki} is generated from the key. Let L(x)
  580. and R(x) denote the left and right halves of x, and let XOR denote
  581. exclusive-or. Then if Mi denotes the output of stage i, we have 
  582.  
  583.  
  584.       L(Mi) = R(Mi-1),
  585.  
  586.       R(Mi) = L(Mi-1) XOR f(L(Mi),Ki).
  587.  
  588.  
  589.    The hope is that after 16 rounds, the output will be
  590. statistically flat; i.e., all patterns in the initial data will be
  591. undetectable. 
  592.  
  593.  
  594.    1.5 Another conventional cipher: exponentiation.
  595.  
  596.  
  597.    Pohlig and Hellman [POHL78] noted a type of cipher which
  598. deviated from the classical methods such as transposition and
  599. substitution. Their technique was conceptually much simpler. Let
  600. GCD denote greatest common divisor (app. G). Suppose p > 2 is
  601. a prime and suppose K is a key in [1,p-1) with GCD(K,p-1) = 1
  602. (i.e., K is relatively prime to p-1). If M is plaintext in [1,p-
  603. 1], an encryption function E may be defined by 
  604.  
  605.  
  606.       E(M) = MK  mod p.
  607.  
  608.  
  609.    Now the condition GCD(K,p-1) = 1 implies (lem. G.1) that we can
  610. find I with I * K ≡ 1 (mod p-1). Note that I is not a separate key;
  611. I is easily derived from K or vice-versa (app. H). We may set
  612.  
  613.  
  614.       D(C) = CI  mod p.
  615.  
  616.  
  617.    It may then be shown (cor. G.2.3) that D(E(M)) = M, as required.
  618. Furthermore, E(D(C)) = C as well; i.e., E and D are inverse
  619. functions. This makes exponentiation a versatile cipher; in
  620. particular, we can encipher with D as well as E. Later we will note
  621. that this can be useful in authentication. However, Pohlig and
  622. Hellman used the above only as an example of a conventional
  623. cryptosystem. That is, since I is easily derived from K, both E and
  624. D are generated by the single, secret, shared key K. In section 4.1
  625. we will see that if p were replaced by a product of two primes,
  626. derivation of I from K would be non-trivial. This would cause the
  627. key material to be split into two portions.
  628.  
  629.    Despite the relative simplicity of the definitions of E and D,
  630. they are not as easy to compute as their counterparts in DES. This
  631. is because exponentiation mod p is a more time-consuming operation
  632. than permutations or table lookups if p is large. 
  633.  
  634.    Security of the system in fact requires that p be large. This
  635. is because K should be nondeterminable even in the event of a
  636. known-plaintext attack. Suppose a cryptanalyst knows p, M, C, and
  637. furthermore knows that C = MK mod p for some K. He should still be
  638. unable to find K; i.e., he should not be able to compute discrete
  639. logarithms modulo p. At present there are no efficient algorithms
  640. for the latter operation: the best techniques now available take
  641. time (e.g., [ADLE79],[COPP86])
  642.  
  643.  
  644.       exp(c((log p)(log log p))1/2).
  645.  
  646.  
  647.    Computing modulo p is equivalent to using the Galois field
  648. GF(p); it is possible to use GF(pn) instead (app. G). There are
  649. both advantages and disadvantages to the extension. Arithmetic in
  650. GF(pn) is generally easier if n > 1, and especially so in GF(2n).
  651. On the other hand, taking discrete logarithms in GF(pn) is also
  652. easier. The case of small n is treated in [ELGA85b]. The greatest
  653. progress has been made for the case p = 2 (e.g.,
  654. [BLAK84],[COPP84]). In [COPP84] it is shown that discrete
  655. logarithms in GF(2n) can be computed in time
  656.  
  657.  
  658.       exp(c * n1/3 * (log n)2/3).
  659.  
  660.  
  661.    For a survey of the discrete logarithm problem see, e.g.,
  662. [ADLE86],[COPP87],[MCCU89],[ODLY84b].
  663.  
  664.  
  665.    1.6 Public-key cryptosystems.
  666.  
  667.  
  668.    The notion of public-key cryptography was introduced by Diffie
  669. and Hellman [DIFF76b]; for a history see [DIFF88]. Public-key
  670. systems, also called two-key or asymmetric [SIMM79], differ from
  671. conventional systems in that there is no longer a single secret key
  672. shared by a pair of users. Rather, each user has his own key
  673. material. Furthermore, the key material of each user is divided
  674. into two portions, a private component and a public component. The
  675. public component generates a public transformation E, and the
  676. private component generates a private transformation D. In analogy
  677. to the conventional case E and D might be termed encryption and
  678. decryption functions, respectively. However, this is imprecise: in
  679. a given system we may have D(E(M)) = M, E(D(M)) = M, or both.
  680.  
  681.    A requirement is that E must be a trapdoor one-way function.
  682. One-way refers to the fact that E should be easy to compute from
  683. the public key material but hard to invert unless one possesses the
  684. corresponding D, or equivalently, the private key material
  685. generating D. The private component thus yields a "trapdoor" which
  686. makes the problem of inverting E seem difficult from the point of
  687. view of the cryptanalyst, but easy for the (sole legitimate)
  688. possessor of D. For example, a trapdoor may be the knowledge of the
  689. factorization of an integer (see sec. 4.1). 
  690.  
  691.    We remark that the trapdoor functions employed as public
  692. transformations in public-key systems are only a subclass of the
  693. class of one-way functions. The more general case will be discussed
  694. in section 3.2.2.
  695.  
  696.    We note also that public/private dichotomy of E and D in public-
  697. key systems has no analogue in a conventional cryptosystem: in the
  698. latter, both EK and DK are parameterized by a single key K. Hence
  699. if EK is known then it may be assumed that K has been compromised,
  700. whence it may also be assumed that DK is also known, or vice-
  701. versa. For example, in DES, both E and D are computed by
  702. essentially the same public algorithm from a common key; so E and
  703. D are both known or both unknown, depending on whether the key has
  704. been compromised.
  705.  
  706.  
  707.    1.6.1 Secrecy and authenticity.
  708.  
  709.  
  710.    To support secrecy, the transformations of a public-key system
  711. must satisfy D(E(M)) = M. Suppose A wishes to send a secure message
  712. M to B. Then A must have access to EB, the public transformation of
  713. B (note that subscripts refer to users rather than keys in this
  714. context). Now A encrypts M via C = EB(M) and sends C to B. On
  715. receipt, B employs his private transformation DB for decryption;
  716. i.e., B computes DB(C) = DB(EB(M)) = M. If A's transmission is
  717. overheard, the intruder cannot decrypt C since DB is private. Thus
  718. secrecy is ensured. However, presumably anyone can access EB; B has
  719. no way of knowing the identity of the sender per se. Also, A's
  720. transmission could have been altered. Thus authenticity and
  721. integrity are not assured.
  722.  
  723.    To support authentication/integrity, the transformations in a
  724. public-key system must satisfy E(D(M)) = M. Suppose A wishes to
  725. send an authenticated message M to B. That is, B is to be able to
  726. verify that the message was sent by A and was not altered. In this
  727. case A could use his private transformation DA to compute C = DA(M)
  728. and send C to B. Now B can use A's public transformation EA to find
  729. EA(C) = EA(DA(M)) = M. Assuming M is valid plaintext, B knows that
  730. C was in fact sent by A, and was not altered in transit. This
  731. follows from the one-way nature of EA: if a cryptanalyst, starting
  732. with a message M, could find C' such that EA(C') = M, this would
  733. imply that he can invert EA, a contradiction.
  734.  
  735.    If M, or any portion of M, is a random string, then it may be
  736. difficult for B to ascertain that C is authentic and unaltered
  737. merely by examining EA(C). Actually, however, a slightly more
  738. complex procedure is generally employed: an auxiliary public
  739. function H is used to produce a digital signature S = DA(H(M))
  740. which A sends to B along with M. On receipt B can compute H(M)
  741. directly. The latter may be checked against EA(S) to ensure
  742. authenticity and integrity, since once again the ability of a
  743. cryptanalyst to find a valid S' for a given M would violate the
  744. one-way nature of EA. Actually H must also be one-way; we return to
  745. this subject in section 3.2.
  746.  
  747.    Sending C or S above ensures authenticity, but secrecy is
  748. nonexistent. In the second scheme M was sent in the clear along
  749. with S; in the first scheme, an intruder who intercepts C = DA(M)
  750. presumably has access to EA and hence can compute M = EA(C). Thus
  751. in either case M is accessible to an eavesdropper.
  752.  
  753.    It may be necessary to use a combination of systems to provide
  754. secrecy, authenticity and integrity. However, in some cases it is
  755. possible to employ the same public-key system for these services
  756. simultaneously. We note that for authenticity/integrity purposes,
  757. D is applied to M or H(M); for secrecy, E is applied to M. If the
  758. same public-key system is to be used in both cases, then D(E(M))
  759. = M and E(D(M)) = M must both hold; i.e., D and E are inverse
  760. functions. A requirement is that the plaintext space (i.e., the
  761. domain of E) must be the same as the ciphertext space (i.e., the
  762. domain of D).
  763.  
  764.    Suppose that in addition to E and D being inverses for each
  765. user, for each pair of users A and B the functions EA, DA, EB, and
  766. DB all have a common domain. Then both secrecy and authenticity can
  767. be accomplished with a single transmission: A sends C = EB(DA(M))
  768. to B; then B computes EA(DB(C)) = EA(DA(M)) = M. An intruder cannot
  769. decrypt C since he lacks DB; hence secrecy is assured. If the
  770. intruder sends C' instead of C, C' cannot produce a valid M since
  771. DA is needed to produce a valid C. This assures authenticity. 
  772.  
  773.    In actuality there are no common systems versatile enough for
  774. the last usage without modification. In fact there is only one
  775. major system (RSA) which satisfies E(D(M)) = D(E(M)) = M. The lack
  776. of a common domain between two users creates a technical problem
  777. in using such a system for secrecy and authenticity. We discuss
  778. some approaches to this problem in section 4.1.
  779.  
  780.    If the question of domains is ignored, the usage of a system
  781. satisfying E(D(M)) = D(E(M)) = M with a hash function H is
  782. illustrated below. There EA,DA,EB,DB are the public transformations
  783. of A and B, respectively.
  784.  
  785.  
  786.  
  787.  
  788.               A:                                 B:
  789.       ____________________                _________________
  790.      |                    |        _____\|                 |
  791.      |    compute H(M)    |      /|\    /|  receive (C,S)  |
  792.      |____________________|       |      |_________________|
  793.                |                  |               |
  794.                |                  |               |
  795.       ________\|/_________        |     _________\|/_________
  796.      |                    |       |    |                     |
  797.      |  compute C = EB(M) |       |    |  compute M' = DB(C) |
  798.      |____________________|       |    |_____________________|
  799.                |                  |               |
  800.                |                  |               |
  801.      _________\|/__________       |     _________\|/_________
  802.     |                      |      |    |                     |
  803.     | compute S = DA(H(M)) |      |    |  compute H' = EA(S) |
  804.     |______________________|      |    |_____________________|
  805.                |                  |               |
  806.                |                  |               |
  807.       ________\|/_________        |     _________\|/_________
  808.      |                    |       |    |                     |
  809.      |  send (C,S) to B   |       |    |  verify H' = H(M')  |   
  810.       |____________________|       |    |_____________________|
  811.                |                  |               
  812.                |                  |     
  813.               \|/________________\|
  814.                                  /
  815.  
  816.  
  817.        Figure 2. Using Public-Key for Secrecy and Authenticity
  818.  
  819.  
  820.    1.6.2 Applicability and limitations.
  821.  
  822.  
  823.    The range of applicability of public-key systems is limited in
  824. practice by the relatively low bandwidths associated with public-
  825. key ciphers, compared to their conventional counterparts. It has
  826. not been proven that time or space complexity must necessarily be
  827. greater for public key systems than for conventional systems.
  828. However, the public-key systems which have withstood cryptanalytic
  829. attacks are all characterized by relatively low efficiency. For
  830. example, some are based on modular exponentiation, a relatively
  831. slow operation. Others are characterized by high data expansion
  832. (ciphertext much larger than plaintext). This inefficiency, under
  833. the conservative assumption that it is in fact inherent, seems to
  834. preclude the use of public-key systems as replacements for
  835. conventional systems utilizing fast encryption techniques such as
  836. permutations and substitutions. That is, using public-key systems
  837. for bulk data encryption is not feasible, at least for the present.
  838.  
  839.    On the other hand, there are two major application areas for
  840. public-key cryptosystems: 
  841.  
  842.  
  843.       a. Distribution of secret keys.
  844.  
  845.       b. Digital signatures.
  846.  
  847.  
  848.    The first involves using public-key systems for secure and
  849. authenticated exchange of data-encrypting keys between two parties
  850. (sec. 2). Data-encrypting keys are secret shared keys connected
  851. with a conventional system used for bulk data encryption. This
  852. permits users to establish common keys for use with a system such
  853. as DES. Classically, users have had to rely on a mechanism such as
  854. a courier service or a central authority for assistance in the key
  855. exchange process. Use of a public-key system permits users to
  856. establish a common key which does not need to be generated by or
  857. revealed to any third party, providing both enhanced security and
  858. greater convenience and robustness.
  859.  
  860.    Digital signatures are a second major application (sec. 3). They
  861. provide authentication, nonrepudiation and integrity checks. As
  862. noted earlier, in some settings authentication is a major
  863. consideration; in some cases it is desirable even when secrecy is
  864. not a consideration (e.g., [SIMM88]). We have already seen an
  865. example of a digital signature, i.e., when A sent DA(M) to B. This
  866. permitted B to conclude that A did indeed send the message. As we
  867. will note in section 3, nonrepudiation is another property
  868. desirable for digital signatures. Public key cryptosystems provide
  869. this property as well.
  870.  
  871.    No bulk encryption is needed when public-key cryptography is
  872. used to distribute keys, since the latter are generally short.
  873. Also, digital signatures are generally applied only to outputs of
  874. hash functions (sec. 3). In both cases the data to be encrypted or
  875. decrypted is restricted in size. Thus the bandwidth limitation of
  876. public-key is not a major restriction for either application.
  877.  
  878.  
  879.    2. Key management. 
  880.  
  881.  
  882.    Regardless of whether a conventional or public-key cryptosystem
  883. is used, it is necessary for users to obtain other users' keys. In
  884. a sense this creates a circular problem: in order to communicate
  885. securely over insecure channels, users must first exchange key
  886. information. If no alternative to the insecure channel exists, then
  887. secure exchange of key information presents essentially the same
  888. security problem as subsequent secure communication.
  889.  
  890.    In conventional cryptosystems this circle can be broken in
  891. several ways. For example, it might be assumed that two users can
  892. communicate over a supplementary secure channel, such as a courier
  893. service. In this case it is often the case that the secure channel
  894. is costly, inconvenient, low-bandwidth and slow; furthermore, use
  895. of a courier cannot be considered truly secure. An alternative is
  896. for the two users to exchange key information via a central
  897. authority. This presumes that each user individually has
  898. established a means of communicating securely with the central
  899. authority. Use of a central authority has several disadvantages as
  900. noted below.
  901.  
  902.    In public-key systems the key management problem is simpler
  903. because of the public nature of the key material exchanged between
  904. users, or between a user and a central authority. Also,
  905. alternatives to the insecure channel may be simpler; e.g., a
  906. physical mail system might suffice, particularly if redundant
  907. information is sent via the insecure (electronic) channel.
  908.  
  909.  
  910.    2.1 Secret-key management.
  911.  
  912.  
  913.    In a conventional (one-key) system, security is dependent on the
  914. secrecy of the key which is shared by two users. Thus two users who
  915. wish to communicate securely must first securely establish a common
  916. key. As noted above, one possibility is to employ a third party
  917. such as a courier; but as remarked there are various disadvantages
  918. to this implementation. The latter is the case even for a single
  919. key exchange. In practice, it may be necessary to establish a new
  920. key from time to time for security reasons. This may make use of
  921. a courier or similar scheme costly and inefficient.
  922.  
  923.    An alternative is for the two users to obtain a common key from
  924. a central issuing authority [BRAN75]. Security is then a major
  925. consideration: a central authority having access to keys is
  926. vulnerable to penetration. Due to the concentration of trust, a
  927. single security breach would compromise the entire system. In
  928. particular, a central authority could engage in passive
  929. eavesdropping for a long period of time before the practice was
  930. discovered; even then it might be difficult to prove.
  931.  
  932.    A second disadvantage of a central issuing authority is that it
  933. would probably need to be on-line. In large networks it might also
  934. become a bottleneck, since each pair of users needing a key must
  935. access a central node at least once. If the number of users is n
  936. then the number of pairs of users wishing to communicate could
  937. theoretically be as high as n(n-1)/2, although this would be highly
  938. unlikely in large networks. Each time a new key is needed, at least
  939. two communications involving the central authority are needed for
  940. each pair of users. Furthermore, such a system may not be robust:
  941. failure of the central authority could disrupt the key distribution
  942. system.
  943.  
  944.    Some of the disadvantages of a central authority can be
  945. mitigated by distributing key distribution via a network of issuing
  946. authorities. One possibility is a hierarchical (tree-structured)
  947. system, with users at the leaves and key distribution centers at
  948. intermediate nodes. However, distributing key management creates
  949. a new security problem, since a multiplicity of entry points for
  950. intruders is created. Furthermore, such a modification might be
  951. inefficient unless pairs of users communicating frequently were
  952. associated to a common subtree; otherwise the root of the tree
  953. would be a bottleneck as before.
  954.  
  955.    Another alternative is a key translation center which requires
  956. only one key-encrypting key exchange through a certification
  957. authority.
  958.  
  959.    Some of these disadvantages can also be mitigated by a public-
  960. key approach to key distribution.
  961.  
  962.  
  963.    2.2 Public distribution of secret keys.
  964.  
  965.  
  966.    It was noted by Diffie and Hellman [DIFF76b] and Merkle [MERK78]
  967. that users can publicly exchange secret keys. This is not related
  968. a priori to public-key cryptography; however, a public-key system
  969. can be used to implement public distribution of secret keys (often
  970. referred to as public key distribution). The underlying public-
  971. key system must support secrecy, for use in key encryption. 
  972.  
  973.    The notion of public distribution of secret keys was originated
  974. in 1974 by Merkle, who proposed a "puzzle" system to implement it
  975. [MERK78]. However, even before this work was published it was
  976. superseded by a public-key scheme supporting public key
  977. distribution [DIFF76b]. This has come to be known as the
  978. Diffie/Hellman exponential key exchange. To begin with, users A and
  979. B are assumed to have agreed upon a common prime p and a common
  980. primitive root g modulo p (app. K). Then (lem. K.2) each number in
  981. [1,p) can be expressed as gx mod p for some x. Both p and g may be
  982. public.
  983.  
  984.    To establish a common secret key, A chooses a random x(A) in
  985. [0,p-1] and B chooses a random x(B) in [0,p-1]; these are kept
  986. secret. Then A computes 
  987.  
  988.  
  989.       y(A) = gx(A) mod p 
  990.  
  991.  
  992. while B computes 
  993.  
  994.  
  995.       y(B) = gx(B) mod p.
  996.  
  997.  
  998.    These need not be secret. Finally A sends y(A) to B and B sends
  999. y(B) to A. Now A knows x(A) and y(B) and can compute 
  1000.  
  1001.  
  1002.       K = y(B)x(A) mod p = gx(B)x(A).
  1003.  
  1004.  
  1005.    Similarly, B knows x(B) and y(A) and can compute 
  1006.  
  1007.  
  1008.       K = y(A)x(B) mod p = gx(A)x(B).
  1009.  
  1010.  
  1011.    The Diffie/Hellman algorithm is illustrated below.
  1012.  
  1013.  
  1014.  
  1015.  
  1016.  
  1017.  
  1018.  
  1019.  
  1020.  
  1021.  
  1022.  
  1023.  
  1024.  
  1025.  
  1026.  
  1027.  
  1028.  
  1029.  
  1030.  
  1031.  
  1032.  
  1033.  
  1034.  
  1035.  
  1036.  
  1037.               A:                                 B:
  1038.         _______________                    _______________
  1039.        |               |                  |               |
  1040.        |   choose xA   |                  |   choose xB   |
  1041.        |_______________|                  |_______________|
  1042.                |                                  |
  1043.                |                                  |
  1044.       ________\|/_________               ________\|/_________
  1045.      |                    |             |                    |
  1046.      | compute yA = g**xA |             | compute yB = g**xB |
  1047.      |____________________|             |____________________|
  1048.                |                                  |
  1049.                |                                  |
  1050.        _______\|/________                ________\|/_________
  1051.       |                  |              |                    |
  1052.       |   send yA to B   |------------->| receive yA from A  |
  1053.       |__________________|              |____________________|
  1054.                |                                  |
  1055.                |                                  |
  1056.       ________\|/________                ________\|/_________
  1057.      |                   |              |                    |
  1058.      | receive yB from B |<-------------|    send yB to A    |
  1059.      |___________________|              |____________________|
  1060.                |                                  |
  1061.                |                                  |
  1062.       ________\|/_________               ________\|/_________
  1063.      |                    |             |                    |
  1064.      | compute K = yB**xA |             | compute K = yA**xB |
  1065.      |____________________|             |____________________|
  1066.  
  1067.  
  1068.               Figure 3. The Diffie/Hellman Key Exchange          
  1069.      
  1070.                                  
  1071.    This establishes K as a secret common quantity which can be used
  1072. in some agreed-upon fashion to generate a secret key. The secrecy
  1073. of this scheme depends, as in section 1.5, on the difficulty of
  1074. computing discrete logarithms. That is, knowing p, g, y and the
  1075. fact that y = gx mod p for some x does not yield x. Thus, if an
  1076. intruder knows p and g and intercepts y(A) or y(B) or both, he
  1077. cannot find x(A) or x(B) and hence cannot compute K. 
  1078.  
  1079.    A disadvantage of this scheme is lack of support for
  1080. authenticity. If an intruder C intercepts y(B), sends y(C) = gx(C)
  1081. mod p to B and B thinks he is receiving y(A), B will inadvertently
  1082. establish a secret key with C. That is, the underlying public-key
  1083. cryptosystem supports secrecy but not authentication. Thus it may
  1084. be desirable to augment a secrecy-providing system with one which
  1085. provides authentication. Examples of the latter will be given
  1086. later.
  1087.    
  1088.    2.3 Management of public components in a public-key system.
  1089.  
  1090.  
  1091.    Prior to using a public-key cryptosystem for establishing secret
  1092. keys, signing messages etc., users A and B must exchange their
  1093. public transformations (EA and EB in sec. 1.6), or equivalently
  1094. their public components. The latter may be regarded as a key
  1095. management problem. It is a simpler problem than establishment of
  1096. secret keys, since public components do not require secrecy in
  1097. storage or transit. Public components can, e.g., be managed by an
  1098. on-line or off-line directory service; they can also be exchanged
  1099. directly by users. However, authenticity is an issue as in the
  1100. previous section. If A thinks that EC is really EB then A might
  1101. encrypt using EC and inadvertently allow C to decrypt using DC. A
  1102. second problem is integrity: any error in transmission of a public
  1103. component will render it useless. Hence some form of error
  1104. detection is desirable. 
  1105.  
  1106.    Regardless of the scheme chosen for public component
  1107. distribution, at some point a central authority is likely to be
  1108. involved, as in conventional systems. However, it may not be
  1109. necessary for the central authority to be on-line; exchange of
  1110. public components between users need not involve the central
  1111. authority. An example of how this can be implemented is given in
  1112. section 2.5. We also note there that the implications of compromise
  1113. of the central authority are not as severe as in the conventional
  1114. case.
  1115.  
  1116.    Validity is an additional consideration: a user's public
  1117. component may be invalidated because of compromise of the
  1118. corresponding private component, or for some other reason such as
  1119. expiration. This creates a stale-data problem in the event that
  1120. public components are cached or accessed through a directory.
  1121. Similar problems have been encountered in management of multi-
  1122. cache systems and distributed databases, and various solutions have
  1123. been suggested. For example, users could be notified immediately
  1124. of key compromises or invalidations. This may be impractical, in
  1125. which case either users should be informed within a given time
  1126. period of changes needed for cached information on public
  1127. components, or users should periodically check with a central
  1128. authority to update validity information. 
  1129.  
  1130.  
  1131.    2.3.1 Use of certificates.
  1132.  
  1133.  
  1134.    A technique to gain a partial solution to both authenticity and
  1135. integrity in distribution of public components is use of
  1136. certificates [KOHN78]. A certificate-based system assumes a central
  1137. issuing authority CA as in the secret-key case. Again it must be
  1138. assumed that each user can communicate securely with the CA. This
  1139. is relatively simple in the present instance: it merely requires
  1140. that each user possess ECA, the public transformation of the CA.
  1141. Then each user A may register EA with the CA. Since EA is public,
  1142. this might be done via the postal service, an insecure electronic
  1143. channel, a combination of these, etc.
  1144.  
  1145.    Normally A will follow some form of authentication procedure in
  1146. registering with the CA. Alternatively, registration can be handled
  1147. by a tree-structured system: the CA issues certificates to local
  1148. representatives (e.g., of employing organizations), who then act
  1149. as intermediaries in the process of registering users at lower
  1150. levels of the hierarchy. An example of such a system is given in
  1151. section 5.4.
  1152.  
  1153.    In any case, in return A receives a certificate signed by the
  1154. CA (see sec. 3 for a more thorough discussion of signatures) and
  1155. containing EA. That is, the CA constructs a message M containing EA,
  1156. identification information for A, a validity period, etc. Then the
  1157. CA computes CERTA = DCA(M) which becomes A's certificate. The latter
  1158. is then a public document which both contains EA and authenticates
  1159. it, since the certificate is signed by the CA. Certificates can be
  1160. distributed by the CA or by users, or used in a hierarchical system
  1161. which we return to later. The inclusion of the validity period is
  1162. a generalization of timestamping. The latter was not treated in
  1163. [KOHN78], but Denning [DENN81] notes the importance of timestamping
  1164. in guarding against the use of compromised keys.
  1165.  
  1166.    In general, the problem of stale data is not wholly solved by
  1167. timestamping: a certificate may be invalidated before its
  1168. expiration date, because of compromise or administrative reasons.
  1169. Hence if certificates are cached by users (as opposed to being re-
  1170. distributed by the CA each time they are used), the CA must
  1171. periodically issue lists of invalidated certificates. Popek and
  1172. Kline [POPE79] have noted that certificates are analogous to
  1173. capabilities in operating systems. Management of certificates
  1174. creates analogous problems, such as selective revocation of
  1175. capabilities. The public nature of certificates, however, a priori
  1176. precludes an analogue of a useful feature of a capability system:
  1177. users cannot be restricted to communicating with a subset of other
  1178. users. If a selective capability feature is desired it must be
  1179. implemented through a controlled distribution of certificates,
  1180. which would be difficult and contrary to the spirit of public-key.
  1181.  
  1182.  
  1183.    2.3.2 Generation and storage of component pairs.
  1184.  
  1185.  
  1186.    Generation of public/private component pairs is an important
  1187. consideration. If this service is offered by a central facility,
  1188. it may result in certain advantages; e.g., keys might be longer or
  1189. chosen more carefully. However, this introduces the same problem
  1190. noted in section 2.1: a central authority holding users' private
  1191. components would be vulnerable to penetration. Also, the central
  1192. facility would have to be trusted not to abuse its holdings by
  1193. monitoring communications between users. Both problems are
  1194. circumvented if users generate and store their own private/public
  1195. components.
  1196.  
  1197.  
  1198.    2.3.3 Hardware support for key management.
  1199.  
  1200.  
  1201.    If users store their own components, a management problem is
  1202. created. One possibility is software storage, e.g., in a file with
  1203. read protection. If greater security is desired, a second option
  1204. is hardware keys ([DENN79],[FLYN78],[RIVE78]). 
  1205.  
  1206.    In the classical version of this scheme, each public/private key
  1207. pair is stored on a pair of ROM chips. The public key is revealed
  1208. to the owner of the keys. However, the private key need not be
  1209. known to any user, including the owner. 
  1210.  
  1211.    There are two advantages to this mode of storage, namely the
  1212. fact that neither the user nor a central authority need know the
  1213. private component. We have previously noted the advantage of not
  1214. having users reveal private keys to a central authority. Also, as
  1215. noted in [FLYN78], it may also be desirable to protect keys from
  1216. disloyal employees. Entering keys from a keyboard rather than from
  1217. ROM may be insecure; moreover, the large size of public keys makes
  1218. this impractical. However, there is also an obvious disadvantage
  1219. to the ROM mode of hardware key storage, namely the fact that the
  1220. party which loads a private key to ROM could retain a copy. An
  1221. alternative, but still classical, scheme is for the user to be
  1222. provided with a means of writing to a memory chip and then sealing
  1223. it from further writing.
  1224.  
  1225.    A more modern and more secure hardware adjunct is a smart token,
  1226. smart card or other device which contains both memory and a
  1227. microprocessor. Such a device can both generate and store user
  1228. keys. Ideally, it should be implemented via a single chip which
  1229. stores both cryptographic algorithms and data.
  1230.  
  1231.    In the classical case, encryption and decryption are handled by
  1232. separate units in a hardware device acting as an interface between
  1233. a user's computer and the network. As noted in [DENN79], this
  1234. creates a security risk: an intruder may rig the device.
  1235.  
  1236.    If a token or smart card is used, it is possible (at least in
  1237. theory; the technology is still evolving at the time of this
  1238. writing) to generate and store keys on the same device which
  1239. executes encryption and decryption algorithms. Again, security is
  1240. optimal if all of these functions are combined onto one or a
  1241. minimal number of chips. Use of such auxiliary devices mitigates
  1242. some of the problems encountered in the classical case. However,
  1243. a token or smart card may be stolen, permitting the thief to
  1244. masquerade as the user. Passwords (PINs) or biometrics used to
  1245. control access to devices can substantially lessen this threat.
  1246.  
  1247.    Capabilities such as signature generation should become feasible
  1248. on devices such as smart cards in the near future. This will
  1249. provide an excellent solution to the problem of using private
  1250. components without exposing them.
  1251.  
  1252.  
  1253.    2.4 Using public-key systems for secret key distribution.
  1254.  
  1255.  
  1256.    As noted earlier, one of the major applications of public-key
  1257. cryptosystems is in regard to public distribution of secret keys.
  1258. Thus, a public-key system can be used in conjunction with a
  1259. conventional system such as DES. We have already seen an example
  1260. of a public-key cryptosystem implementing public key distribution
  1261. in section 2.2. Both secrecy and authentication can be provided
  1262. simultaneously in the distribution process via public-key systems.
  1263. This may be achieved using a single public-key system if its
  1264. encryption and decryption functions are inverses, or via a hybrid
  1265. of two public key systems providing secrecy and authentication
  1266. separately. 
  1267.  
  1268.    The essence of this usage is very simple: a secret key is merely
  1269. a particular form of message. Assuming that a system has been
  1270. established for distribution of public components of users as
  1271. discussed in the previous section, users can then establish secret
  1272. keys at will by employing the public system for encryption and
  1273. signing of secret keys. Thus the latter can be exchanged or changed
  1274. without difficulty. This is in contradistinction to a system in
  1275. which secret keys must be established via couriers or a central
  1276. authority.
  1277.  
  1278.    The use of public-key cryptography thus reduces the problem of
  1279. secret key distribution to the problem of binding user identities
  1280. and user public keys. The latter is a simpler problem in that no
  1281. communication of secret information is necessary. That is, users
  1282. can generate their own private/public key pairs and need not expose
  1283. their private keys to anyone, including themselves. However, it is
  1284. critical that user public keys be properly authenticated. This is
  1285. a nontrivial consideration in large networks.
  1286.  
  1287.    Since only integrity and authenticity are considerations, users
  1288. may be able to register their public components without use of a
  1289. secure channel. In a large network this might require a distributed
  1290. system of certifying authorities, arranged in hierarchical fashion.
  1291. The feasibility of such an approach requires transitivity of trust.
  1292. For example, a central certifying authority could certify a second
  1293. level of certifying agents who in turn certify user public
  1294. components. Other levels could be added as well. Thus a user is
  1295. certified via an authentication path. Such a path need not require
  1296. use of insecure channels if the nodes in the path can communicate
  1297. securely. For example, a user might register with a local
  1298. certifying authority in person. The local authority might be
  1299. affiliated with an organization and may be able to use the user's
  1300. organization ID to certify the user's public key. If the local
  1301. authority can communicate securely with the central authority, the
  1302. user's public key may then be forwarded to the central authority
  1303. for distribution.
  1304.  
  1305.    Assuming that user public components can be certified and
  1306. distributed, two users may use each other's public components to
  1307. establish common keys for use in message encryption, again without
  1308. resort to a secure channel.
  1309.  
  1310.  
  1311.    2.4.1 A protocol for key exchange.
  1312.  
  1313.  
  1314.    Suppose A and B wish to establish a shared secret key. Suppose
  1315. further that they have obtained each other's public components.
  1316. Some possible modes for binding user public keys to user identities
  1317. and distributing certified user public keys are discussed in
  1318. sections 5.3.1 - 5.3.2 and 5.4.6. In any case, A may now generate
  1319. a secret key K. For example, this may be a key-encrypting key to
  1320. be used to exchange session keys and possibly initialization
  1321. vectors if, e.g., DES is used in cipher feedback mode or cipher
  1322. block-chaining mode [NATI80]. Then A might form an expanded message
  1323. which contains K and other data, which could include an
  1324. identification for A, a timestamp, a sequence number, a random
  1325. number, etc. This added material is needed for A to authenticate
  1326. himself to B in real-time, and thus prevent replays. For example,
  1327. Needham and Schroeder [NEED78] suggest a three-way handshake
  1328. protocol:
  1329.  
  1330.    First of all A may send to B the message C = EB(RA,IDA), where EB
  1331. is B's public transformation, IDA is the identification of A, and
  1332. RA is a random number. Now B can decrypt C and obtain IDA. Now B
  1333. generates a random number RB and sends C' = EA(RA,RB) to A. Upon
  1334. decryption of C', A can verify in real time that B has received RA,
  1335. since only B could decrypt C. Finally A sends C" = EB(RB) to B; when
  1336. B decrypts C" he can verify in real time that A has received RB,
  1337. since only A could decrypt C'. Thus A and B are authenticated to
  1338. each other in real time; i.e., each knows that the other is really
  1339. there.
  1340.  
  1341.    Now A sends EB(DA(K)) to B, who can decrypt to obtain K. This
  1342. ensures both secrecy and authenticity in exchange of K. 
  1343.  
  1344.    The authentication stage of the preceding protocol is
  1345. illustrated below.
  1346.   
  1347.  
  1348.  
  1349.  
  1350.  
  1351.  
  1352.               A:                                    B:
  1353.       __________________                   ____________________
  1354.      |                  |          ______\|                    |
  1355.      |     choose RA    |        /|\     /|  receive M from A  |
  1356.      |__________________|         |       |____________________|
  1357.                |                  |                 |
  1358.                |                  |                 |
  1359.    ___________\|/__________       |     ___________\|/___________
  1360.   |                        |      |    |                        
  1361. |
  1362.   |  compute M = EB(RA,IA) |      |    | compute (RA,IA) = EA(M)
  1363. |
  1364.   |________________________|      |    |_________________________|
  1365.                |                  |                 |
  1366.                |                  |                 |
  1367.      _________\|/_________        |         _______\|/_______
  1368.     |                     |       |        |                 |
  1369.     |     send M to B     |______\|        |    choose RB    |
  1370.     |_____________________|      /         |_________________|
  1371.                |                                    |
  1372.                |                                    |
  1373.       ________\|/________               ___________\|/__________
  1374.      |                   |             |                        |
  1375.      | receive M' from B |/_______     | compute M' = EA(RA,RB) |
  1376.      |___________________|\      /|\   |________________________|
  1377.                |                  |                 |           
  1378.                |                  |                 |
  1379.    ___________\|/____________     |        ________\|/________
  1380.   |                          |    |       |                   |
  1381.   | compute (RA,RB) = DA(M') |    |/______|   send M' to A    |
  1382.   |__________________________|     \      |___________________|
  1383.                |                                    |
  1384.                |                                    |
  1385.        _______\|/______                    ________\|/_________
  1386.       |                |            _____\|                    |
  1387.       |    verify RA   |          /|\    /| receive M" from A  |
  1388.       |________________|           |      |____________________|
  1389.                |                   |                |
  1390.                |                   |                |
  1391.      _________\|/_________         |      _________\|/__________
  1392.     |                     |        |     |                      |
  1393.     | compute M" = EB(RB) |        |     | compute RB = DB(M")  |
  1394.     |_____________________|        |     |______________________|
  1395.                |                   |                |
  1396.                |                   |                |
  1397.        _______\|/________          |         ______\|/______
  1398.       |                  |         |        |               |
  1399.       |   send M" to B   |________\|        |   verify RB   |
  1400.       |__________________|        /         |_______________|
  1401.  
  1402.  
  1403.            Figure 4. A Protocol for Real-Time Authentication
  1404.  
  1405.  
  1406.    2.5 Protocols for certificate-based key management.
  1407.  
  1408.  
  1409.    There are a number of different approaches to public-key
  1410. component management and the application to secret key distribution
  1411. (e.g., [KLIN79],[NEED78]). For simplicity we assume a certificate-
  1412. based system. We also assume that a system has been established for
  1413. a central authority to create certificates.
  1414.  
  1415.    
  1416.    2.5.1 Certificate management by a central authority.
  1417.  
  1418.  
  1419.    In a certificate-based public-key system, one possibility is to
  1420. have the central issuing authority manage certificate distribution.
  1421. Suppose the authority CA has created certificates CERTA and CERTB
  1422. for A and B, respectively. These contain EA and EB (or equivalently,
  1423. the public components of A and B) as noted in section 2.3.1.    
  1424.  
  1425.    We may assume that A and B have cached CERTA and CERTB,
  1426. respectively. If A has exchanged certificates with B previously,
  1427. A and B may have each other's certificates cached. If not, then
  1428. there are two ways in which A could obtain B's certificate. The
  1429. simplest is for A to request B's certificate directly from B; this
  1430. is explored in the next section. The advantage of this simple
  1431. approach is that on-line access to a central authority is avoided.
  1432.  
  1433.    On the other hand, if A requests B's certificate directly from
  1434. B, or obtains it from a directory listing, security and integrity
  1435. considerations arise. For example, the certificate A obtains may
  1436. have been recently invalidated. 
  1437.  
  1438.    Thus A may wish to access B's certificate through the CA,
  1439. assuming that the latter is on-line. In this event A requests CERTA
  1440. and CERTB from S. We recall that each CERT has the form DS(M) where
  1441. M contains an E. Thus when A receives the requested certificates,
  1442. he can validate CERTA by computing ES(CERTA) and recovering EA. This
  1443. validates the source of the certificates, thus validating CERTB as
  1444. well. Hence A may retrieve a duly authenticated EB from CERTB. The
  1445. disadvantage is the requirement of an on-line central node; the
  1446. advantage is that A is assured of the instantaneous validity of the
  1447. certificate. Later we will note that this has implications for
  1448. nonrepudiation.
  1449.  
  1450.    Caching of certificates implies that authentication involving
  1451. the CA will not be done regularly. Thus the above procedure will
  1452. only be necessary when two users first communicate, or when
  1453. components are compromised or certificates invalidated. As long as
  1454. the public components involved are valid, secret keys can be
  1455. exchanged at will, although a handshake protocol may still be used
  1456. to ensure real-time authenticity and integrity.
  1457.  
  1458.    An advantage of this mode of key management is that the entire
  1459. process is conducted over insecure channels with excellent
  1460. security. A second advantage is that distribution of certificates
  1461. by a central authority assures that certificates are valid at time
  1462. of receipt. A prerequisite for the proper functioning of such a key
  1463. management system is the existence of a system for binding user
  1464. public keys and identities. Such a system requires distributed
  1465. trust.
  1466.  
  1467.    A disadvantage of this mode of management is that as in section
  1468. 2.1, the central authority may be a bottleneck. The severity is
  1469. mitigated by the fact that a secure channel is not needed, but the
  1470. essential problem is similar.
  1471.  
  1472.    A  more significant disadvantage arises from the concentration
  1473. of trust in one entity [KLIN79]. The security of the central
  1474. authority might be compromised, e.g., by penetration. The fact that
  1475. the central authority does not generally access users' private
  1476. components means that existing messages are not compromised, as
  1477. might be the case in a secret-key system [DIFF82]. However, if an
  1478. intruder accesses the central authority's private component, the
  1479. intruder could forge certificates. Some scenarios for intrusions
  1480. of this sort, explorations of consequences, and means for
  1481. minimizing damage are explored in [DENN83b] and [DIFF88].
  1482.  
  1483.    Merkle [MERK82b] has suggested a tree-structured system as a
  1484. means of coping with the compromise of a central authority.
  1485. However, this scheme is not practical for large networks since the
  1486. tree must be restructured each time the user population changes.
  1487.  
  1488.  
  1489.    2.5.2 Decentralized management.
  1490.  
  1491.  
  1492.    Users may be responsible for managing their own certificates.
  1493. In this event the protocol is much simpler. When A wishes to
  1494. initiate communication (e.g., exchange of a secret key) with B, he
  1495. sends a message to B containing A's certificate, A's
  1496. identification, and other information such as a date, random number
  1497. etc. as described in the protocol in the previous section. This
  1498. message also requests B's certificate. Upon completion of the
  1499. certificate exchange, employing some protocol such as the handshake
  1500. above, A and B will possess each other's authenticated
  1501. certificates. A can validate the certificate CB by computing ES(CB)
  1502. as usual. Then EB may be retrieved. The certificate must contain
  1503. information properly identifying B to A, so that an intruder cannot
  1504. masquerade as B. The certificate must also have a validity period.
  1505. In turn B may proceed similarly.
  1506.  
  1507.    The central authority must periodically issue lists of 
  1508. certificates which have become invalid before their expiration
  1509. dates due to key compromise or administrative reasons. It is likely
  1510. that in a large system this would be done, e.g., on a monthly
  1511. basis. Hence a user receiving a certificate from another user would
  1512. not have complete assurance of its validity, even though it is
  1513. signed by S. Thus this system trades higher efficiency for some
  1514. security loss, compared to the previous scheme.
  1515.  
  1516.    For greater assurance of validity, a user could access a
  1517. centrally-managed list of invalid certificates; presumably these
  1518. would be very current. This would require on-line access to a
  1519. central facility, which would create the same type of bottleneck
  1520. we have noted previously. However, the accesses would be very
  1521. quick, since presumably only a certificate sequence number would
  1522. be transmitted.
  1523.  
  1524.    Yet another on-line possibility would be for the central
  1525. authority to enforce coherence by a global search of cached
  1526. certificates each time a certificate is invalidated. Again there
  1527. is a trade-off of validity assurance and efficiency.
  1528.  
  1529.  
  1530.    2.5.3 A phone-book approach to certificates.
  1531.  
  1532.  
  1533.    Some of the features of the previous schemes could be combined
  1534. in a phone-book approach, using an electronic equivalent such as
  1535. a floppy disk containing certificates. This would optimize ease of
  1536. use since a user could communicate securely with another by
  1537. accessing the latter's certificate very rapidly. However, again the
  1538. central authority would have to issue "hot lists". Periodic
  1539. distribution of the compilations of certificates would be a
  1540. separate management process.
  1541.  
  1542.  
  1543.    Security of such a scheme is clearly in question [KLIN79].
  1544. Phone-book entries might contain errors, or entries could be
  1545. altered. 
  1546.  
  1547.  
  1548.    3. Digital signatures and hash functions.
  1549.  
  1550.  
  1551.    Digital signatures were introduced by Diffie and Hellman
  1552. [DIFF76b]; for surveys see, e.g., [AKL-83],[POPE79],[RABI78]. A
  1553. digital signature is the electronic analogue of a handwritten
  1554. signature. A common feature is that they must provide the
  1555. following:
  1556.  
  1557.  
  1558.       a. A receiver must be able to validate the sender's        
  1559.           signature.
  1560.  
  1561.       b. A signature must not be forgeable.
  1562.  
  1563.       c. The sender of a signed message must not be able to      
  1564.           repudiate it later.
  1565.  
  1566.  
  1567.    We have already seen an example of the usage of digital
  1568. signatures, namely when a central authority signs certificates. In
  1569. this section we are concerned with the signing of arbitrary
  1570. messages.
  1571.  
  1572.    A major difference between handwritten and digital signatures
  1573. is that a digital signature cannot be a constant; it must be a
  1574. function of the document which it signs. If this were not the case
  1575. then a signature, due to its electronic nature, could be attached
  1576. to any document. Furthermore, a signature must be a function of the
  1577. entire document; changing even a single bit should produce a
  1578. different signature. Thus a signed message cannot be altered.  
  1579.  
  1580.    There are two major variants of implementation:
  1581.  
  1582.  
  1583.        a. true signatures.
  1584.  
  1585.        b. arbitrated signatures.
  1586.  
  1587.  
  1588.    In a true signature system, signed messages are forwarded
  1589. directly from signer to recipient. In an arbitrated system, a
  1590. witness (human or automated) validates a signature and transmits
  1591. the message on behalf of the sender. The use of an arbitrator may
  1592. be helpful in event of key compromise as noted below.
  1593.  
  1594.    The notion of authentication by some form of signature can be
  1595. traced back as far as 1952, as noted by Diffie [DIFF88].
  1596. Cryptography was used by the Air Force to identify friendly
  1597. aircraft through a challenge/response system. The protocols
  1598. utilized influenced the development of public-key cryptography by
  1599. Diffie and Hellman [DIFF76b].
  1600.  
  1601.    As we note below, hash functions are useful auxiliaries in this
  1602. context, i.e., in validating the identity of a sender. They can
  1603. also serve as cryptographic checksums (i.e., error-detecting
  1604. codes), thereby validating the contents of a message. Use of
  1605. signatures and hash functions can thus provide authentication and
  1606. verification of message integrity at the same time.
  1607.  
  1608.    Numerous digital signature schemes have been proposed. As noted
  1609. in [DAVI83], a major disadvantage of signature schemes in
  1610. conventional systems is that they are generally one-time schemes.
  1611. A signature is generated randomly for a specific message, typically
  1612. using a large amount of key material, and is not re-usable.
  1613. Furthermore, later resolution of disputes over signed documents
  1614. requires written agreements and substantial bookkeeping on the part
  1615. of the sender and receiver, making it more difficult for a third
  1616. party to adjudicate. A conventional scheme was noted in [DIFF76b]
  1617. (the Lamport/Diffie One-Time Signature) and is refined in [MERK82].
  1618. Some other conventional schemes are DES-based.
  1619.  
  1620.    Public-key schemes supporting authentication permit generation
  1621. of signatures algorithmically from the same key repeatedly,
  1622. although the actual signatures are of course different. That is,
  1623. in a public-key scheme, signatures are a function of the message
  1624. and a long-term key. Hence key material can be re-used many times
  1625. before replacement. This obviates the necessity of special written
  1626. agreements between individual senders and receivers. It also makes
  1627. it easy for a third party to resolve disputes (e.g., involving
  1628. repudiation) later, and simplifies storage and bookkeeping. As we
  1629. note below, the bandwidth limitation of public-key systems is
  1630. minimized by the use of hash functions as auxiliaries.
  1631.  
  1632.    In passing we remark that Goldwasser, Micali and Rivest [GOLD88]
  1633. have proposed a nondeterministic public-key signature scheme which
  1634. incorporates an aspect of conventional schemes: a message does not
  1635. have a unique signature. This scheme is intended to deflect
  1636. adaptive chosen-text attacks, in which an attacker is permitted to
  1637. use a signer as an oracle. In such an attack, the attacker
  1638. specifies a sequence of messages to be signed, and is able to study
  1639. all previous signatures before requesting the next. In the GMR
  1640. scheme, it can be proved that an attacker can gain no information
  1641. by studying any number of signatures no matter how they are
  1642. generated. 
  1643.  
  1644.    However, this security gain is offset to some extent by data
  1645. expansion (high ratio of signature to message size) and a negative
  1646. effect on nonrepudiation. As in the case of the one-time schemes
  1647. discussed earlier, the signatures generated in nondeterministic
  1648. public-key schemes tend to be large in comparison to signatures
  1649. produced by deterministic public-key schemes (i.e., those which
  1650. produce a unique signature for a given message). Adjudication of
  1651. disputes is made difficult by increased bookkeeping and the
  1652. necessity of storing large databases of messages and their
  1653. signatures.
  1654.  
  1655.    In the following we discuss only deterministic public-key
  1656. signature schemes, in which a message has a unique signature.
  1657.  
  1658.  
  1659.    3.1 Public-key implementation of signatures.
  1660.  
  1661.  
  1662.    We have noted previously that, like secret-key systems, public-
  1663. key systems can be used for authentication. There are several
  1664. distinctive features of a public-key implementation of signatures,
  1665. including:
  1666.  
  1667.  
  1668.       a. The possibility of incorporating both secrecy and       
  1669.           authenticity simultaneously, assuming that the system  
  1670.            supports both services.
  1671.  
  1672.       b. The re-use of key material in generating signatures     
  1673.           algorithmically.
  1674.  
  1675.       c. Nonrepudiation of sending is essentially a built-in     
  1676.           service.
  1677.  
  1678.  
  1679.    These features make public-key implementation of signatures very
  1680. efficient and versatile.
  1681.  
  1682.  
  1683.    3.1.1 Signing messages.
  1684.  
  1685.  
  1686.    There are several possible protocols for signing in public-key
  1687. cryptography, depending on the services desired. In the simplest
  1688. case, A simply signs a document M by sending S = DA(M) to B. 
  1689.  
  1690.    If a hash function H is used, A computes S = DA(H(M)) and sends
  1691. both M and S to B. B validates A's signature S by computing H(M)
  1692. = EA(S). We also noted earlier that because EA is a trapdoor one-
  1693. way function, it should not be possible for an intruder to find S'
  1694. such that H(M) = EA(S') for a given message M. Thus A's signature
  1695. cannot be forged. Also, if A attempts to repudiate the M sent to
  1696. B above, B may present M and S to a judge. The judge can access EA
  1697. and hence can verify H(M) = EA(S); assuming the trapdoor DA is
  1698. indeed secret, only A could have sent S. Thus a priori we have
  1699. nonrepudiation (but see below).
  1700.  
  1701.    For both authenticity and secrecy, A could send 
  1702.  
  1703.  
  1704.       M' = EB(M,DA(H(M))) 
  1705.  
  1706.  
  1707. to B; B computes 
  1708.  
  1709.  
  1710.       (M,DA(H(M))) = DB(M')
  1711.  
  1712.  
  1713. and then verifies that
  1714.  
  1715.  
  1716.       H(M) = EA(DA(H(M))).
  1717.  
  1718.  
  1719.    The last protocol is illustrated below.
  1720.  
  1721.  
  1722.               A:                                 B:
  1723.       ____________________               ___________________
  1724.      |                    |        ____\|                   |
  1725.      |  compute H = H(M)  |      /|\   /| receive M' from A |
  1726.      |____________________|       |     |___________________|
  1727.                |                  |               |
  1728.                |                  |               |
  1729.       ________\|/_________        |    __________\|/___________
  1730.      |                    |       |   |                        |
  1731.      |  compute S = DA(H) |       |   | compute (M,S) = DB(M') |
  1732.      |____________________|       |   |________________________|
  1733.                |                  |               |
  1734.                |                  |               |
  1735.      _________\|/__________       |     _________\|/_________
  1736.     |                      |      |    |                     |
  1737.     | compute M' = EB(M,S) |      |    |  compute H' = EA(S) |
  1738.     |______________________|      |    |_____________________|
  1739.                |                  |               |
  1740.                |                  |               |
  1741.       ________\|/_________        |     _________\|/_________
  1742.      |                    |       |    |                     |
  1743.      |    send M' to B    |       |    |  verify H' = H(M)   |
  1744.      |____________________|       |    |_____________________|
  1745.                |                  |
  1746.                |                  |
  1747.               \|/________________\|
  1748.                                  /
  1749.            
  1750.    Figure 5. A Protocol for Signing with Hash Function and Secrecy
  1751.  
  1752.  
  1753.    For nonrepudiation in the last case, B retains DB(M') =
  1754. (M,DA(H(M))). A judge can apply EA to DA(H(M)) and compare to H(M).
  1755. This again assumes common domains for the E's and D's; in section
  1756. 4.1 we will note an example of how this point may be treated in
  1757. practice. In passing we remark that the preceding schemes satisfy
  1758. another desirable property: in the adjudication process, they do
  1759. not compromise security by exposing private components to a judge.
  1760.  
  1761.  
  1762.    3.1.2 The issue of nonrepudiation.
  1763.  
  1764.  
  1765.    Nonrepudiation, i.e., preventing senders from denying they have
  1766. sent messages, is contingent upon users keeping their private
  1767. components secret (e.g., [NEED78],[POPE79]). In the above, if DA
  1768. should be compromised, then A might be able to repudiate messages
  1769. sent even before the compromise. On the other hand, as in the case
  1770. of lost or stolen credit cards, A may still be held liable for
  1771. messages signed before the compromise was reported to a central
  1772. authority. This is an administrative issue, and ultimately a matter
  1773. for litigation; hence it is beyond the scope of cryptography per
  1774. se. However, some partial solutions have been proposed which can
  1775. be incorporated into protocols. Most of these involve use of some
  1776. form of arbitrator, as noted in [DEMI83]. 
  1777.    For example, in [POPE79], notary public machines are employed
  1778. as arbitrators. A general protocol for usage of an arbitrator A
  1779. when U is sending a message M to R is given in [AKL-83]:
  1780.  
  1781.  
  1782.       a. U computes S1 = ER(DU(M)).
  1783.  
  1784.       b. U computes a header m = identifying information.
  1785.  
  1786.       c. U computes S2 = DU(m,S1).
  1787.  
  1788.       d. U sends m and S2 to A.
  1789.  
  1790.       e. A applies EU to S2 and checks the identifying information 
  1791.          in m, thereby verifying the origin of M.
  1792.  
  1793.       f. A computes M' = (m,S1,timestamp).
  1794.  
  1795.       g. A computes S' = DA(M').
  1796.  
  1797.       h. A sends S' to R.
  1798.  
  1799.  
  1800.    As noted above, a copy of S' may also be sent to U.
  1801.  
  1802.    As noted in [POPE78], this type of scheme violates a desirable
  1803. criterion for network protocols, namely point-to-point
  1804. communication. It also requires trusted software, which is
  1805. undesirable.
  1806.  
  1807.    In [BOOT81] the use of a central authority is suggested for this
  1808. purpose. In this scheme, the receiver of a message sends a copy to
  1809. the central authority. The latter can attest to the instantaneous
  1810. validity of the sender's signature; i.e., that it has not been
  1811. reported that the sender's private component has been compromised
  1812. at the time of sending. The value of such testimony is mitigated
  1813. by the necessity of users rapidly reporting key compromise to the
  1814. central authority. Also, the central authority becomes a
  1815. bottleneck.
  1816.  
  1817.    Another partial solution involves timestamps ([DENN81],
  1818. [MERK82b]). This again may involve a network of automated
  1819. arbitrators, but very simple in nature, since they need merely
  1820. timestamp messages. In contrast to the notary publics above,
  1821. however, in [MERK82b] it is suggested that receivers obtain
  1822. timestamps. If a receiver needs to be sure of the validity of a
  1823. signature, he may check the validity of the sender's private
  1824. component by checking with a central authority. As long as the
  1825. received message is timestamped before the validity check, the
  1826. receiver is assured of nonrepudiation. To be legally cohesive,
  1827. however, this system requires the sender to be responsible for
  1828. signing until a compromise of his private component is reported to
  1829. the central authority. In analogy to lost credit cards, this may
  1830. not be a desirable system. Also, it requires an on-line central
  1831. authority and real-time validity checks and timestamps, which may
  1832. again create bottlenecks. Furthermore, such schemes require a
  1833. network-wide clock and are vulnerable to forgery of timestamps, as
  1834. noted in [BOOT81]. 
  1835.  
  1836.    If users are permitted to change their components, a central
  1837. authority should retain past components for use in disputes which
  1838. may arise later. Neither compromise nor change of components of a
  1839. user should cause catastrophic problems in practice, since credit
  1840. card systems have established precedents for protocols, both
  1841. administrative and legal. For example, as noted above, conventions
  1842. have been established for treatment of cases of lost or stolen
  1843. credit cards; presumably analogous procedures could be established
  1844. for component compromise.
  1845.  
  1846.  
  1847.    3.1.3 The issue of proof of delivery.
  1848.  
  1849.  
  1850.    The literature on public-key protocols concentrates on the
  1851. issues of validity of signatures and the effects of key compromise
  1852. on nonrepudiation. However, DeMillo and Merritt [DEMI83] note that
  1853. the inverse of a signature, namely protection against the recipient
  1854. of a message denying receipt, may also be a desired feature of a
  1855. system. It is mentioned as an optional security service in [ISO-
  1856. 87].
  1857.  
  1858.     Both nonrepudiation and proof of delivery must be implemented
  1859. via adjudicable protocols, i.e., protocols which can be verified
  1860. later by a third party. In [DEMI83] it is noted that nonarbitrated
  1861. adjudicable reception protocols are difficult to design. A simple
  1862. handshaking protocol might proceed as follows: 
  1863.  
  1864.  
  1865.       a. A computes X = EB(DA(M)).
  1866.  
  1867.       b. A sends X to B.
  1868.  
  1869.       c. B computes M = EA(DB(X)).
  1870.  
  1871.       d. B computes Y = EA(DB(M)).
  1872.  
  1873.       e. B acknowledges receipt of M by sending Y to A.
  1874.  
  1875.  
  1876.    If this protocol is standard procedure then A can assume
  1877. nonreception unless he receives acknowledgement from B. However,
  1878. to serve as an adjudicable proof-of-reception protocol, B is
  1879. required to acknowledge anything A sends. Then an intruder C could
  1880. proceed as follows:
  1881.  
  1882.  
  1883.       a. C intercepts Y = EA(DB(M)).
  1884.  
  1885.       b. C sends Y to A.
  1886.  
  1887.       c. A thinks that this is a legitimate message from C,      
  1888.  
  1889.          unrelated to his communication with B. Following protocol:
  1890.  
  1891.             c.1. A computes M' = EC(DA(Y)).
  1892.  
  1893.             c.2. A computes Z = EC(DA(M')).
  1894.  
  1895.             c.3. A acknowledges receipt of M' by sending Z to C.
  1896.  
  1897.       d. C computes EB(DC(EA(DC(Z)))) = EB(DC(M')) = EB(DA(Y)) = M.
  1898.  
  1899.  
  1900.    This of course occurs because of step c, in which A is required
  1901. by protocol to acknowledge M' = gibberish. This shows that such an
  1902. automatic protocol may be undesirable. On the other hand, selective
  1903. acknowledgement might have an adverse effect on adjudicability.
  1904.  
  1905.  
  1906.    3.2 Hash functions and message digests.
  1907.  
  1908.  
  1909.    We noted that public-key systems generally encrypt more slowly
  1910. than conventional ciphers such as DES. Other digital signature
  1911. schemes are also relatively slow in general. Furthermore, some
  1912. schemes produce signatures comparable in size to, and in some cases
  1913. larger than, the messages they sign. This results in data expansion
  1914. and effectively lower bandwidth of transmission. Thus it is usually
  1915. not desirable to apply a digital signature directly to a long
  1916. message. On the other hand, we remarked that the entire message
  1917. must be signed. This is seemingly contradictory, but a heuristic
  1918. solution can be obtained by using a hash function as an
  1919. intermediary. 
  1920.  
  1921.    A hash function H accepts a variable-size message M as input and
  1922. outputs a fixed-size representation H(M) of M, sometimes called a
  1923. message digest [DAVI80]. In general H(M) will be much smaller than
  1924. M; e.g., H(M) might be 64 or 128 bits, whereas M might be a
  1925. megabyte or more. A digital signature may be applied to H(M) in
  1926. relatively quick fashion. That is, H(M) is signed rather than M.
  1927. Both M and the signed H(M) may be encapsulated in another message
  1928. which may then be encrypted for secrecy. The receiver may validate
  1929. the signature on H(M) and then apply the public function H directly
  1930. to M and check to see that it coincides with the forwarded signed
  1931. version of H(M). This validates both the authenticity and integrity
  1932. of M simultaneously. If H(M) were unsigned only integrity would be
  1933. assured.
  1934.  
  1935.    A hash function can also serve to detect modification of a
  1936. message, independent of any connection with signatures. That is,
  1937. it can serve as a cryptographic checksum (also known as an MDC =
  1938. manipulation detection code or MAC = message authentication code).
  1939. This may be useful in a case where secrecy and authentication are
  1940. unimportant but accuracy is paramount. For example, if a key is
  1941. sent in unencrypted form, even if the key is only a few hundred
  1942. bits it might be useful to transmit a checksum along with it.
  1943. Another instance where this case arises is when secrecy is provided
  1944. by a system such as DES which does not provide a signature
  1945. capability. An important distinction is that a hash function such
  1946. as a MAC used in connection with a conventional system is typically
  1947. parameterized by a secret shared key, although the latter may be
  1948. distinct from the session key used in transmitting the message and
  1949. its MAC. In contrast, hash functions used in connection with
  1950. public-key systems should be public and hence keyless.
  1951.  
  1952.    Earlier we referred to the use of hash functions as a
  1953. "heuristic" solution to the problem of signing long messages. This
  1954. refers to the fact that the signature for a message should be
  1955. unique, but it is theoretically possible that two distinct messages
  1956. could be compressed into the same message digest (a collision). The
  1957. security of hash functions thus requires collision avoidance.
  1958. Collisions cannot be avoided entirely, since in general the number
  1959. of possible messages will exceed the number of possible outputs of
  1960. the hash function. However, the probability of collisions must be
  1961. low. If a function has a reasonably random output, the probability
  1962. of collisions is determined by the output size.
  1963.  
  1964.    A hash function must meet at least the following minimal
  1965. requirement to serve the authentication process properly: it must
  1966. not be computationally feasible to find a message which hashes to
  1967. the same digest as a given message. Thus, altering a message will
  1968. change the message digest. This is important to avoid forgery. 
  1969.  
  1970.    In many settings this minimal requirement is regarded as too
  1971. weak. Instead, the requirement is added that it should not be
  1972. possible to find any two strings which hash to the same value. We
  1973. return to the distinction between these two criteria in section
  1974. 3.2.3.
  1975.  
  1976.  
  1977.    3.2.1 Usage of hash functions.
  1978.  
  1979.  
  1980.    In a public-key system augmented by a hash function H, A might
  1981. send a message M to B as follows: for simplicity ignore secrecy
  1982. considerations. Then A sends M and S = DA(H(M)) to B. The latter
  1983. uses EA to retrieve H(M) from S, then computes H(M) directly and
  1984. compares the two values for authentication. For nonrepudiation, B
  1985. retains M, H(M) and S. If A attempts to repudiate M, a judge can
  1986. use the three items to resolve the dispute as before: he computes
  1987. H(M) = EA(S) and recomputes H(M) from M. If B could find M' with
  1988. H(M') = H(M), B could claim A sent M'. A judge receiving M', H(M)
  1989. and S would reach a false conclusion. 
  1990.  
  1991.    
  1992.    3.2.2 Relation to one-way functions.
  1993.  
  1994.  
  1995.    Merkle [MERK82] defines a hash function F to be a transformation
  1996. with the following properties:
  1997.  
  1998.  
  1999.       a. F can be applied to an argument of any size.
  2000.  
  2001.       b. F produces a fixed-size output.
  2002.  
  2003.       c. F(x) is relatively easy to compute for any given x.
  2004.  
  2005.       d. For any given y it is computationally infeasible to find 
  2006.           x with F(x) = y.
  2007.  
  2008.       e. For any fixed x it is computationally infeasible to find 
  2009.          x' ■ x with F(x') = F(x).
  2010.  
  2011.  
  2012.    The most important properties are (d) and (e). In particular,
  2013. (e) guarantees that an alternative message hashing to the same
  2014. value as a given message cannot be found. This prevents forgery and
  2015. also permits F to function as a cryptographic checksum for
  2016. integrity. Actually (e) can be strengthened as we note momentarily.
  2017.  
  2018.    Property (d) states that F is a one-way function (e.g.,
  2019. [DIFF76b]). One-way functions are used in various other contexts
  2020. as well. For example, we noted earlier that the security of public-
  2021. key systems depends on the fact that the public transformations are
  2022. trapdoor one-way functions. Trapdoors permit decoding by
  2023. recipients. In contrast, hash functions are one-way functions which
  2024. do not have trapdoors. 
  2025.  
  2026.    The concept of (non-trapdoor) one-way functions originated in
  2027. connection with log-in procedures ([WILK68] p. 91): Needham noted
  2028. that if passwords were stored encrypted under a one-way function,
  2029. a list of encrypted passwords would be of no use to an intruder
  2030. since the original passwords could not be recovered. When a user
  2031. logged in, the string entered would be encrypted and compared to
  2032. the stored version for authenticity. Essentially the same system
  2033. was rediscovered later in [EVAN74]. 
  2034.  
  2035.    Usage of one-way functions to produce message digests or encrypt
  2036. passwords is very different from use of trapdoor one-way functions
  2037. to generate encryption functions {EA} in a public-key cryptosystem.
  2038. In the latter, (d) above becomes a dichotomy: it is computationally
  2039. infeasible for anyone except A to find M from C = EA(M); but it is
  2040. easy for A, the unique holder of the trapdoor DA, to compute M =
  2041. DA(C).
  2042.  
  2043.    An example of functions which are not one-way are the private
  2044. transformations in public-key systems: anyone can solve S = D(M)
  2045. for M; i.e., M = E(S). This shows that signature schemes are not
  2046. one-way functions; i.e., they do not satisfy (d) above. On the
  2047. other hand, a deterministic signature function S satisfies (e)
  2048. above; i.e., messages have unique signatures. For example, if a
  2049. signature is generated via S = D(M) where D is a decryption
  2050. function of a public-key system, then D(M) = D(M') implies E(D(M))
  2051. = M = E(D(M')) = M', so (e) is trivially satisfied.
  2052.  
  2053.    Merkle's requirements above are that a hash function must be
  2054. both one-way (d) and effectively collisionless (e). In order to
  2055. satisfy (a) and (b) concurrently, collisions must exist; (e)
  2056. requires that a cryptanalyst should not be able to find them. This
  2057. notion is amenable to further refinement.
  2058.  
  2059.  
  2060.    3.2.3 Weak and strong hash functions.
  2061.  
  2062.  
  2063.    The security of hash functions can be refined further: we may
  2064. distinguish between weak and strong hash functions. A function
  2065. satisfying (a) - (e) of the previous section may be termed a weak
  2066. hash function. Property (e) characterizes weak hash functions; it
  2067. states that a cryptanalyst cannot find a second message producing
  2068. the same message digest as a fixed message. On the other hand, H
  2069. may be termed a strong hash function if (a) - (d) still hold, but
  2070. (e) is modified as follows: it is computationally infeasible to
  2071. find any {x1,x2} with H(x1) = H(x2).
  2072.  
  2073.    Strong and weak functions may often be obtained from the same
  2074. class of functions. Strong functions are then characterized by
  2075. larger message digests, which reduce the probability of collisions.
  2076. Strong functions are thus more secure, but the longer message
  2077. digests are likely to increase time needed to hash.
  2078.  
  2079.    Although the two definitions above are superficially similar,
  2080. computationally they are quite different. For example, suppose H
  2081. is a hash function with an 80-bit output. Suppose a cryptanalyst
  2082. starts with a fixed message M and wishes to find a second message
  2083. M' with H(M) = H(M'). Assuming that the 280 outputs of H are totally
  2084. random, any candidate M' has a probability of only 2-80 of meeting
  2085. the required condition. More generally, if the cryptanalyst tries
  2086. k candidates, the probability that at least one candidate satisfies
  2087. H(M) = H(M') is 1-(1-2-80)k which is about 2-80k by the binomial
  2088. theorem if the latter is small. For example, the cryptanalyst will
  2089. probably have to compute H for about k = 274 = 1022 values of M' to
  2090. have even one chance in a million of finding one M' which collides
  2091. with M. Thus H is secure in the weak sense. 
  2092.  
  2093.    Suppose for the same H the cryptanalyst merely seeks any values
  2094. {M1,M2} with H(M1) = H(M2). By example F.1, if he examines H(M) for
  2095. at least 1.17 * 240 < 2 * 1012 random values of M, the probability
  2096. of at least one collision exceeds 1/2. A supercomputer could
  2097. probably find M1 and M2 with H(M1) = H(M2) in at most a few days.
  2098. Thus H is not secure in the strong sense.
  2099.  
  2100.    The latter attack is called a birthday attack (app. F). It
  2101. should be noted that finding a collision H(x) = H(y) gives the
  2102. cryptanalyst no valuable information if x and y are random bit
  2103. strings. For a purpose such as forgery an adversary may need to
  2104. generate a large number (e.g. 1012 above) of variations of a message
  2105. to find two which collide. Inclusion of timestamps or sequence
  2106. numbers in messages, according to a fixed format, may make it
  2107. computationally infeasible to find a collision of use to an
  2108. adversary.
  2109.  
  2110.  
  2111.    3.3 Digital signatures and certificate-based systems.
  2112.  
  2113.  
  2114.    We previously noted that digital signatures can be employed for
  2115. authentication in the process of distributing public components in
  2116. public-key systems. In particular, if the system is certificate-
  2117. based, the central issuing authority can sign certificates
  2118. containing public components. 
  2119.  
  2120.    The notion of a central authority can be extended to a
  2121. hierarchical (tree) structure. The central authority serves as the
  2122. root of the tree; leaves represent users. Intermediate nodes may
  2123. also be users. Typically the intermediate nodes will be arranged
  2124. in several levels representing, e.g., organizations and
  2125. organizational units. Each node of the tree is responsible for
  2126. authenticating its children. Thus an authentication path is created
  2127. for each node, ending at the root. For example, the central
  2128. authority may certify an organization; the organization may certify
  2129. a unit; the unit may certify an individual user. Certification may
  2130. be accomplished by having a parent node sign a certificate for the
  2131. child node. To validate another user's certificate, a user may
  2132. request the entire authentication path.
  2133.  
  2134.    It is also possible for the tree to be replaced by a forest. For
  2135. example, in a multinational system there may be a different tree 
  2136. for each country. In this event the roots must certify each other.
  2137. An authentication path may then pass through two or more roots.
  2138.  
  2139.    More generally, an authentication structure can be an arbitrary
  2140. directed graph, with a directed edge from A to B if A certifies B.
  2141. Then authentication paths may be constructed by conjoining directed
  2142. paths from two users to a common trusted node; an example of this
  2143. more complex structure is given in section 5.3.
  2144.  
  2145.  
  2146.    4. Examples of public-key systems and hash functions.
  2147.  
  2148.  
  2149.    Numerous public-key systems have been proposed. These may be
  2150. divided into several categories:
  2151.  
  2152.  
  2153.       a. Systems which have been broken.
  2154.  
  2155.       b. Systems which are considered secure.
  2156.  
  2157.          b.1. Systems which are of questionable practicality.
  2158.  
  2159.          b.2. Systems which are practical.
  2160.  
  2161.               b.2.1. Systems suitable for key distribution only.
  2162.  
  2163.               b.2.2. Systems suitable for digital signatures only.
  2164.  
  2165.               b.2.3. Systems suitable for key distribution and   
  2166.                       digital signatures.
  2167.  
  2168.  
  2169.    From the standpoint of sheer numbers, most systems have proven
  2170. to be insecure. This is unfortunate, since some of the techniques
  2171. producing insecure systems have relatively high bandwidths, where
  2172. bandwidth refers to rates of encryption/decryption. Knapsack
  2173. ciphers are an example (sec. 4.2.1, app. E)) of high-bandwidth but
  2174. generally insecure systems. Of the systems which have not been
  2175. broken, many are regarded as impractical for reasons such as large
  2176. key sizes or large data expansion (ciphertext much larger than
  2177. plaintext). 
  2178.  
  2179.    Only a relative handful of systems are widely-regarded as secure
  2180. and practical. In particular, a cryptosystem is usually regarded
  2181. as secure if breaking it is essentially equivalent to solving a
  2182. long-standing mathematical problem which has defied all attempts
  2183. at solution. 
  2184.  
  2185.    Of the well-known systems which are generally regarded as secure
  2186. and practical, some are limited to digital signatures and hence
  2187. unsuitable for public key distribution (e.g. sec. 4.2.2). On the
  2188. other hand, in instances such as the Diffie/Hellman exponential
  2189. exchange scheme (sec. 2.2), public key distribution is supported
  2190. but authentication is not. Such systems may need augmentation by
  2191. a system which supports signatures. The only well-known system
  2192. discovered to date which is secure, practical and suitable for both
  2193. secrecy and authentication is described in section 4.1.
  2194.  
  2195.    Category (b.2.3) above could in theory be further subdivided
  2196. into systems with relatively low and high bandwidths, but there are
  2197. no well-known examples with high bandwidths. There does not exist
  2198. a secure, practical system suitable for key distribution and
  2199. digital signatures, and with high enough bandwidth to support bulk
  2200. data encryption. Prospects for creating radically new systems seem
  2201. dim; in fact, as noted in [DIFF88], most of the extant systems are
  2202. based on a small number of hard mathematical problems:
  2203.  
  2204.  
  2205.        a. discrete exponentiation.
  2206.  
  2207.        b. knapsack problems.
  2208.  
  2209.        c. factoring.
  2210.  
  2211.  
  2212.    According to Diffie, discrete exponentiation was suggested by
  2213. J. Gill, and the use of the knapsack problem by Diffie. A
  2214. suggestion to use factoring was apparently made by Knuth to Diffie
  2215. during the early years of public-key cryptography, but factoring
  2216. was not incorporated into a cryptosystem until several years later
  2217. (sec. 4.1).
  2218.  
  2219.    The knapsack problem is noted briefly in section 4.2.1. The
  2220. other two mathematical problems above are easy to state (though
  2221. also hard to solve):
  2222.  
  2223.  
  2224.       a. If p is a given prime and g and M are given integers, find 
  2225.          x such that gx ≡ M (mod p).
  2226.  
  2227.       b. If N is a product of two secret primes:
  2228.  
  2229.          1. factor N.
  2230.  
  2231.          2. Given integers M and C, find d such that Md ≡ C (mod  
  2232.             N).
  2233.  
  2234.          3. Given integers e and C, find M such that Me ≡ C (mod  
  2235.             N).
  2236.  
  2237.          4. Given an integer x, decide whether there exists an   
  2238.              integer y such that x ≡ y2 (mod N).
  2239.  
  2240.  
  2241.    Gill's suggestion was based on (a), i.e., on the difficulty of
  2242. computing discrete logarithms modulo a prime. This has generated
  2243. systems (e.g. sec. 2.2) suitable for key distribution, and others
  2244. suitable for signatures (e.g. sec. 4.2.2). 
  2245.  
  2246.    Exploitation of the difficulty of factoring has proven to be the
  2247. most versatile approach to design of public-key systems. Factoring
  2248. is widely-regarded as very difficult. If a modulus has unknown
  2249. factorization, various problems in modular arithmetic become
  2250. difficult. For example, discrete logarithm ((b.2) above) is
  2251. difficult, as is taking roots (b.3) and deciding quadratic
  2252. residuosity (b.4). These problems have generated the most widely-
  2253. known public-key system (sec. 4.1) and various others. We remark
  2254. in passing that the probabilistic scheme mentioned in section 3 and
  2255. appendix P are based on (b.4); more generally, quadratic
  2256. residuosity forms the basis of many zero-knowledge schemes.
  2257.  
  2258.    Diffie's knapsack suggestion is one of many attempts to utilize
  2259. NP-complete problems for cryptosystems. Such attempts have met with
  2260. very limited success. We return to this topic and further
  2261. discussion of the above problems later. In the meantime we discuss
  2262. a few of the most well-known public-key systems, along with some
  2263. hash functions.
  2264.  
  2265.  
  2266.    4.1 The RSA public-key scheme.
  2267.  
  2268.  
  2269.    Rivest, Shamir and Adleman [RIVE78] obtained the best-known and
  2270. most versatile public-key cryptosystem. It supports both secrecy
  2271. and authentication, and hence can provide complete and self-
  2272. contained support for public key distribution and signatures.
  2273.  
  2274.    A user chooses primes p and q and computes n = p * q and m = (p-
  2275. 1)(q-1). He then chooses e to be an integer in [1,m-1] with
  2276. GCD(e,m) = 1. He finds the multiplicative inverse of e, modulo m;
  2277. i.e. he finds (app. H) d in [1,m-1] with e * d ≡ 1 (mod m). Now n
  2278. and e are public; d, p, q and m are secret. That is, for a user A,
  2279. nA and eA constitute the public component, and dA, pA, qA the private
  2280. component.
  2281.  
  2282.    After a user has computed p,q,e,d, the private transformation
  2283. D and public transformation E are defined by (see app. M):
  2284.  
  2285.  
  2286.       E(M) = Me mod n,
  2287.  
  2288.       D(C) = Cd mod n.
  2289.  
  2290.  
  2291.    In the above, M and C are in [0,n-1]. As in section 1.5 we have
  2292. D(E(M)) = M and E(D(C)) = C; i.e. D and E are inverses. Since d is
  2293. private, so is D; and since e and n are public, so is E. This
  2294. constitutes a cryptosystem which can be used for both secrecy and
  2295. authentication. That is, for secrecy, A sends EB(M) to B as usual;
  2296. for authentication, A sends DA(M) as usual. For both secrecy and
  2297. authentication, suppose first that message digests are not
  2298. employed. Assuming nA ≤ nB, A computes 
  2299.  
  2300.  
  2301.       C = EB(DA(M)) 
  2302.  
  2303. and sends C to B. Then B recovers M as usual by 
  2304.  
  2305.  
  2306.       M = EA(DB(EB(DA(M)))).
  2307.  
  2308.  
  2309.    This process is illustrated below:
  2310.  
  2311.  
  2312.                  A:                               B:
  2313.     ___________________________           __________________
  2314.    |                           |         |                  |
  2315.    | compute M' = M**eA mod nA |  |----->| receive C from A |
  2316.    |___________________________|  |      |__________________|
  2317.                   |               |                |
  2318.                   |               |                |
  2319.     _____________\|/___________   |   ____________\|/____________
  2320.    |                           |  |  |                          
  2321. |
  2322.    | compute C = M'**dB mod nB |  |  | compute M' = C**eB mod nB
  2323. |
  2324.    |___________________________|  |  |___________________________|
  2325.                   |               |                |
  2326.                   |               |                |
  2327.        __________\|/__________    |   ____________\|/____________
  2328.       |                       |   |  |                          
  2329. |
  2330.       |      send C to B      |   |  | compute M = M'**dA mod nA
  2331. |        |_______________________|   | 
  2332. |___________________________|
  2333.                   |               |               
  2334.                   |               |     
  2335.                  \|/_____________\|
  2336.                                  /
  2337.  
  2338.            Figure 6. Using RSA for Authenticity and Secrecy
  2339.  
  2340.  
  2341.    As noted in section 3.1.1, for nonrepudiation B may retain
  2342. DA(M).
  2343.  
  2344.    This implementation only works because the range of DA is a
  2345. subset of the domain of EB; i.e. [0,nA-1] is a subset of [0,nB-1].
  2346. In the event that nA ≥ nB, Kohnfelder [KOHN78b] notes that A can
  2347. instead transmit 
  2348.  
  2349.  
  2350.       C' = DA(EB(M)).
  2351.  
  2352.  
  2353.    Then B can recover M as
  2354.  
  2355.  
  2356.       M = DB(EA(DA(EB(M)))).
  2357.  
  2358.  
  2359.    This works since the range of EB is a subset of the domain of DA.
  2360. For adjudication of possible disputes, B must retain C' and M. Then
  2361. to prove that A sent M, the judge can compute EA(C') and EB(M) and
  2362. test for equality.
  2363.  
  2364.    However, in [DAVI83] and [DENN83b] it is noted that there is a
  2365. disadvantage to this solution: A signs EB(M) rather than M. In
  2366. section 3.1.1 the judge was able to apply EA to the stored quantity
  2367. DA(M) and M is obtained. In Kohnfelder's protocol both C' and M
  2368. must be stored, doubling the storage requirement.
  2369.  
  2370.    The use of message digests eliminates the preceding problem.
  2371. Suppose H is a hash function. Then to send M to B, A can create a
  2372. new message M' containing M and DA(H(M)) and send C = EB(M') to B.
  2373. This gives both secrecy and authentication; also, C may be retained
  2374. for nonrepudiation. Moreover, M and DA(H(M)) are reblocked in
  2375. forming M', so that no problem arises from the sizes of nA and nb.
  2376.  
  2377.  
  2378.    4.1.1 Choice of p and q.
  2379.  
  2380.  
  2381.    To use the RSA system, a user must first choose primes p and q.
  2382. As noted in section 4.1.3, p and q should at least 75 to 80 decimal
  2383. digits; for the sake of discussion we assume p and q to be on the
  2384. order of about 100 digits. The user begins by choosing a random odd
  2385. b of around 100 digits; b is a candidate for p. Now b is acceptable
  2386. only if b is prime. There are two approaches to this problem. The
  2387. deterministic approach decides with certainty whether b is prime
  2388. (see below). An alternative is to use the probabilistic approach
  2389. as implemented, e.g., by Solovay and Strassen [SOLO77]: randomly
  2390. choose a set of about 100 numbers in [1,b-1]. For each number a in
  2391. the set, test to see if GCD(a,b) = 1, where GCD = greatest common
  2392. divisor. If this condition holds, compute the Jacobi symbol (a/b)
  2393. (app. J). Both GCDs and Jacobi symbols are easy to compute via
  2394. well-known algorithms (app. H,J). Now check to see if
  2395.  
  2396.  
  2397.       (a/b) ≡ a(b-1)/2 (mod b).
  2398.  
  2399.  
  2400.    If b is not prime, this check will fail with probability at
  2401. least 1/2 (app. L). Thus, if 100 random a's are tested and all pass
  2402. the above test, the probability of b not being prime is about 1 in
  2403. 2100. Hence it is possible to test in polynomial time whether b is
  2404. probably a prime. The probability of b being prime is about 1 in
  2405. 115; hence repeated applications of the preceding algorithm will
  2406. probably quickly yield b which is probably a prime. This can be
  2407. taken to be p; a second application of the algorithm will yield q.
  2408.  
  2409.    The Solovay/Strassen algorithm is discussed further in appendix
  2410. L, which also mentions alternative algorithms of Lehman [LEHM82]
  2411. and Miller and Rabin ([MILL76],[RABI80]).
  2412.  
  2413.    The advantage of such probabilistic algorithms is that the
  2414. algorithms run in polynomial time. They do not guarantee a correct
  2415. answer, but the possibility of error is negligible as noted above.
  2416. If absolute certainty were required, deterministic algorithms for
  2417. primality testing could be used ([ADLE83],[COHE87],[COHE84]). These
  2418. guarantee primality, but have runtimes of the form
  2419.  
  2420.  
  2421.       exp(c(log log n)(log log log n)).
  2422.  
  2423.  
  2424.    If a sufficient amount of computing power is available,
  2425. primality of 100-digit numbers can usually be established
  2426. deterministically in minutes. However, the code needed is
  2427. complicated; moreover, most users will not have access to high-
  2428. performance computers. The probabilistic algorithms have acceptable
  2429. run times even on small computers, particularly if hardware support
  2430. is available.
  2431.  
  2432.  
  2433.    4.1.2 Further notes on implementation.
  2434.  
  2435.  
  2436.    Once p and q have been chosen, e is chosen to be relatively
  2437. prime to m = (p-1)(q-1); i.e. GCD(e,m) = 1. For example, e can be
  2438. chosen to be a random small prime > 2. If e is relatively small,
  2439. E(M) can be computed relatively rapidly; i.e. only a small number
  2440. of modular multiplications are needed. The condition GCD(e,m) = 1
  2441. presents no problem; in fact the probability that two random
  2442. numbers are relatively prime is about 3/5 ([KNUT81] p. 324). Now
  2443. d can be found in polynomial time; however, d may be large. Hence
  2444. a version of the Chinese Remainder Theorem is employed for
  2445. decryption (app. M).
  2446.  
  2447.    There are some restrictions on p and q in addition to the size
  2448. specification mentioned above. Some of these are noted in section
  2449. 4.1.3.1. Also, the time and space requirements of RSA are
  2450. considerably larger than, e.g., DES. Storage for each of p, q, and
  2451. d will require at least 300 bits; n is about 600 bits. Only e can
  2452. be chosen to be small. 
  2453.  
  2454.    Exponentiation mod n is a relatively slow operation for large
  2455. n, especially in software. Efficient algorithms for computing
  2456. products mod n have been given, e.g., in [BLAK83], [BRIC82],
  2457. [MONT85] and [QUIS82]. In particular, [BRIC82] shows how
  2458. multiplication mod n can be done in m+7 clock pulses if n is m
  2459. bits. In [MONT85] it is shown how modular multiplication can avoid
  2460. division.
  2461.  
  2462.    At the present time RSA decryption (encryption is slower) with
  2463. a 508-bit modulus has been performed at about 225 Kbits/sec in
  2464. hardware [SHAN90]. Decryption with a 512-bit modulus has been
  2465. effected at about 11 Kbits/sec in software [DUSS90].
  2466.  
  2467.  
  2468.    4.1.3 Security of RSA.
  2469.  
  2470.  
  2471.    The security of the private components in the RSA cryptosystem
  2472. depends on the difficulty of factoring large integers. No efficient
  2473. algorithms are known for this problem. Consequently, knowing n = 
  2474. p * q does not yield p and q. Thus it is computationally infeasible
  2475. to find (p-1)(q-1) = m, and hence the relation e * d ≡ 1 (mod m)
  2476. is useless for determining d from e.
  2477.  
  2478.    The difficulty of computing discrete logarithms (cf. sec. 1.5)
  2479. deflects known-plaintext attacks. Suppose an intruder knows M, C
  2480. and M = D(C) for some plaintext/ciphertext pair {M,C}. To find d
  2481. he must solve M = Cd mod n; i.e., he must find a discrete
  2482. logarithm.
  2483.  
  2484.    Ciphertext-only attacks are equivalent to taking roots modulo
  2485. a composite number with unknown factorization, i.e. solving C = Me
  2486. mod n for M. This is probably about as difficult as discrete
  2487. logarithms, even in the case of square roots (e.g., [ADLE86]). In
  2488. fact (lem. N.3.2; cf. [KNUT81] p. 389, [RABI79]), taking square
  2489. roots modulo such n is, loosely speaking, as hard as factoring n.
  2490.  
  2491.    It should be noted that the security of RSA is not provably
  2492. equivalent to the difficulty of factoring or the other problems
  2493. mentioned here. Also, security of RSA or other public-key systems
  2494. does not preclude breaking specific protocols for their use; see
  2495. e.g. [MOOR88] or [DOLE81]. An example of a protocol failure is
  2496. given in [MOOR88]: suppose two users use a common modulus n and
  2497. encryption exponents e and e' with GCD(e,e') = 1. If the same
  2498. message M is sent to both, then let C = Me mod n and C' = Me' mod n.
  2499. If both C and C' are intercepted, an intruder can find (app. H) r
  2500. and s with r * e + s * e' = 1; now M = Cr * C's mod n.
  2501.  
  2502.    
  2503.    4.1.3.1 Restrictions on p and q. 
  2504.  
  2505.  
  2506.    There are two major restrictions on p and q in order to foil
  2507. attempts at factoring n = p * q: 
  2508.  
  2509.  
  2510.       a. p and q should be about the same length.
  2511.  
  2512.       b. p and q should be at least 75 digits in length.
  2513.  
  2514.  
  2515.    Present factoring methods will be foiled by such a choice. For
  2516. longer-term security, p and q should be, e.g., around 100 digits.
  2517. Condition (a) is needed against the elliptic curve method (see
  2518. below).
  2519.  
  2520.    An attempt to predict the period of time for which a given
  2521. modulus length will remain secure is necessarily guesswork.
  2522. Intelligent guesses are the best that can be hoped for by
  2523. implementors; these are connected with the status of progress in
  2524. factoring, which is highly dynamic.
  2525.  
  2526.  
  2527.    4.1.3.2 Notes on factoring.
  2528.  
  2529.  
  2530.    Choosing n to be about 200 digits will foil any present attempt
  2531. at factoring n. The most powerful general-purpose factoring
  2532. algorithm is Pomerance's quadratic sieve [POME84] and its
  2533. variations. Using a parallel version of the quadratic sieve, Caron
  2534. and Silverman [CARO87] factored 90-digit integers in several weeks
  2535. on a network of several dozen Sun-3's. Recently, 106-digit integers
  2536. have been factored on a larger network [LENS89], using the multiple
  2537. polynomial variant of the quadratic sieve. Recent announcements of
  2538. work in progress indicate that integers of around 116 digits may
  2539. be factored shortly, using the same network used in the 106-digit
  2540. case and another variant of the quadratic sieve.
  2541.  
  2542.    Pomerance, Smith and Tuler [POME88] discuss a prototype of a
  2543. special pipelined architecture, optimized for the quadratic sieve,
  2544. which they claim is extensible to a machine which might factor 125-
  2545. digit integers in a year. However, this presents no threat to 200-
  2546. digit moduli, since all of the best general-purpose factoring
  2547. algorithms known, including the quadratic sieve, run in time
  2548. roughly
  2549.  
  2550.  
  2551.       exp(((log n)(log log n))1/2).
  2552.  
  2553.  
  2554.    The fastest present computers only execute on the order of 1010
  2555. operations per second, at a cost of $10 million or more. Even if
  2556. a future computer reached 1012 operations per second (and presumably
  2557. a cost exceeding $100 million) it would take on the order of 1000
  2558. years to factor a 200-digit number using existing algorithms. 
  2559.  
  2560.     The strongest results on factoring obtained to date have
  2561. utilized networks of computers. The power of such networks is more
  2562. difficult to extrapolate than for supercomputers, since they are
  2563. expandable and the power of personal computers and workstations has
  2564. been rising at a higher rate than at the supercomputer level. In
  2565. theory it would be preferable to know that a cryptosystem would be
  2566. immune to an attack by an assemblage of every computer in the
  2567. universe. It seems difficult to estimate the total amount of
  2568. computing power this would bring to bear; furthermore, the question
  2569. in practice is what fraction of this total amount can be
  2570. realistically allotted to a given factoring problem (cf. app. B).
  2571.  
  2572.    It follows that implementors may have a high level of confidence
  2573. in 200-digit moduli at the present. An interesting issue at the
  2574. time of this writing is whether a modulus with a length between 150
  2575. and 200 digits will provide security for a given length of time.
  2576. It seems certain that 154-digit (i.e., 512-bit) integers will be
  2577. factored eventually, but the question is when. If the preceding
  2578. runtime estimate is used, the conclusion is that 154 digits is
  2579. likely to be secure until the late 1990s, barring major algorithmic
  2580. advances (cf. app. B). RSA moduli of around 512 bits are generally
  2581. preferable to 200 digits (around 660 bits) from a hardware-
  2582. implementation standpoint.
  2583.  
  2584.    A potential qualifier to the preceding analysis is that the
  2585. above runtime estimate is generic; in particular it assumes that
  2586. runtime is essentially independent of the integer being factored.
  2587. However, there are algorithms which have the above as their worst-
  2588. case time. For example, the Schnorr/Lenstra algorithm [SCHN84]
  2589. factors n by using quadratic forms with discriminant -n. The
  2590. equivalence classes of such forms form a group (the class group)
  2591. whose order is denoted by h(-n). The algorithm factors n quickly
  2592. if h(-n) is free of large prime divisors. The algorithm is Monte
  2593. Carlo in the sense that the n's which will be factored quickly are
  2594. evidently fairly random. No algorithms are known to generate class
  2595. numbers with large prime divisors, although interestingly RSA comes
  2596. close: class numbers h(-n) of discriminants n with one or two prime
  2597. factors have a higher probability of having large prime factors
  2598. than the class numbers of discriminants with only small prime
  2599. factors. 
  2600.  
  2601.    The net result is that, e.g., perhaps one in 1000 n's will
  2602. factor 1000 times more quickly than average. If this method were
  2603. practicable it would argue for the 200-digit modulus in RSA.
  2604. However, the Monte Carlo phenomenon has not produced noticeably
  2605. lower factoring times in practice as yet.
  2606.  
  2607.    Some other factoring methods are applicable to numbers which do
  2608. not have the form required for an RSA modulus. For example, the
  2609. elliptic curve method [LENS87] is oriented to integers whose
  2610. second-largest prime factor is considerably smaller than the
  2611. largest prime factor. This motivates the condition that an RSA
  2612. modulus should have factors roughly equal in size. A recent
  2613. algorithm, the number field sieve [LENS90], applies to integers of
  2614. the form rd + s or rd - s where r and s are small. Again this will
  2615. not affect properly-chosen RSA moduli.
  2616.  
  2617.  
  2618.    4.1.4 Low-exponent versions of RSA.
  2619.  
  2620.  
  2621.    A priori the encryption exponent e in the RSA scheme is
  2622. arbitrary. However, it need not be random. It has been suggested
  2623. that e be chosen to have a common value by all users of an RSA-
  2624. based system. Using e = 2 is not feasible per se, since 2 is not
  2625. relatively prime to p-1 or q-1. However, extensions of this type
  2626. have been made. These are of some theoretical interest, since Rabin
  2627. [RABI79] and Williams [WILL80] have noted modifications of RSA with
  2628. exponent 2 for which successful ciphertext-only attacks are
  2629. essentially as difficult as factoring the modulus (app. N). 
  2630.  
  2631.    The exponent 3 can be used directly with RSA. It has the
  2632. advantage of greatly simplifying the encryption (but not the
  2633. decryption) process. In fact Knuth [KNUT81], Rivest [RIVE84] and
  2634. others recommend its usage. However, 3 and other very low exponents
  2635. suffer from some flaws. The case e = 3 is an illustration. For one
  2636. thing, as Knuth notes, users must make certain that each block M
  2637. to be encrypted satisfies M3 >> n. This is because C = M3 mod n
  2638. becomes simply C = M3 if M3 < n; in this event finding M reduces to
  2639. the trivial problem of taking ordinary cube roots of integers. Thus
  2640. the use of e = 3 causes the domain of E to be a subset of [0,n)
  2641. rather than the whole interval as would be preferable.
  2642.  
  2643.    A related but more subtle flaw has also been noted if, e.g., e
  2644. = 3 [HAST88]. Suppose A sends the same message M to each of {Bi},
  2645. i = 1,2,3. Suppose Bi uses modulus ni, and M < ni for each i (this
  2646. will be true, e.g., if the sender uses a modulus smaller than each
  2647. of the {ni}). Assuming that each of {n1,n2,n3} is generated as a
  2648. product of two random primes, the probability of duplicates among
  2649. the 6 primes used is near zero. Hence it may be safely assumed that
  2650. the {ni} are pairwise relatively prime. Let Ci = M3 mod ni. Suppose
  2651. all 3 {Ci} are intercepted. Using the Chinese Remainder Theorem
  2652. (app. I), the intruder can find x in [0,n'), n' = n1 * n2 * n3, with
  2653. x ≡ Ci (mod ni), i = 1,2,3. Thus x ≡ M3 (mod n'). But M3 < n', so M3
  2654. = x, so M = x1/3 (ordinary cube root). Hence the plaintext M can be
  2655. easily recovered from the three ciphertexts. Thus the use of e =
  2656. 3 or other small exponents makes RSA vulnerable to ciphertext-only
  2657. attacks. The sender may attempt to modify M for each recipient to
  2658. deflect this attack, but Hastad shows that more generally, a low
  2659. exponent is vulnerable to linear dependencies in portions of
  2660. messages.
  2661.  
  2662.  
  2663.    4.2 Other public-key systems.
  2664.  
  2665.  
  2666.    Several public-key systems other than RSA have been proposed.
  2667. These are briefly surveyed here. As noted earlier, most of these
  2668. are either insecure, of questionable practicality, or limited to
  2669. one of signatures/secrecy but not both. In some cases their
  2670. security and/or practicality has not been established. None of
  2671. these systems rivals RSA if a combination of versatility, security
  2672. and practicality is the criterion. However, this does not preclude
  2673. the use of the secure systems for specific applications such as
  2674. digital signatures.
  2675.  
  2676.  
  2677.    4.2.1 Knapsack systems.
  2678.  
  2679.  
  2680.    These were proposed by Merkle and Hellman [MERK78b]. However,
  2681. the essence is the use of NP-complete problems (e.g.,
  2682. [GARE79],[HORO78]) which had been suggested for use in designing
  2683. public-key systems in [DIFF76b]. The Merkle/Hellman approach was
  2684. to employ a superincreasing sequence {ai}, i.e., a sequence of
  2685. positive integers for which 
  2686.  
  2687.  
  2688.       ai > ai-1 + ... + a1.
  2689.  
  2690.  
  2691.    The associated knapsack problem [HORO78] is to find nonnegative
  2692. integers {Mi} such that for a given Y,
  2693.  
  2694.  
  2695.       Y = a1 * M1 + ... + an * Mn.
  2696.  
  2697.  
  2698.    The above is an instance of integer programming. In the present
  2699. context the {Mi} are binary; thus the above reduces to sum-of-
  2700. subsets. Solving the above is easy for superincreasing {ai}; in
  2701. fact the solution is unique. However, even deciding existence of
  2702. a solution of sum-of-subsets, or more generally integer
  2703. programming, is NP-complete ([GARE79], pp. 223, 245). Now for any
  2704. w and u satisfying
  2705.  
  2706.  
  2707.       u > a1 + ... + an,
  2708.  
  2709.       GCD(u,w) = 1,
  2710.  
  2711.  
  2712. a disguised knapsack problem may be produced from {ai} by defining
  2713.  
  2714.  
  2715.       bi = w * ai mod u.
  2716.  
  2717.  
  2718.    Then the associated knapsack problem
  2719.  
  2720.  
  2721.       C = b1 * M1 + ... + bn * Mn
  2722.  
  2723.  
  2724. appears to a cryptanalyst to be hard since the {bi} appear random.
  2725. In actuality, it is easily solved using the connection with the
  2726. {ai}: since GCD(w,u) = 1, there exists W (app. H) such that
  2727.  
  2728.  
  2729.       w * W ≡ 1 (mod u).
  2730.  
  2731.  
  2732.    Then
  2733.  
  2734.  
  2735.       W * C ≡ a1 * M1 + ... + an * Mn   (mod u).
  2736.  
  2737.  
  2738.    Since 0 ≤ Mi ≤ 1,
  2739.  
  2740.  
  2741.       0 ≤ a1 * M1 + ... + an * Mn < u,
  2742.  
  2743.  
  2744. from which
  2745.  
  2746.  
  2747.       W * C = a1 * M1 + ... + an * Mn.
  2748.  
  2749.  
  2750.    As noted above, the latter knapsack problem has an easily-found
  2751. unique solution, from which C may be retrieved. This is called a
  2752. trapdoor; it permits a legitimate user to easily solve what appears
  2753. to be a hard problem. The above modular disguise can be iterated;
  2754. i.e., new w' and u' chosen and the {bi} disguised, etc.
  2755.  
  2756.    The trapdoor knapsack yields a public-key system: if the binary
  2757. representation of plaintext M is Mn...M1, let
  2758.  
  2759.  
  2760.       E(M) = b1 * M1 + ... + bn * Mn.
  2761.  
  2762.  
  2763.    If C = E(M) then decrypting C is equivalent to solving what
  2764. appears to be a general knapsack problem, although decryption is
  2765. easy using the trapdoor. The public component is {bi} and the
  2766. private component is u, w and {ai} (see [MERK78b] for details).
  2767.  
  2768.    The advantage is that the arithmetic is much quicker than in
  2769. RSA: about 200 additions are needed, as opposed to about 500
  2770. squarings and 150 multiplications in RSA. In fact knapsacks may
  2771. rival DES in speed [HENR81]. Unfortunately the above knapsack and
  2772. most variations on the above have been broken (Appendix E).
  2773.  
  2774.    It should also be noted that even if a knapsack approach proves
  2775. to be secure and practical, such schemes are generally limited to
  2776. support for either secrecy or authentication but not both. In
  2777. contrast to RSA, the encryption and decryption functions are not
  2778. inverses, although D(E(M)) = M. A trivial example suffices to show
  2779. this: suppose
  2780.  
  2781.  
  2782.       E(M) = 2M1 + 3M2.
  2783.  
  2784.  
  2785.    To be invertible a function must be both injective and
  2786. surjective. However, E is not surjective (onto). For example there
  2787. is no M such that E(M) = 1; hence D(1) is undefined. Thus we could
  2788. not employ D for signatures as in RSA, since, e.g., 1 could not be
  2789. signed by computing D(1). 
  2790.  
  2791.  
  2792.       4.2.2 The ElGamal signature scheme.
  2793.  
  2794.  
  2795.    A signature scheme derived from a modification of exponentiation
  2796. ciphers was proposed by ElGamal [ELGA85].
  2797.  
  2798.    First of all a prime p and a base a which is a primitive root
  2799. modulo p (app. K) are public. Now suppose A wishes to send a signed
  2800. message to B. The private component of A consists of two portions,
  2801. one fixed and the other message-dependent. The fixed portion is a
  2802. random x(A) from [1,p-2]. The public component of A also has fixed
  2803. and message-dependent components. The fixed portion is 
  2804.  
  2805.  
  2806.       y(A) = ax(A) mod p.
  2807.  
  2808.  
  2809.    Now for a given message M in [0,p-1], A chooses a secret k in
  2810. [0,p-1] with GCD(k,p-1) = 1. Thus k is the message-dependent
  2811. portion of A's private component. Also, A finds (app. H) I with 
  2812.  
  2813.  
  2814.        k * I ≡ 1 (mod (p-1)).
  2815.  
  2816.  
  2817.    The message-dependent portion of A's public component consists
  2818. of r and s, where
  2819.  
  2820.  
  2821.       r = ak mod p,
  2822.  
  2823.       s ≡ I * (M - r * x(A))   (mod (p-1)).
  2824.  
  2825.  
  2826.    Now A sends M, r and s to B. For authentication B computes
  2827.  
  2828.  
  2829.       C = aM mod p,
  2830.  
  2831.       C' = y(A)r * rs mod p.
  2832.  
  2833.  
  2834.    We note that
  2835.  
  2836.  
  2837.       M ≡ r * x(A) + k * s   (mod (p-1)).
  2838.  
  2839.  
  2840.    Hence if M is authentic and valid,
  2841.  
  2842.  
  2843.       C = (ax(a))r * (ak)s  mod p = C'.
  2844.  
  2845.  
  2846.    The ElGamal algorithm is illustrated below.
  2847.  
  2848.  
  2849.  
  2850.  
  2851.  
  2852.  
  2853.  
  2854.  
  2855.  
  2856.  
  2857.  
  2858.  
  2859.  
  2860.  
  2861.  
  2862.  
  2863.  
  2864.  
  2865.  
  2866.  
  2867.  
  2868.  
  2869.  
  2870.  
  2871.  
  2872.  
  2873.  
  2874.  
  2875.  
  2876.  
  2877.  
  2878.  
  2879.  
  2880.  
  2881.  
  2882.  
  2883.               A:                                 B:
  2884.       ____________________                _________________
  2885.      |                    |        _____\|                 |
  2886.      |      choose k      |      /|\    /| receive (M,r,s) |
  2887.      |____________________|       |      |_________________|
  2888.                |                  |               |
  2889.                |                  |               |
  2890.      _________\|/__________       |    __________\|/___________
  2891.     |                      |      |   |                        |
  2892.     | find I*k ≡ 1 mod p-1 |      |   | compute C = a**M mod p |
  2893.     |______________________|      |   |________________________|
  2894.                |                  |               |
  2895.                |                  |               |
  2896.     __________\|/___________      |     _________\|/_________
  2897.    |                        |     |    |                     |
  2898.    | compute r = a**k mod p |     |    |  compute C' = yA**r |
  2899.    |________________________|     |    |        * r**s mod p |
  2900.                |                  |    |_____________________|
  2901.                |                  |               |
  2902.                |                  |               |
  2903.     __________\|/___________      |               |
  2904.    |                        |     |               |
  2905.    | compute s = I*(M-r*xA) |     |               |
  2906.    |             mod p-1    |     |               |
  2907.    |________________________|     |               |
  2908.                |                  |               |
  2909.                |                  |               |
  2910.       ________\|/_________        |     _________\|/_________
  2911.      |                    |       |    |                     |
  2912.      |  send (M,r,s) to B |       |    |    verify C' = C    |
  2913.      |____________________|       |    |_____________________|
  2914.                |                  |
  2915.                |                  |
  2916.               \|/________________\|
  2917.                                  /
  2918.  
  2919.               Figure 7. The ElGamal Signature Algorithm
  2920.  
  2921.  
  2922.    A different k must be chosen for each M; using any k twice
  2923. determines x(A) uniquely. The security of the method then depends
  2924. mainly on the difficulty of computing discrete logarithms in GF(p):
  2925. suppose an intruder intercepts M, r and s; a and p are public. Let
  2926. d = ar mod p and u * rs ≡ 1 (mod p). Then the intruder knows 
  2927.  
  2928.  
  2929.       aM ≡ y(A)r * rs  (mod p).
  2930.  
  2931.  
  2932.    Hence
  2933.  
  2934.  
  2935.       u * aM ≡ y(A)r  (mod p).
  2936.  
  2937.  
  2938.    Thus
  2939.  
  2940.  
  2941.       dx(A) ≡ (ax(A))r  ≡ y(A)r  (mod p).
  2942.  
  2943.  
  2944.    Finally
  2945.  
  2946.  
  2947.       dx(A) ≡ u * aM (mod p).
  2948.  
  2949.  
  2950.    Finding x(A), which permits the intruder to masquerade as A, is
  2951. thus equivalent to the above discrete logarithm problem. It is easy
  2952. to solve this problem if p-1 has only small factors [POHL78], hence
  2953. p-1 should have a large prime factor as in RSA. An alternative
  2954. approach is to seek k and m satisfying
  2955.  
  2956.  
  2957.       M = r * x(A) + s * k + (p-1) * m,
  2958.  
  2959.  
  2960. but this is underdetermined, so that there are an exponential
  2961. number of possible solutions to check. A third approach at
  2962. cryptanalysis seeks r and s satisfying
  2963.  
  2964.  
  2965.       aM ≡ y(A)r * rs   (mod p).
  2966.  
  2967.  
  2968.    This is presumably easier than discrete logarithm since r and
  2969. s can both be varied, but it is not clear how much easier. 
  2970.  
  2971.    In comparing this scheme to RSA, we note that both employ
  2972. exponentiation, so that their speeds of encryption/decryption
  2973. should be comparable. Generating keys in the two methods is
  2974. similar; finding appropriate primes is the main step in either.
  2975. Security of ElGamal is more difficult to assess. The major attack
  2976. against RSA, i.e., factorization, is a problem which has been
  2977. studied for centuries. It is safe to say that far less time has
  2978. been invested in attempts to cryptanalyze the ElGamal scheme.
  2979.  
  2980.    Cryptanalytically, the last attack (varying r and s
  2981. simultaneously) may have a complexity substantially lower than
  2982. factoring or discrete logarithm; hence security of ElGamal is at
  2983. best no better than RSA, and possibly much inferior, with respect
  2984. to secrecy of components (it must be emphasized that this is a
  2985. conservative characterization; it could also turn out that no
  2986. substantial advantage is gained by varying r and s simultaneously).
  2987. The use of message-dependent portions of components is a plus and
  2988. minus: it increases bookkeeping, and makes it more difficult for
  2989. a third party to adjudicate a dispute. On the other hand it may
  2990. produce greater security against certain types of attacks. In fact
  2991. the k above could be chosen differently for different blocks of one
  2992. message.
  2993.  
  2994.    In passing we note that, like knapsacks, this scheme goes in one
  2995. direction only: we have in effect 
  2996.  
  2997.  
  2998.       M = E(r,s) = (x(A) * r + k * s) mod (p-1).
  2999.  
  3000.  
  3001.    This maps the ordered pair (r,s) to a unique M. The condition
  3002. GCD(k,p-1) = 1 guarantees that an (r,s) can always be found; i.e.,
  3003. E is surjective. But it is not injective (one-to-one): e.g., if p
  3004. = 7, k = 5, x(A) = 5, then E(1,2) = E(2,1) = 3. Thus text M cannot
  3005. be represented uniquely by a pair (r,s), which would lead to
  3006. ambiguity in an attempt to use this scheme in two directions.
  3007.  
  3008.    Also, ElGamal notes that extension to GF(pn) (app. G) is
  3009. feasible. However, it is not clear that extensions to finite fields
  3010. are desirable (cf. sec. 1.5); gains in efficiency may be offset by
  3011. lower security for comparable key sizes.
  3012.  
  3013.  
  3014.    4.3 Examples of hash functions.
  3015.  
  3016.  
  3017.    To be useful in conjunction with public-key systems, a hash
  3018. function should ideally be keyless. This is in contradistinction
  3019. to message authentication codes used in connection with secret-
  3020. key systems. Several hash functions have been proposed for use in
  3021. public-key settings. A few are mentioned here, but it seems to be
  3022. difficult to produce secure, keyless, efficient hash functions.
  3023. Thus we include some examples of functions which have keys, are
  3024. insecure, or both.
  3025.  
  3026.    
  3027.    4.3.1 Merkle's meta-method.
  3028.  
  3029.  
  3030.    Merkle ([MERK82],[MERK89]) has proposed a general technique for
  3031. obtaining hash functions and digital signatures from existing
  3032. conventional cryptosystems such as DES. Although secret-key systems
  3033. are used as adjuncts, the resulting hash functions are keyless;
  3034. keys needed for DES are generated from the message to be hashed.
  3035. The hash functions are pre-certified in the sense that their
  3036. security can often be proven to be the same as that of the
  3037. underlying conventional function.
  3038.  
  3039.    Merkle assumes that encryption in a system such as DES defines
  3040. a function EK, where K is a key, which produces a random output.
  3041. This is technically impossible, and in fact DES is not a random
  3042. function since it is a permutation. Nonetheless, small deviations
  3043. from randomness may be tolerable. Another requirement is that for
  3044. a given key/plaintext (or ciphertext) pair, the ciphertext (or
  3045. plaintext) returned will not vary with time. Normally a
  3046. cryptosystem would meet this criterion. 
  3047.  
  3048.    Assume that a function EK(M) is available which satisfies these
  3049. requirements. In deference to the potential use of DES to define
  3050. E, assume K is 56 bits, M is 64 bits, and EK(M) is 64 bits. Since
  3051. E may be assumed to be an encryption function, it may be assumed
  3052. that there exists a decryption function with EK(DK(C)) = C. This is
  3053. undesirable in producing one-way hash functions. This problem may
  3054. be mitigated as follows: given a 120-bit input x, write x =
  3055. CAT(K,M) where CAT denotes concatenation, K is the first 56 bits
  3056. of x, and M is the last 64 bits. Let 
  3057.  
  3058.  
  3059.       f(x) = EK(M) XOR M,
  3060.  
  3061.  
  3062. where XOR is exclusive-or. Then f hashes 120 bits to 64 bits.
  3063. Furthermore, Merkle claims that f produces a random output even if
  3064. x is chosen non-randomly. A strong one-way hash function, as
  3065. defined in section 3.2.3, meets this criterion. Thus f might be
  3066. termed a fixed-size strong one-way hash function, with "fixed-
  3067. size" referring to the fact that f does not accept arbitrary
  3068. inputs. 
  3069.  
  3070.    There are various ways in which f can be extended to a one-way
  3071. hash function accepting arbitrary inputs (see [MERK89]).
  3072. Furthermore, it is desirable to have a function which outputs more
  3073. than 64 bits, to deflect "birthday" or "square root" attacks (app.
  3074. F), which are based on the statistical phenomenon that the
  3075. probability of collisions produced when hashing becomes significant
  3076. when the number of items hashed is around the square root of the
  3077. total number of hash function values. 
  3078.  
  3079.    In section 3.2.3 we noted how such attacks affect the security
  3080. of hash functions. For example, a 64-bit output (i.e., 264 hash
  3081. values) would be vulnerable to an attack using only 232 = 4 billion
  3082. messages. On the other hand, a 112-bit output would require
  3083. exhaustive search of on the order of 256 values, producing a
  3084. security level comparable to DES. Merkle discusses several
  3085. constructions for producing an output exceeding 64 bits from f.
  3086. Only the simplest construction will be discussed here. Given an
  3087. input x of 119 bits, let
  3088.  
  3089.  
  3090.       CAT(f(CAT("0",x)),f(CAT("1",x))) = CAT(y,z),
  3091.  
  3092.  
  3093. where y is 112 bits. Then define F0(x) = y. In the above, " "
  3094. denotes constant bit string. We note that F0 hashes 119 bits to 112
  3095. bits. This is not very efficient, but the 112-bit output will deter
  3096. a birthday attack. The latter would require 256 = 7*1016 messages,
  3097. which is computationally infeasible; more precisely, adequate
  3098. computing power to effect a birthday attack would also break DES,
  3099. thereby obliterating DES-based hash functions.
  3100.  
  3101.    This produces F0 which is also a fixed-size strong one-way hash
  3102. function. Finally F0 is extended to a one-way hash function F
  3103. accepting inputs of arbitrary size by cascading copies of F0. Given
  3104. an input x, suppose 
  3105.  
  3106.  
  3107.       x = CAT(x1,...,xn),
  3108.  
  3109.  
  3110. where n is arbitrary and each xi is 7 bits (pad x with a few zeroes
  3111. if need be). Let
  3112.  
  3113.  
  3114.       R0 = 0,
  3115.  
  3116.       Ri = F0(CAT(Ri-1,xi))   (1 ≤ i ≤ n),
  3117.  
  3118.  
  3119. where in the first equation the right side is a string of 112
  3120. zeroes. Let F(x) = Rn.
  3121.  
  3122.    Now Merkle claims that F is as secure as F0. That is, if x ■ x'
  3123. can be found with F(x') = F(x), then F0 can also be broken. The
  3124. proof is inductive: if n = 1 we have F(x) = F0(CAT(0,x)). If F(x)
  3125. = F(x') and x ■ x' let z = CAT(0,x) and z' = CAT(0,x'); then F0(z)
  3126. = F0(z') and z ■ z', so that F0 is broken. Now suppose the claim is
  3127. true for n. Suppose 
  3128.  
  3129.  
  3130.       zi  = CAT(x1,...,xi)      (1 ≤ i ≤ n+1),
  3131.  
  3132.       x   = zn+1,
  3133.  
  3134.       zi' = CAT(x1',...,xi')    (1 ≤ i ≤ n+1),
  3135.  
  3136.       x ' = zn+1',
  3137.  
  3138.       Ri  = F0(CAT(Ri-1,xi))    (1 ≤ i ≤ n+1),
  3139.  
  3140.       Ri' = F0(CAT(Ri-1',xi'))  (1 ≤ i ≤ n+1),
  3141.  
  3142.  
  3143. where each xi and xi' is 7 bits. Suppose x ■ x' but F(x) = F(x'),
  3144. i.e., Rn+1 = Rn+1'. Let y = CAT(Rn,xn+1) and y' = CAT(Rn',xn+1'). Then
  3145. F0(y) = F0(y'). If xn+1 ■ xn+1' then y ■ y' and F0 is broken. Suppose
  3146. xn+1 = xn+1'. Then Rn = Rn'; but zn ■ zn' since x ■ x'. Now we observe
  3147. that by definition Ri = F(zi) and Ri' = F(zi'). Hence F(zn) = F(zn').
  3148. By the induction hypothesis, F0 can be broken, completing the
  3149. proof.
  3150.  
  3151.    A disadvantage of this F is that it hashes 7 bits per stage of
  3152. the cascade, and each stage involves two DES calculations. Thus 3.5
  3153. bits are hashed per DES calculation. Merkle gives other
  3154. constructions which are more complicated but hash up to 17 bits per
  3155. application of DES.
  3156.  
  3157.  
  3158.    4.3.2 Coppersmith's attack on Rabin-type functions.
  3159.  
  3160.  
  3161.    The Merkle meta-method is an attempt to use a conventional
  3162. system as a generator for hash functions. This type of approach has
  3163. its origin in some predecessors which have been broken by
  3164. combinations of birthday attacks and meet-in-the-middle attacks as
  3165. formulated by Coppersmith [COPP85]. 
  3166.  
  3167.    An early attempt to construct a hash function in support of
  3168. signature schemes was given by Rabin [RABI78]. Let H0 be random
  3169. (Rabin uses 0) and suppose a message M is divided into fixed-size
  3170. blocks M1,...,Mn. Suppose E(K,N) represents encryption of block N
  3171. with key K using a conventional system such as DES. For i = 1,..,n
  3172. let 
  3173.  
  3174.  
  3175.       Hi = E(Mi,Hi-1).
  3176.  
  3177.  
  3178.    Then a hash value is given by (H0,Hn). Coppersmith's attack
  3179. assumes that an opponent knows H0 and Hn. He then constructs a bogus
  3180. message whose hash value is also (H0,Hn). Assume blocksize is 64
  3181. bits. The opponent begins by specifying M1,...,Mn-2 using H0. He then
  3182. generates 232 trial values X. For each X he computes a trial Hn-1 of
  3183. the form 
  3184.  
  3185.  
  3186.       H(n-1,X) = E(X,Hn-2).
  3187.  
  3188.  
  3189.    He sorts these 232 values and stores them. Now he generates 232
  3190. trial values Y. For each Y he computes a trial Hn-1 of the form 
  3191.  
  3192.  
  3193.       H'(n-1,Y) = D(Y,Hn),
  3194.  
  3195.  
  3196. where D is the decryption function corresponding to E. We note that
  3197. H(n-1,X) is the value that Hn-1 would have if Mn-1 = X, and H'(n-
  3198. 1,Y) is the value Hn-1 would have if Mn = Y. Each time the opponent
  3199. tries a Y he searches through the sorted H-list (about 32
  3200. operations per search) and tries to find an X and Y with H(n-1,X)
  3201. = H'(n-1,Y). By the birthday phenomenon (app. F), the probability
  3202. of finding X and Y is at least 1/2. If X and Y are found, the
  3203. opponent has obtained a bogus message with the proscribed hash
  3204. value; furthermore this takes at most about 233 encryptions, 232
  3205. storage and 64 * 232 comparison operations. This effectively breaks
  3206. the scheme. Actually Coppersmith's attack was directed against a
  3207. refinement by Davies and Price [DAVI80]; Rabin's original scheme
  3208. had been broken earlier. 
  3209.  
  3210.  
  3211.    4.3.3 Quadratic congruential hash functions.
  3212.  
  3213.  
  3214.    Another attempt to create hash functions, differing from both
  3215. Merkle- and Rabin-type constructions, was made by Jueneman
  3216. [JUEN82]. Unlike the Merkle meta-method this uses no external
  3217. system as an adjunct. It is not keyless; an initialization vector
  3218. is used. This limits the scope of usage; in particular, such a
  3219. function is useless for signature-only schemes. Nonetheless,
  3220. quadratic congruential constructions are simple and efficient, and
  3221. hence would be useful in some contexts if secure. Unfortunately it
  3222. seems as though Coppersmith's attack applies to these as well.
  3223.  
  3224.    Jueneman uses the same partition into fixed-size blocks as
  3225. above, and again begins by choosing H0 = 0. However, he also
  3226. chooses a secret seed M0 which is changed every message and
  3227. transmitted as a prefix to the message. Thus  Assuming 32-bit
  3228. blocks (to use the Mersenne prime 231-1), for i = 0,...,n he
  3229. computes
  3230.  
  3231.  
  3232.       Hi+1 = (Hi + Mi)2 mod (231-1).
  3233.  
  3234.  
  3235.    Then the hash value is Hn. Coppersmith broke this first scheme.
  3236. A revised scheme was proposed in [JUEN86]. The text is split into
  3237. 128-bit blocks, which are further divided into 4 words. Recent
  3238. results suggest that this scheme may be insecure also. This is
  3239. especially unfortunate in light of the fact that a hash function
  3240. given in Annex D of X.509 [CCIT87] is defined similarly, via
  3241.  
  3242.  
  3243.  
  3244.       Hi+1 = Mi + Hi2    mod n.
  3245.  
  3246.  
  3247.    Recent work calls this into question as well.
  3248.  
  3249.  
  3250.    4.4 Hardware and software support.
  3251.  
  3252.  
  3253.    As noted earlier, RSA and similar exponentiation-based
  3254. algorithms suffer from relatively low bandwidths. At a minimum this
  3255. implies that supporting software needs to be carefully designed;
  3256. hardware support is probably a necessity in many settings. As noted
  3257. by Sedlak [SEDL87], bandwidths of less than 64 kbps (kilobits per
  3258. second) will degrade performance in many networks. Furthermore,
  3259. arithmetic modulo numbers of an adequate number of bits (at least
  3260. 512) should be supported. Essentially the requirement is a chip (or
  3261. chip set) that can quickly compute quantities such as a mod b, ai
  3262. mod b, and perhaps multiplicative inverses or greatest common
  3263. divisors. As Sedlak notes further, a single chip is preferable for
  3264. security reasons. Since off-chip communication is slower than on-
  3265. chip, single-chip implementations should also yield higher
  3266. bandwidths.
  3267.  
  3268.  
  3269.    4.4.1 Design considerations for RSA chips.
  3270.  
  3271.  
  3272.    Some general tradeoffs in such design schemes are discussed by
  3273. Rivest [RIVE84]. He classifies architectures as serial (S),
  3274. serial/parallel (S/P), or parallel/parallel (P/P). He then notes
  3275. the following time and hardware costs:
  3276.  
  3277.  
  3278.       a. Multiplying two k-bit numbers modulo a k-bit number:
  3279.  
  3280.          1. O(k2) time and O(1) gates on an S.
  3281.  
  3282.          2. O(k) time and O(k) gates on an S/P.
  3283.  
  3284.          3. O(log k) time and O(k2) gates on a P/P.
  3285.  
  3286.       b. Exponentiating a k-bit number modulo a k-bit number:
  3287.  
  3288.          1. O(k3) time and O(1) gates on an S.
  3289.  
  3290.          2. O(k2) time and O(k) gates on an S/P.
  3291.  
  3292.          3. O(k log k) time and O(k2) gates on a P/P.
  3293.  
  3294.       c. Key generation, k-bit primes:
  3295.  
  3296.          1. O(k4) time and O(1) gates on an S.
  3297.  
  3298.          2. O(k3) time and O(k) gates on an S/P.
  3299.  
  3300.          3. O(k2 log k) time and O(k2) gates on a P/P.
  3301.  
  3302.  
  3303.    This is a somewhat oversimplified version of [RIVE84] presented
  3304. only for comparison purposes. Also, there are two basic assumptions
  3305. used above: exponentiation is an inherently sequential process; and
  3306. the 100 or so primality tests used in key generation are done
  3307. sequentially. The first assumption seems intrinsic. However, the
  3308. second is pragmatic: the tests all use the same hardware, and
  3309. replicating the latter 100-fold for parallel execution would be
  3310. highly cost-ineffective. Rivest uses the above to give some sample
  3311. timings:
  3312.  
  3313.  
  3314.       a. Decryption rate, 200-digit modulus:
  3315.  
  3316.          1. 0.005 kbps on an S.
  3317.  
  3318.          2. 1.3 kbps on an S/P.
  3319.  
  3320.          3. 95 kbps on a P/P.
  3321.  
  3322.       b. Key generation, 100-digit primes:
  3323.  
  3324.          1. 1,200,000 ms = 20 minutes on an S.
  3325.  
  3326.          2. 5,000 ms = 5 seconds on an S/P.
  3327.  
  3328.          3. 70 ms on a P/P.
  3329.  
  3330.  
  3331.    It may be seen that reasonably high bandwidths can be achieved,
  3332. but the time/cost tradeoff is significant.
  3333.  
  3334.  
  3335.    4.4.2 Proposed designs for RSA chips.
  3336.  
  3337.  
  3338.    Various authors have proposed designs for chips supporting RSA.
  3339. Of course such chips could also support other exponential-based
  3340. algorithms.
  3341.  
  3342.    Orton et. al. [ORTO86] discuss an implementation of RSA in 2 um
  3343. CMOS which should encrypt at 40 kbps for 512-bit moduli.
  3344.  
  3345.    Sedlak [SEDL87] discusses a highly-optimized chip which makes
  3346. substantial usage of lookahead. Thus the number of cycles required
  3347. for exponentiation is not fixed; analysis of expected time is
  3348. performed using a probabilistic finite state machine (see app. D).
  3349. Support is provided not only for RSA but also for the ISO hash
  3350. function (see above). Sedlak claims a deciphering rate of nearly
  3351. 200 kbps is achievable for 780-bit moduli using a single 160,000-
  3352. transistor chip with dual ciphering units, in 1.5 um CMOS. He also
  3353. claims a key generation time of 2 seconds. A 5,000-transistor, 5
  3354. um CMOS prototype has been realized.
  3355.  
  3356.    In [BRIC89] it is noted that chips capable of up to 450 kbps are
  3357. being designed.
  3358.  
  3359.  
  3360.    5. Implementations of public-key cryptography.
  3361.  
  3362.  
  3363.    We examine here some existing implementations of public-key
  3364. cryptography, some implementations which are in progress, and some
  3365. which have been proposed.
  3366.  
  3367.  
  3368.    5.1 MITRENET.
  3369.  
  3370.  
  3371.    One of the earliest implementations of public-key cryptography
  3372. was in the MEMO (MITRE Encrypted Mail Office) system, a secure
  3373. electronic mail system for MITRENET ([SCHA82],[SCHA80]). MITRENET
  3374. is a broadband cable system with a bandwidth of 1 mbps. It uses a
  3375. carrier sense protocol (e.g., [TANE81]); i.e., each station can
  3376. sense transmissions of all other stations. In fact the protocol
  3377. requires all parties to monitor all communication, in effect
  3378. requiring passive eavesdropping. A priori this provides no secrecy,
  3379. authentication or integrity services. Furthermore it employs
  3380. distributed switching, creating a potential for active intrusion.
  3381. This is a good setting for a privacy enhancement testbed.
  3382.  
  3383.    The MEMO system is a hybrid public/private cryptosystem. DES is
  3384. used for data encryption. The Diffie/Hellman exponential key
  3385. exchange of section 2.2 is used for establishment of secret keys.
  3386. To implement Diffie/Hellman, use of GF(2n), with 2n - 1 a prime
  3387. (called a Mersenne prime), was chosen for efficiency of
  3388. implementation via linear feedback shift registers. Unfortunately
  3389. the MEMO implementors used n = 127; the work of Adleman [ADLE79]
  3390. rendered this choice insecure even before the system was
  3391. implemented. This is noted by Schanning; in fact the use of n = 521
  3392. is recommended in [SCHA82], suggesting that the MEMO system was
  3393. intended mainly for experimental purposes.
  3394.  
  3395.    In the MEMO system, a Public Key Distribution Center is a
  3396. separate network node containing public components in EPROM.
  3397. Private components can be generated by users or by the system.
  3398.  
  3399.    Each user workstation establishes secure communication with the
  3400. Public Key Distribution Center. A session begins with the user
  3401. requesting the file of public keys from the PKDC. The request is
  3402. honored if it passes an identification test involving the user's
  3403. private component. The file of public keys is then downloaded to
  3404. the user's workstation, encrypted with DES to ensure integrity.
  3405.  
  3406.    When the user sends a message to another user, the workstation
  3407. generates a random document key. The latter is used to DES-encrypt
  3408. the message. The public key of the recipient is used to generate
  3409. a key-encrypting key which is used to DES-encrypt the document key.
  3410.  
  3411.    There is no provision for lost keys. Some provision is made for
  3412. detecting modifications to messages, using checksums. However, the
  3413. use of Diffie/Hellman alone does not permit authentication to be
  3414. introduced.
  3415.  
  3416.  
  3417.    5.2 ISDN.
  3418.  
  3419.  
  3420.    In [DIFF87] a testbed secure Integrated Services Digital Network
  3421. terminal developed at Bell-Northern Research is described. It can
  3422. carry voice or data at 64 kbps. Public-key cryptography is used for
  3423. both key exchange and authentication. Reference to the
  3424. Diffie/Hellman exponential key exchange is made. Evidently it is
  3425. used in conjunction with DES. The article also alludes to
  3426. signatures, but implementation is unclear.
  3427.  
  3428.    As noted in [DIFF88], the use of public-key in conjunction with
  3429. DES provides good security. In particular, the exponential key
  3430. exchange permits a session key unique to each call. Thus if long-
  3431. term keys are compromised, recordings of calls made prior to
  3432. compromise cannot be decoded. In conventional systems the
  3433. compromise of a long-term key may compromise communications made
  3434. previously with derived keys.
  3435.  
  3436.    Public key computations in the terminal are implemented via a
  3437. DSP (digital signal processing) chip, while an off-the-shelf
  3438. integrated circuit implements DES, which is used for data
  3439. encryption. Key management involves keys installed in phones,
  3440. carried by users, and exchanged electronically. 
  3441.  
  3442.    Each BNR terminal incorporates a Northern Telecom M3000
  3443. Touchphone.
  3444.  
  3445.  
  3446.    5.2.1 Keys.
  3447.  
  3448.  
  3449.    A public/private component pair is embedded in the phone; this
  3450. pair is called the intrinsic key. The private component is
  3451. contained in a tamper-resistant compartment of the phone. The
  3452. public component serves as the name of the phone. These cannot be
  3453. altered. 
  3454.  
  3455.    A second long-term public key stored in the phone is the owner
  3456. key. This is used to authenticate commands from the owner. It can
  3457. be changed by a command signed with the current owner key, thus
  3458. permitting transfer to a new owner. 
  3459.  
  3460.    A third long-term public key in the phone is the network key.
  3461. This identifies the network with which the phone is associated. It
  3462. validates commands signed with the private component of the
  3463. network's key management facility. It can authenticate calls from
  3464. network users. It can be changed by a command signed by the owner
  3465. key.
  3466.  
  3467.    A short-term component pair stored in the phone is the working
  3468. pair. These are embodied in a certificate signed by the key
  3469. management facility. During the setup process for a call, phones
  3470. exchange certificates. The network key is used to authenticate
  3471. certificates. This permits station-to-station calls. 
  3472.  
  3473.    Further information is needed for authenticated person-to-
  3474. person calls. This information is contained on a hardware "ignition
  3475. key" which must be inserted into the phone. This key contains the
  3476. user's private component encrypted under a secret password known
  3477. only to the user. It also contains a certificate signed by the KMF
  3478. which contains the user's public component and identifying
  3479. information. The latter is encrypted as well. Decryption of the
  3480. information on the ignition key is effected via a password typed
  3481. on the telephone touchpad.
  3482.  
  3483.    Further certificates authorizing users to use particular phones
  3484. are acquired by the phone from the key management facility; these
  3485. are cached and replaced in FIFO fashion.
  3486.  
  3487.  
  3488.    5.2.2 Calling.
  3489.  
  3490.  
  3491.    A person-to-person call begins as follows: the caller inserts
  3492. his ignition key and dials the number. The phone interrogates the
  3493. ignition key to check the caller's identity. The phone then checks
  3494. its cache for an authorization certificate for the caller. If not
  3495. found it is acquired by the phone from the KMF. The phone then
  3496. dials the number of the other phone. 
  3497.  
  3498.    The two phones then set-up. This begins with an exponential key
  3499. exchange. The calling phone then transmits its certificate and user
  3500. authorization. The receiving phone authenticates the signatures on
  3501. both of the latter using the network key. The receiving phone then
  3502. employs challenges. It demands real-time responses to time-
  3503. dependent messages; the responses must be signed. This ensures that
  3504. certificates are not played back from a previous conversation. One
  3505. response is signed by the calling phone; another with the user's
  3506. ignition key. A further level of security may be obtained via the
  3507. ISDN D channel, which makes calling party identification available
  3508. from the network without interrupting the primary call.
  3509.  
  3510.    Now the called phone sends its certificates and responds to
  3511. challenges as above. If the called party is home he inserts his
  3512. ignition key. If the called phone does not have authorization for
  3513. the called party to use the phone, it must obtain a certificate.
  3514. Again this can be accomplished via the D channel without
  3515. interrupting the call. The called party then undergoes challenge
  3516. and response. Finally the conversation ensues.
  3517.  
  3518.  
  3519.    5.3 ISO Authentication Framework.
  3520.  
  3521.  
  3522.    Public-key cryptography has been recommended for use in
  3523. connection with the ISO authentication framework, X.509 [CCIT87].
  3524. This is based on the Directory, a collection of services and
  3525. databases which provide an authentication service. Authentication
  3526. refers to verification of the identity of a communicating party.
  3527. Strong authentication uses cryptography. The credentials of a
  3528. communicating party may be obtained from the Directory.
  3529.  
  3530.    No specific cryptosystem or hash function is endorsed in support
  3531. of strong authentication; however, it is specified in [CCIT87] that
  3532. a cryptosystem should be usable for both secrecy and authenticity.
  3533. That is, the encryption and decryption transformations should be
  3534. inverses, as is the case with RSA. Multiple cryptosystems and hash
  3535. functions may be used in the system.
  3536.  
  3537.    A user must possess a distinguished name. Naming Authorities are
  3538. responsible for assigning unique names. The crux of the
  3539. authentication framework is the binding of user names and public
  3540. components. Assuming for the moment that such binding has occurred,
  3541. subsequent authentication in the ISO framework consists of locating
  3542. a chain of trusted points within the Directory. Such a chain exists
  3543. if there is a common point of trust between two authenticating
  3544. parties. 
  3545.  
  3546.  
  3547.    5.3.1 Use of certificates.
  3548.  
  3549.  
  3550.    The X.509 public-component management system is certificate-
  3551. based. Binding of a user's name and public component occurs when
  3552. a Certification Authority issues a certificate to a user. The
  3553. certificate contains the user's public component and distinguished
  3554. name, and the certificate's validity period. It is generated off-
  3555. line and signed by the CA using the CA's private component.
  3556. Normally a user would generate his own public/private component
  3557. pair and transmit the public component to the CA for inclusion in
  3558. the certificate. At the user's request the CA may also generate the
  3559. user's public/private component pair. 
  3560.  
  3561.    The CA vouches for the binding of the user's name and public
  3562. component. The CA must not issue multiple certificates with one
  3563. name. Also, a CA must keep his private component secret; compromise
  3564. would affect not only the CA but also the integrity of
  3565. communications involving users certified by the CA.
  3566.  
  3567.    Obtaining a certificate from a CA requires a secure
  3568. communication between the user and CA. In particular, the integrity
  3569. of the user's public component must be assured. This communication
  3570. can be on-line, off-line, or both for redundancy.
  3571.  
  3572.    The user receives a copy of the certificate obtained from the
  3573. CA. This can be cached; e.g., a component pair could be stored on
  3574. a smart card along with the user's certificate and the CA's
  3575. certificate. Additionally, certificates are entered in the
  3576. Directory. The user may place a copy of the certificate in the
  3577. Directory, or the CA may be authorized to do this. A user's
  3578. Directory entry may contain multiple certificates. A CA's entry in
  3579. the DIT contains the certificates issued for it by other CAs, as
  3580. well as certificates it issues for other nodes. 
  3581.  
  3582.    Semi-formally a certificate may be defined as follows:
  3583.  
  3584.  
  3585.       certificate ::=
  3586.          {
  3587.          signature algorithm identifier;
  3588.          issuer name;
  3589.          validity period;
  3590.          subject name;
  3591.          subject information
  3592.          }
  3593.  
  3594.       validity period ::=
  3595.          {
  3596.          start date;
  3597.          finish date
  3598.          }
  3599.  
  3600.       subject information ::=
  3601.          {
  3602.          subject public key;
  3603.          public key algorithm identifier
  3604.          }
  3605.  
  3606.  
  3607.    This format permits usage of different algorithms. For a more
  3608. formal description of relevant formats using ASN.1 see annexes G
  3609. and H of [CCIT87].
  3610.  
  3611.  
  3612.    5.3.2 Certification paths.
  3613.  
  3614.  
  3615.    An associated data structure is the Directory Information Tree
  3616. (DIT). Certification Authorities are otherwise undistinguished
  3617. users who are nodes in the DIT. A user may have certificates issued
  3618. by several CAs. Thus the authentication structure, despite the use
  3619. of the term DIT, is not tree-structured. Instead it may be modeled
  3620. as a directed graph.
  3621.  
  3622.    A certification path consists of certificates of nodes in the
  3623. DIT. The public component of the first node is used to initiate a
  3624. domino-type process which ultimately unlocks the whole path,
  3625. leading to recovery of the public component of the final node. The
  3626. simplest path is of the form (A,B), where A is a CA for B. Then a
  3627. knowledge of the public component of A permits recovery of the
  3628. public component of B from the certificate issued by A for B, since
  3629. the latter is signed using the private transformation of A. This
  3630. is readily extended by recursion: in a certification path A1,...,An,
  3631. knowing the public component of Ai permits recovery of the public
  3632. component of Ai+1 from the certificate for Ai+1 issued by Ai. 
  3633.  
  3634.    For a user A to obtain B's certificate involves finding a common
  3635. trusted point, i.e., a node which has certification paths to the
  3636. two users individually. Joining these two paths produces a
  3637. certification path between A and B. The paths, if they exist, may
  3638. be obtained from the Directory.
  3639.  
  3640.    Although there is no restriction placed on the structure of the
  3641. authentication graph, an important special case is when it is tree-
  3642. structured. In this event the CAs are arranged hierarchically;
  3643. hence each node (except the root) has a unique CA (its parent in
  3644. the tree). Then each CA stores the certificate obtained from its
  3645. superior CA, as well as various certificates issued by it. The
  3646. common trusted point for a pair of users is the root of the DIT.
  3647. A user A may cache the certificates of nodes along the path from
  3648. A to the root. The other half of the path to another user B is
  3649. obtained by conjoining the path from the root to B. 
  3650.  
  3651.    More generally, a user A who communicates frequently with users
  3652. certified by a particular CA could store paths to and from that CA
  3653. (these may be different in the non-hierarchical case). Then to
  3654. communicate with a given user B certified by that CA, A need only
  3655. consult the directory entry for the CA and obtain the certificate
  3656. of B.
  3657.  
  3658.    A related concept is cross-certification: if two CAs C1 and C2
  3659. have certified users who communicate frequently, C1 and C2 may
  3660. certify each other. Then the certificate issued by C1 for C2 can be
  3661. stored in the directory entry of C1 and vice-versa. We note that in
  3662. a hierarchical system, a priori a directory entry for a node
  3663. contains only the certificate of a node's superior and the reverse
  3664. certificate; if cross-certification is permitted then entries
  3665. contain an indefinite number of certificates. 
  3666.  
  3667.    A user may cache certificates of other users. A CA may add
  3668. another's certificate to its directory entry.
  3669.  
  3670.  
  3671.    5.3.3 Expiration and revocation of certificates.
  3672.  
  3673.    When a certificate expires it should be removed from the
  3674. Directory. Expired certificates should be retained by the issuing
  3675. CAs for a period of time in support of the nonrepudiation service.
  3676.  
  3677.    Revocation of certificates may occur because of component
  3678. compromise involving either the user or the issuing CA. Revocation
  3679. may also be necessary for administrative reasons, e.g., when a CA
  3680. is no longer authorized to certify a user. A CA keeps a time-
  3681. stamped list of revoked certificates which the CA had issued, and
  3682. a list of revoked certificates issued by other CAs certified by the
  3683. first CA. Entries for CAs in the Directory should contain
  3684. revocation lists for users and CAs. 
  3685.  
  3686.  
  3687.    5.3.4 Authentication protocols.
  3688.  
  3689.  
  3690.    Suppose A wishes to engage in communication with an
  3691. authenticated B. Suppose further that A has obtained a
  3692. certification path from A to B, e.g., by accessing the Directory,
  3693. and has utilized the path to obtain B's public component. Then A
  3694. may initiate one-, two-, or three-way authentication protocols. 
  3695.  
  3696.   One-way authentication involves a single communication from A to
  3697. B. It establishes the identities of A and B and the integrity of
  3698. any communicated information. It also deflects replay in
  3699. communication of authentication information. 
  3700.  
  3701.    Two-way authentication adds a reply from B. It establishes that
  3702. the reply was sent by B and that information in the reply had
  3703. integrity and was not replayed. It also establishes secrecy of the
  3704. two communications. Both one-way and two-way authentication use
  3705. timestamps. Three-way authentication adds a further message from
  3706. A to B, and obviates the necessity of timestamps.
  3707.  
  3708.    Let 
  3709.  
  3710.  
  3711.       IA = identity of A,
  3712.  
  3713.       IB = identity of B,
  3714.  
  3715.       DA = private transformation of A,
  3716.  
  3717.       EA = public transformation of A,
  3718.  
  3719.       DB = private transformation of B,
  3720.  
  3721.       EB = public transformation of B,
  3722.  
  3723.       TA = timestamp by A,
  3724.  
  3725.       TB = timestamp by B,
  3726.  
  3727.       RA = random number generated by A,
  3728.  
  3729.       RB = random number generated by B,
  3730.  
  3731.       CA = certification path from A to B.
  3732.  
  3733.  
  3734.    Identities refer to the distinguished names of A and B. A
  3735. timestamp included in a message M includes an expiration date for
  3736. M. Optionally, it also may include the time of generation of M.
  3737. Random numbers may be supplemented with sequence numbers; they
  3738. should not be repeated within the expiration period indicated by
  3739. a timestamp in the same communication.
  3740.  
  3741.    The one-way protocol is as follows:
  3742.  
  3743.  
  3744.       a. A:
  3745.  
  3746.          1. generates an RA.
  3747.  
  3748.          2. constructs message M = (TA,RA,IB,<data>) where <data> is 
  3749.             arbitrary. The latter may include data encrypted under 
  3750.             EB for secrecy, e.g., when A is sending a data-       
  3751.             encrypting key to B.
  3752.  
  3753.          3. sends (CA,DA(M)) to B.
  3754.  
  3755.       b. B:
  3756.  
  3757.          1. decrypts CA and obtains EA. Also checks certificate   
  3758.             expiration dates.
  3759.  
  3760.          2. uses EA to decrypt DA(M), verifying both A's signature 
  3761.             and the integrity of the signed information.
  3762.  
  3763.          3. checks the IB contained in M for accuracy.
  3764.  
  3765.          4. checks the TA in M for currency.
  3766.  
  3767.          5. optionally, checks the RA in M for replay.
  3768.  
  3769.  
  3770.    The one-way protocol is illustrated below, with CA denoting CA,
  3771. RA denoting RA, etc.
  3772.  
  3773.  
  3774.  
  3775.  
  3776.  
  3777.  
  3778.  
  3779.               A:                                 B:
  3780.       ____________________                _________________
  3781.      |                    |        _____\|                 |
  3782.      |    generate RA     |      /|\    /| receive (CA,M') |
  3783.      |____________________|       |      |_________________|
  3784.                |                  |               |
  3785.                |                  |               |
  3786.       ________\|/_________        |     _________\|/_________
  3787.      |                    |       |    |                     |
  3788.      |    obtain TA,IB    |       |    |  recover EA from CA |
  3789.      |____________________|       |    |_____________________|
  3790.                |                  |               |
  3791.                |                  |               |
  3792.      _________\|/__________       |     _________\|/_________
  3793.     |                      |      |    |                     |
  3794.     | compute M' =         |      |    |  compute (TA,RA,IB) |
  3795.     |         DA(TA,RA,IB) |      |    |          = EA(M')   |
  3796.     |______________________|      |    |_____________________|
  3797.                |                  |               |
  3798.                |                  |               |
  3799.       ________\|/________         |     _________\|/_________
  3800.      |                   |        |    |                     |
  3801.      | send (CA,M') to B |        |    |   verify TA,RA,IB   |
  3802.      |___________________|        |    |_____________________|
  3803.                |                  |               
  3804.                |                  |     
  3805.               \|/________________\|
  3806.                                  /
  3807.  
  3808.               Figure 8. One-Way Authentication Protocol
  3809.  
  3810.  
  3811.    The two-way protocol is:
  3812.  
  3813.  
  3814.       a. as above.
  3815.  
  3816.       b. as above.
  3817.  
  3818.       c. B:
  3819.  
  3820.          1. generates an RB.
  3821.  
  3822.          2. constructs M' = (TB,RB,IA,RA,<data>) where RA was      
  3823.              obtained previously and <data> may include data     
  3824.               encrypted using EA.
  3825.  
  3826.          3. sends DB(M') to A.
  3827.  
  3828.       d. A:
  3829.  
  3830.          1. decrypts DB(M'), verifying B's signature and the      
  3831.             integrity of the enclosed information.
  3832.  
  3833.          2. checks the IA contained in M' for accuracy.
  3834.  
  3835.          3. checks the TB in M' for currency.
  3836.  
  3837.          4. optionally checks RB for replay.
  3838.  
  3839.  
  3840.    The three-way protocol is:
  3841.  
  3842.  
  3843.       a. A:
  3844.  
  3845.          1. generates an RA.
  3846.  
  3847.          2. constructs M = (TA,RA,IB,<data>). Unlike the previous  
  3848.             cases, TA may be zero.
  3849.  
  3850.          3. sends (CA,DA(M)) to B.
  3851.  
  3852.       b. B:
  3853.  
  3854.          1. decrypts CA and obtains EA. Also checks certificate   
  3855.             expiration dates.
  3856.  
  3857.          2. uses EA to decrypt DA(M), verifying both A's signature 
  3858.             and the integrity of the signed information.
  3859.  
  3860.          3. checks the IB contained in M for accuracy.
  3861.  
  3862.          4. optionally, checks the RA in M for replay.
  3863.  
  3864.          5. generates an RB.
  3865.  
  3866.          6. constructs M' = (TB,RB,IA,RA,<data>) where RA was      
  3867.              obtained previously; TB may be zero.
  3868.  
  3869.          7. sends DB(M') to A.
  3870.  
  3871.       c. A:
  3872.  
  3873.          1. decrypts DB(M'), verifying B's signature and the      
  3874.             integrity of the enclosed information.
  3875.  
  3876.          2. checks the IA contained in M' for accuracy.
  3877.  
  3878.          3. optionally checks RB for replay.
  3879.  
  3880.          4. checks the received version of RA against the version 
  3881.             sent to B.
  3882.  
  3883.          5. sends DA(RB) to B.
  3884.  
  3885.       d. B:
  3886.  
  3887.          1. decrypts DA(RB), verifying the signature and data     
  3888.             integrity.
  3889.  
  3890.          2. checks the RB received against the value sent to A.
  3891.  
  3892.  
  3893.    Remarks: it has been noted that there are some potential
  3894. problems with these protocols. For example, in the three-way
  3895. version, it would be better to have A send DA(RB,IB) to B rather
  3896. than just DA(RB). This would prevent a third party from intercepting
  3897. random numbers and using them to subvert the protocol.
  3898.  
  3899.    Also, authentication tokens may be of the form M = (TA,RA,IB,RB,
  3900. EB(encdata)). Then encrypted data is signed, which may cause
  3901. problems. For example, suppose C intercepts DA(M) on its way to B.
  3902. Then C may decrypt M and construct (TC,RC,IB,RB,EB(encdata)). In a
  3903. communication between B and C, B may think that EB(encdata) was
  3904. generated by C and inadvertently reveal encdata to C. In
  3905. particular, encdata may have included a data-encrypting key to be
  3906. used by A and B. A solution to this problem is to let M =
  3907. (TA,RA,IB,RB,encdata), M' = (TA,RA,IB,RB,EB(encdata)), and M" =
  3908. (M',DA(M)), then send M".
  3909.  
  3910.  
  3911.    5.3.5 Further notes.
  3912.  
  3913.  
  3914.    Authentication uses a hash function. Signed information includes
  3915. identifications of the hash function used to produce the message
  3916. digest and the decryption function used to generate the digital
  3917. signature. Timestamps and random numbers are included in messages
  3918. to prevent replays and forgery. 
  3919.  
  3920.    Annex C of [CCIT87] mentions RSA as an example of a public-key
  3921. system. A recommendation of a 512-bit modulus is made. It is also
  3922. recommended that a common public exponent of e = 216 + 1 be used
  3923. (the fourth Fermat number). In particular it is noted that a
  3924. smaller e would be vulnerable to ciphertext-only attacks.
  3925.  
  3926.    Other annexes specify a strong hash function as defined in
  3927. section 4, and the ASN.1 syntax for the authentication framework.
  3928. Algorithm identifiers are included in ASN.
  3929.  
  3930.  
  3931.    5.4 DARPA-Internet.
  3932.  
  3933.  
  3934.    The Privacy and Security Research Group is in the process of
  3935. developing a proposal for privacy-enhanced electronic mail for the
  3936. DARPA-Internet community. Since this is work in progress we give
  3937. only a very brief description here. Details on the current state
  3938. of this project (at the time of this writing) may be found in
  3939. [IAB-90],[LINN89].
  3940.  
  3941.    Public-key cryptography has been recommended for distribution
  3942. of secret keys and in support of digital signatures. DES will be
  3943. used for encryption of messages and can be used for Message
  3944. Integrity Check (MIC) computations. RSA has been recommended for
  3945. key distribution and digital signatures. The hash functions
  3946. currently supported are MD2 and MD4 [RIVE90]. Fields are included
  3947. in messages to identify cryptographic algorithms and hash
  3948. functions. It is specified that all implementations should support
  3949. RSA and DES.
  3950.  
  3951.     Much of the authentication framework is based on a subset of
  3952. X.509. In particular, the recommended public component management
  3953. system is certificate-based.
  3954.  
  3955.  
  3956.    6. A sample proposal for a LAN implementation.
  3957.  
  3958.  
  3959.    We present here a sample proposal for the implementation of
  3960. privacy enhancement in a packet-switched local area network, using
  3961. public-key cryptography for key management and authentication. The
  3962. main purpose is to explore the relevant decision-making process.
  3963. In particular, some services will be needed in some settings but
  3964. not others, and hence a monolithic structure incorporating all
  3965. conceivable services would be inappropriate. One approach to the
  3966. design of a generic structure is layered, with a kernel consisting
  3967. of the most basic services and outer layers added as desired. This
  3968. is the paradigm we adopt here. The sample proposal presented here
  3969. is not unique, and is intended for illustration purposes only.
  3970.  
  3971.    A hybrid of public-key cryptography and conventional
  3972. cryptography presents advantages. The former is used for signatures
  3973. and for distribution of secret keys used in the latter; the latter
  3974. is used for bulk data encryption. In addition, a hash function is
  3975. needed so that only a compressed form of long text need be signed.
  3976. We do not endorse specific public-key systems or hash functions.
  3977. The conventional system could be taken to be DES.
  3978.  
  3979.  
  3980.    6.1 Integration into a network.
  3981.  
  3982.  
  3983.    There are basically two modes of implementation of encryption
  3984. in a network (e.g., [DIFF84],[DIFF86],[TANE81]), namely link and
  3985. end-to-end. 
  3986.  
  3987.    Link encryption provides good protection against external
  3988. threats such as traffic analysis because all data flowing on links
  3989. can be encrypted, including addresses. Entire packets, including
  3990. addresses, are encrypted on exit from, and decrypted on entry to,
  3991. a node. Link encryption is easy to incorporate into network
  3992. protocols.
  3993.  
  3994.    On the other hand, link encryption has a major disadvantage: a
  3995. message is encrypted and decrypted several times. If a node is
  3996. compromised, all traffic flowing through that node is also
  3997. compromised. A secondary disadvantage is that the individual user
  3998. loses control over algorithms used.
  3999.  
  4000.    In end-to-end encryption, a message is encrypted and decrypted
  4001. only at endpoints, thereby largely circumventing problems with
  4002. compromise of intermediate nodes. However, some address information
  4003. (data link headers) must be left unencrypted to allow nodes to
  4004. route packets. Also, high-level network protocols must be augmented
  4005. with a separate set of cryptographic protocols.
  4006.  
  4007.    Here we assume end-to-end encryption. In terms of the OSI model,
  4008. encryption can occur at various levels, including application,
  4009. presentation, network or transport. As noted in [ISO-87], the
  4010. appropriate level depends on desired granularity of protection. In
  4011. particular, high granularity refers to separate keys for each
  4012. application or user and assurance of integrity. For this
  4013. granularity the presentation or application layers are most
  4014. appropriate. These two layers will be assumed here. In particular,
  4015. integration at the application layer gives the individual user
  4016. complete control over the algorithms used. 
  4017.  
  4018.  
  4019.    6.2 Security threats.
  4020.  
  4021.  
  4022.    Some basic security threats (cf. ann. A of [CCIT87]) include:
  4023.  
  4024.  
  4025.       a. masquerade
  4026.  
  4027.       b. replay
  4028.  
  4029.       c. interception of data
  4030.  
  4031.       d. manipulation of messages
  4032.  
  4033.       e. repudiation
  4034.  
  4035.  
  4036.    Masquerade refers to users representing themselves as other
  4037. users. Replay refers to recording and re-sending a message at a
  4038. later time. Interception of data refers to passive eavesdropping
  4039. on communications. Manipulation refers to unauthorized insertions,
  4040. deletions or other changes to messages. Repudiation refers to
  4041. denial of sending (or possibly receipt) of a message.  
  4042.  
  4043.    There are other threats which are outside the present scope per
  4044. se. For example, mis-routing of packets naturally occurs in OSI
  4045. layers 1-3, and we are restricting ourselves to higher layers. 
  4046.  
  4047.  
  4048.    6.3 Security services.
  4049.  
  4050.  
  4051.    Again from annex A of [CCIT87], some of the most basic security
  4052. services which can be provided include:
  4053.  
  4054.  
  4055.       a. authentication
  4056.  
  4057.       b. secrecy
  4058.  
  4059.       c. integrity
  4060.  
  4061.       d. nonrepudiation
  4062.  
  4063.  
  4064.    Authentication refers to verification of the identity of the
  4065. sender or receiver of a communication. It can protect against
  4066. masquerade. It may also provide protection against replay,
  4067. depending on implementation. Secrecy refers to protection against
  4068. interception of data. Integrity refers to protection against
  4069. manipulation (including accidental) of data. Nonrepudiation refers
  4070. to protection against denial of sending (or possibly receipt) of
  4071. a message. 
  4072.  
  4073.    The kernel of a proposed system would include basic support for
  4074. the above services. This kernel could be standardized to a large
  4075. extent. However, outer layers of an implementation would need to
  4076. interface with various external frameworks as well. For example,
  4077. a system is needed to bind user public components and user
  4078. identities; this forms an important part of the authentication
  4079. service. Also, support for nonrepudiation is a complex matter as
  4080. we have noted. A public-key signature system implements basic
  4081. nonrepudiation of sending automatically, but does not a priori
  4082. protect against repudiation of sending due to compromised private
  4083. components; nor does it provide proof of receipt. Thus (4) is an
  4084. example of a service which relies heavily on an interface with an
  4085. external system which most likely would be implementation-
  4086. dependent, since its structure depends on considerations such as
  4087. contractual agreements which cannot be incorporated into a generic
  4088. structure.
  4089.  
  4090.    There are other services which could be provided as well. One
  4091. example is access control with differing capabilities for different
  4092. classes of users. However, a public key system does not provide
  4093. this type of service per se, since it would require restricted
  4094. access to public components. This type of service is thus another
  4095. example of a layer which could be added in a given implementation,
  4096. e.g. by centralized key distribution which might be considered
  4097. undesirable in many settings.
  4098.  
  4099.    
  4100.    6.4 Security mechanisms. 
  4101.  
  4102.  
  4103.    Once more we follow annex A of [CCIT87], which identifies some
  4104. of the basic mechanisms which can implement security services.
  4105. These include:
  4106.  
  4107.  
  4108.       a. encryption
  4109.  
  4110.       b. manipulation detection codes
  4111.  
  4112.       c. signatures
  4113.  
  4114.       d. authentication framework
  4115.  
  4116.  
  4117.    Encryption refers to application of cryptographic
  4118. transformations to messages or keys; it implements secrecy.
  4119. Manipulation detection can be effected via hash functions producing
  4120. compressed versions of the text. Manipulation detection in
  4121. conjunction with authentication implements integrity. Signature
  4122. refers to application of private components to message digests
  4123. (output of hash functions); it implements authentication and basic
  4124. nonrepudiation, in concert with an authentication framework. The
  4125. form of the latter is implementation-dependent. For example, a
  4126. directory service might be provided, along with "hot lists" of
  4127. compromised keys.
  4128.  
  4129.    The four mechanisms above may be regarded as the kernel of an
  4130. implementation. Various other mechanisms which could be provided
  4131. are noted, e.g., in [ISO-87]. For example, to guard against replay,
  4132. timestamps using synchronized clocks might be provided. Another
  4133. possibility is the addition of a handshaking protocol. For
  4134. enhancement of the basic nonrepudiation mechanism (the signature),
  4135. a notary system could be used. Again these auxiliary services are
  4136. best added at the discretion of implementors. For example,
  4137. synchronized clocks may not be present, and notaries violate the
  4138. desirable feature of point-to-point communication, and hence should
  4139. not be included in standard specifications.
  4140.  
  4141.    
  4142.    6.5 Criteria for cryptosystems.
  4143.  
  4144.  
  4145.    There are various criteria which could be employed in selection
  4146. of a cryptosystem (or systems) to implement key distribution and
  4147. signatures. Logically these are separate functions and a hybrid of
  4148. two separate systems could be used. Some relevant criteria
  4149. (including suggestions from Dr. Dennis Branstad of NIST and Dr.
  4150. Ronald Rivest) are:
  4151.  
  4152.  
  4153.       a. security
  4154.  
  4155.       b. versatility
  4156.  
  4157.       c. bandwidth
  4158.  
  4159.       d. data expansion
  4160.  
  4161.       e. key size
  4162.  
  4163.       f. key generation time
  4164.  
  4165.       g. patent restrictions/license fees
  4166.  
  4167.       h. software support
  4168.  
  4169.       i. hardware support
  4170.  
  4171.       j. number of pseudorandom bits needed
  4172.  
  4173.       k. interoperability
  4174.  
  4175.  
  4176.    Most of these are self-explanatory. The reference to
  4177. pseudorandom bits in (j) is related to key generation, which
  4178. requires a stream of pseudorandom bits generated from a random
  4179. seed. Interoperability refers to the ability to communicate with
  4180. other equipment designed to provide the same security mechanisms
  4181. or functions.
  4182.  
  4183.  
  4184.    6.5.1 Security.
  4185.  
  4186.  
  4187.    The first and foremost criterion is of course security. It may
  4188. take 5 years or more for a given method to be thoroughly
  4189. cryptanalyzed, starting from the time it receives widespread public
  4190. exposure. 
  4191.  
  4192.    One subcriterion in this regard is that a system should be
  4193. published in an outlet such as a refereed journal with a reasonably
  4194. large circulation, or a book or conference proceeding which is
  4195. present in libraries at larger academic institutions and research
  4196. laboratories. This subcriterion is somewhat vague and not
  4197. intrinsic, but may serve to avoid future embarrassment on the part
  4198. of implementors. 
  4199.  
  4200.    A second subcriterion connected with security deals with
  4201. mathematical and computational infrastructure. For example, the
  4202. security of systems such as RSA is connected with the problem of
  4203. factoring. It is safe to assume that thousands (or perhaps
  4204. millions) of hours have been spent on this problem. This does not
  4205. preclude major advances over the next decade or so, but at least
  4206. guarantees that such advances will not occur simply because experts
  4207. have suddenly become aware of a problem. In particular, systems
  4208. based on longstanding problems such as factoring, discrete
  4209. logarithm and discrete root extraction have a certain degree of
  4210. security in this regard. In contrast, for example, the ElGamal
  4211. signature scheme can be broken if the "transcendental" equation c
  4212. = brrs (mod n) can be solved for some r and s. This is easier than
  4213. solving the logarithm or root problem y = xa (mod n); and
  4214. furthermore in all likelihood the ElGamal equation has not been
  4215. studied as extensively.
  4216.  
  4217.  
  4218.    6.5.2 Numerical criteria.
  4219.  
  4220.  
  4221.    Quantitative criteria for cryptosystems include bandwidth
  4222. (encryption and decryption rates), data expansion (relative sizes
  4223. of plaintext and ciphertext), key size and key generation time. We
  4224. have already noted the phenomenon that systems which appear to be
  4225. secure are also characterized by low bandwidths. Exponentiation-
  4226. based methods such as RSA and the Diffie/Hellman exponential key
  4227. exchange are examples. Other systems suffer from large data
  4228. expansion, large key size or long key generation time.
  4229.  
  4230.    There seem to be some inherent tradeoffs in this regard. That
  4231. is, it does not seem possible to construct a system which is secure
  4232. and also scores well on all numeric counts. The classic example is
  4233. key size; e.g., small key size in RSA would produce a high
  4234. bandwidth, but would also produce insecurity. That is, in this case
  4235. high bandwidth would produce low cryptanalysis time. Data expansion
  4236. seems to have a similar impact. For example, in appendix E it is
  4237. noted that Shamir's knapsack attack runs in time which rises as nd
  4238. where d = expansion factor. Again high bandwidth produced
  4239. insecurity. It would be interesting to know whether this trade-
  4240. off notion could be formalized. 
  4241.  
  4242.  
  4243.    6.5.3 Other criteria.
  4244.  
  4245.  
  4246.    Versatility is an important criterion. The RSA system is
  4247. distinguished in this regard since it supports both key
  4248. distribution and signatures. All other major systems are limited
  4249. to one service or the other, although hybrids can achieve the
  4250. capabilities of RSA.
  4251.  
  4252.    Patent restrictions and license fees may be a major factor in
  4253. practice. Software and hardware support is another important
  4254. practical matter.
  4255.  
  4256.  
  4257.    6.6 Criteria for hash functions.
  4258.  
  4259.  
  4260.    In section 3.2 we discussed some of the characterizations which
  4261. have been proposed for hash functions, including measures of
  4262. security. Some of the discussion of section 6.5 applies here as
  4263. well. For example, a hash function should be widely publicized for
  4264. a period of time before it is trusted. Bandwidth is also an
  4265. important criterion. Software and hardware support is relevant as
  4266. well. 
  4267.  
  4268.  
  4269.    6.7 Example of a LAN security framework.
  4270.  
  4271.  
  4272.    Finally we give a brief outline of a framework for incorporating
  4273. public-key cryptography into a local area network. 
  4274.  
  4275.  
  4276.    6.7.1 Key management.
  4277.  
  4278.  
  4279.    The framework for key management described in this section is
  4280. compatible with a subset of [CCIT87]. Public components of
  4281. receivers are used as key-encrypting keys; private components of
  4282. senders are used to encrypt message digests. Data-encrypting keys
  4283. are generated for individual sessions. These may be associated to
  4284. an arbitrary conventional cryptosystem; DES is a possibility. The
  4285. public and private components may be associated to different
  4286. public-key systems if different algorithms are used for key
  4287. encryption and signatures.
  4288.  
  4289.    Certificate-based key management is proposed. Since we are
  4290. focusing on local-area networks, a simple tree structure is
  4291. proposed, consisting of a root and one additional level containing
  4292. all users. In particular, the root issues all certificates.
  4293. Certification paths are thus trivial.
  4294.  
  4295.  
  4296.    6.7.2 Component generation and storage.
  4297.  
  4298.  
  4299.    It is proposed that users generate their own public/private
  4300. component pairs, using trusted software or hardware supplied by the
  4301. system. Key pairs could be stored on smart cards [HAYK88] or
  4302. tokens, along with the user's certificate. Such kernel mechanisms
  4303. could be augmented by involvement of a central key distribution
  4304. facility. However, we have noted that this would negate a major
  4305. advantage of public-key cryptography, since compromise of the
  4306. central facility would compromise all keys of users who obtained
  4307. their keys from it.
  4308.  
  4309.  
  4310.    6.7.3 Secret-key generation.
  4311.  
  4312.  
  4313.    Numerous schemes exist for generation of data-encrypting keys.
  4314. For example, in [MATY78] it is noted that keys can be generated by
  4315. a conventional system such as DES. A master key might be used to
  4316. encrypt data-encrypting keys or other key-encrypting keys. The
  4317. master key, presumably long-term, is generated randomly. Other key-
  4318. encrypting keys can be generated using DES as a pseudorandom
  4319. generator. These are then encrypted under the master, which can
  4320. also be involved in generation of other key-encrypting keys. A
  4321. whole set of key-encrypting keys can be generated from a random 64-
  4322. bit seed, with every eighth bit adjusted for parity. Data-
  4323. encrypting keys can be produced dynamically by pseudorandom number
  4324. generators which are time-variant.
  4325.  
  4326.    An example of a generator for data-encrypting keys, as well as
  4327. initializing vectors, is given in appendix C of [ANSI85]. Let
  4328. E(K,Y) be encryption by DEA (essentially equivalent to DES) with
  4329. key K. Let K be a DEA key reserved for usage in key generation and
  4330. let V0 be a 64-bit secret seed. Let T be a date/time vector,
  4331. updated on each key or IV generation. Let
  4332.  
  4333.  
  4334.      Ri   = E(K,E(K,Ti) XOR Vi),
  4335.  
  4336.      Vi+1 = E(K,Ri XOR E(K,Ti)).
  4337.  
  4338.  
  4339.    Then Ri may be employed as an IV. To obtain a DEA key from R,
  4340. reset every eighth bit to odd parity.
  4341.  
  4342.    Routines for generating DES keys are supplied with various
  4343. products. Schemes for pseudorandom number generation include [AKL-
  4344. 84], [BLUM84],[BRIG76]. The last gives a pseudorandom bit generator
  4345. whose security is equivalent to discrete logarithm.
  4346.  
  4347.  
  4348.    6.7.4 Issuance and distribution of certificates.
  4349.  
  4350.  
  4351.    Public components are registered with the root. The root
  4352. generates a certificate containing the user's public component and
  4353. identifying information, and a validity period. Distribution of
  4354. certificates by users is recommended; certificates may be cached.
  4355. This eliminates the necessity of having the root be on-line. 
  4356.  
  4357.    However, a user may wish to send a privacy-enhanced message to
  4358. a user with whom he has not previously communicated, and who is
  4359. currently unavailable. Thus it may be desirable to augment this
  4360. kernel mechanism with a supplementary source of certificates. There
  4361. are disadvantages to any augmentation. For example, if a phone-
  4362. book approach to certificates is used, entries may be inaccurate
  4363. or altered. If a central directory mechanism is involved in key
  4364. distribution it must be on-line. On the other hand, a central
  4365. mechanism can provide instantaneous validity checks of public
  4366. components and certificates.
  4367.  
  4368.  
  4369.    The root should maintain a list of old public components for a
  4370. period of time in event of disputes, e.g., over attempted
  4371. repudiation.
  4372.  
  4373.  
  4374.    6.7.5 Compromised or invalidated certificates.
  4375.  
  4376.  
  4377.    Assuming that certificates are cached, the root must
  4378. periodically issue hot lists of invalidated certificates. This
  4379. kernel service may be augmented in various ways to provide more
  4380. current validity information. Again, however, additional mechanisms
  4381. have drawbacks. As noted above, a central directory service could
  4382. provide real-time validity checks, but it must be on-line.
  4383. Furthermore, such checks a priori do not account for compromised
  4384. private components, during the period following compromise but
  4385. before a report is filed with the root. Even if users are required
  4386. to report known compromises within a specified time period, a
  4387. compromise may not become known to the user until later. As we
  4388. noted, this creates an administrative/legal problem, since a user
  4389. could disavow a signature on the basis of the latter type of
  4390. compromise. A notary system can be used to add a layer of validity
  4391. by having secondary signatures attest to the validity of senders'
  4392. signatures, but this violates the desired criterion of point-to-
  4393. point communication.
  4394.  
  4395.    This is clearly an area in which solutions must be customized
  4396. to some degree. For example, authentication in a system used for
  4397. financial transactions may require more stringent controls than a
  4398. kernel provides.
  4399.  
  4400.    The root should maintain a time-stamped list of revoked
  4401. certificates.
  4402.  
  4403.  
  4404.    6.7.6 Authentication.
  4405.  
  4406.  
  4407.    A hash function is used to produce a message digest. This is
  4408. signed with the private component of the sender. Timestamps and
  4409. random numbers may also be included to prevent replay. If more than
  4410. one hash function is permitted, identification of the function used
  4411. should be included.
  4412.  
  4413.    Privacy-enhanced communication between two users begins when A
  4414. requests the certificate of B. This initial message contains A's
  4415. certificate. As noted above, it is desirable if this request can
  4416. be met directly by B. In this event, B first validates A's
  4417. certificate. This uses the public component of the root, which is
  4418. assumed to be known to all users. Then B forwards his certificate
  4419. to A, who validates it. Each may cache the certificate of the
  4420. other.
  4421.  
  4422.    Now A and B may communicate securely. If A sends a message to
  4423. B, B uses A's validated public component, extracted from A's
  4424. certificate, to decipher the message digest. Then B may decrypt the
  4425. key used for data encryption, using B's private component. Now B
  4426. may decrypt the message text using this session key, then re-
  4427. compute the message digest and compare to the transmitted form.
  4428.  
  4429.  
  4430.    Appendix A. Mathematical and computational aspects.
  4431.  
  4432.  
  4433.    We discuss here some issues related to the computational
  4434. complexity of public-key cryptography. The foundation of the
  4435. security of such systems is the computational infeasibility of
  4436. performing cryptanalysis, in contradistinction to the relative ease
  4437. of encryption/decryption. We analyze some of the issues which arise
  4438. in this context. Also included is some background theoretical
  4439. computer science needed to discuss the issue of computational
  4440. complexity of cryptography and cryptanalysis, as well as zero-
  4441. knowledge proofs and related schemes. 
  4442.  
  4443.    This discussion may aid in understanding the security basis of
  4444. public-key cryptography. It may also shed some light upon the more
  4445. practical matter of choosing key sizes, i.e., the number of bits
  4446. in private and public components. This section may safely be
  4447. skipped by readers who do not wish to gain an in-depth
  4448. understanding of such issues.
  4449.  
  4450.    
  4451.    A.1 Computational complexity and cryptocomplexity. 
  4452.  
  4453.  
  4454.    An ideal cryptosystem would have the property that encryption
  4455. and decryption are easy, but cryptanalysis is computationally
  4456. infeasible. In practice, this is commonly interpreted (e.g.,
  4457. [DIFF76b]) to mean that encryption/decryption should be executable
  4458. in polynomial time, while ideally cryptanalysis should take
  4459. exponential time. More generally, cryptanalytic time should be an
  4460. exponential function of encryption/decryption time. 
  4461.  
  4462.    Unfortunately, it is difficult to determine when this criterion
  4463. holds in practice. This is because it is usually very difficult to
  4464. determine a nonpolynomial lower bound for the time required for
  4465. cryptanalysis (or computations in general), even in instances when
  4466. this process reduces to simple and well-known problems. In some
  4467. cases the latter problems have been studied for centuries, but
  4468. their computational complexity is still unknown.
  4469.  
  4470.    In fact, whenever we try to determine the relative complexity
  4471. of cryptanalysis and encryption, we encounter the problem of
  4472. determining accurate lower bounds on computations. 
  4473.  
  4474.    Also, an analysis of security and efficiency of public-key
  4475. systems should take into account not only encryption/decryption
  4476. time versus anticipated time for cryptanalysis, but also other
  4477. parameters such as key size, key generation time, and data
  4478. expansion. Developing a theory to characterize both security and
  4479. practicality of cryptosystems seems very challenging.
  4480.  
  4481.  
  4482.    A.2 Classical complexity theory.
  4483.  
  4484.  
  4485.    Here we briefly introduce some notions from the theory of
  4486. computation. In Appendix C some of these notions are given a more
  4487. formal treatment.
  4488.  
  4489.    One attempt to formalize the study of hard problems is the
  4490. theory of NP-completeness (e.g., [GARE79],[HORO78]). The class P
  4491. is defined (loosely) to be the class of decision problems solvable
  4492. in polynomial time via a deterministic algorithm. The latter is
  4493. essentially an algorithm executable on an ordinary sequential
  4494. computer. A nondeterministic algorithm is a more ephemeral concept:
  4495. it is essentially executable on a machine with unbounded
  4496. parallelism. This means that an unlimited number of possibilities
  4497. can be explored in parallel. For example, suppose a set of n items
  4498. is to checked for the presence or absence of a given item. The
  4499. worst-case deterministic complexity is n, the number of operations
  4500. needed by a sequential machine to check all n items. In contrast,
  4501. the nondeterministic complexity is 1, since a machine with
  4502. unbounded parallelism could check all n items in parallel
  4503. regardless of n.
  4504.  
  4505.    The class NP is (loosely) the class of decision problems
  4506. solvable in polynomial time via a nondeterministic algorithm.
  4507. Perhaps the single most important problem in computer science is
  4508. to decide whether P = NP. The NP-complete problems are the hardest
  4509. subclass of NP, having the property that if one instance of the
  4510. subclass is in P then P = NP. Many classical combinatorial search
  4511. problems can be given NP-complete formulations. Traveling salesman
  4512. and knapsack are examples (see [GARE79] for a long list). 
  4513.  
  4514.    The class of NP-hard problems are those problems, decision or
  4515. otherwise, which are at least as hard as NP-complete problems. Some
  4516. NP-hard problems are so hard that no algorithm will solve them;
  4517. they are undecidable. Such problems cannot be in NP. An example is
  4518. the halting problem (e.g., [HORO78]). 
  4519.  
  4520.    A more formal treatment of the classes P and NP requires a
  4521. framework such as Turing machines (app. C).
  4522.  
  4523.  
  4524.    A.3 Public-key systems and cryptocomplexity.
  4525.  
  4526.  
  4527.    The use of NP-complete problems to generate public-key
  4528. cryptosystems was suggested in [DIFF76b]. Later this approach
  4529. materialized in the form of trapdoor knapsacks [MERK78b]. As we
  4530. have noted, however, most knapsacks have been broken, despite the
  4531. continuing intractability of the underlying NP-complete problem
  4532. (integer programming). There are two separate explanations for this
  4533. phenomenon. First of all, in most cases it has not been proven that
  4534. the security of the public-key system is equivalent to the
  4535. intractability of the underlying problem.
  4536.  
  4537.    Secondly, it is important to note that the classical theory of
  4538. computational complexity has been founded around the cornerstone
  4539. of worst-case complexity, with average-case complexity as a
  4540. secondary criterion. As Rabin [RABI76] notes, these measures are
  4541. of limited relevance in analyzing the complexity of cryptanalysis,
  4542. since a cryptosystem must be immune to attack in almost all
  4543. instances. 
  4544.  
  4545.    Attempts to formalize the notion of "almost-everywhere hardness"
  4546. have been made (e.g., [GROL88]). An early characterization was
  4547. suggested by Shamir [SHAM79], who quantifies this notion by
  4548. defining a complexity measure C(n,a) for algorithms as follows:
  4549. C(n,a) is a measure of an algorithm if at least a fraction a of
  4550. problem instances of size n can be solved by the algorithm in time
  4551. C(n,a). For example, an algorithm for finding one factor of n could
  4552. have complexity C(n,1/2) = O(1), since n has a 50% chance of being
  4553. even. However, such investigations have thus far failed to produce
  4554. a comprehensive framework, although they may be useful in a few
  4555. special instances.
  4556.  
  4557.    Another simple example illustrates the difference between worst-
  4558. case and average-case complexity: as noted in [RABI76], algorithms
  4559. to sort n items are often predicated on the assumption that the
  4560. items are arranged in random order; i.e., all n! arrangements are
  4561. equally likely. If the file has a real-world origin it is more
  4562. likely that the file is already partially sorted. An optimized
  4563. algorithm might anticipate this and utilize an adaptive strategy. 
  4564.  
  4565.    In practice, a cryptosystem for which cryptanalysis has an
  4566. average-case polynomial complexity is generally worthless; in fact
  4567. this remains true if any measurable fraction of all instances
  4568. permits polynomial-time cryptanalysis (this is difficult to make
  4569. precise, since the fraction may vary with key size). Thus there is
  4570. no a priori connection between the breaking of a system and the
  4571. difficulty of the underlying problem, since the latter is
  4572. characterized in terms of worst-case complexity. For example, often
  4573. there exists a heuristic technique which yields an approximate
  4574. solution to an NP-complete problem. Such techniques may not
  4575. converge in polynomial time to an exact solution, but may break the
  4576. corresponding cryptosystem.
  4577.  
  4578.    In passing we remark that some authors (e.g., [WAGN84]) have
  4579. attempted to go beyond the Diffie/Hellman notion of utilizing NP-
  4580. complete problems to construct systems, by using the even more
  4581. intractable class of undecidable problems instead. It would be
  4582. interesting to know if such systems could be made practical.
  4583.  
  4584.    
  4585.    A.4 Probabilistic algorithms.
  4586.  
  4587.  
  4588.    Another important distinction between the classical theory of
  4589. complexity and cryptocomplexity is that the classical theory of
  4590. algorithms does not encompass probabilistic algorithms (e.g.,
  4591. [RABI76]), which again may produce rapid solutions to problems in
  4592. many instances but not even terminate in a few instances. They may
  4593. also produce answers which are probably but not necessarily
  4594. correct. Such algorithms are inappropriate in many contexts, e.g.,
  4595. real-time control settings in which a response must be guaranteed
  4596. in a fixed period of time, or where provable solutions are
  4597. required. However, they are powerful tools in both cryptography and
  4598. cryptanalysis.
  4599.  
  4600.    As noted in [RABI76], probabilistic algorithms cannot be
  4601. measured by classical criteria, which focus on worst-case runtime.
  4602. Instead, a probabilistic algorithm may involve a tradeoff between
  4603. execution time and confidence. For example, most numbers have all
  4604. small factors. If an algorithm exploits this fact it may terminate
  4605. quickly for most inputs but take exponential time when large primes
  4606. appear as factors.
  4607.  
  4608.    Gill [GILL77] models probabilistic computation by extending the
  4609. classical Turing machine model (e.g., [HORO78]) to the
  4610. probabilistic Turing machine (app. D). This has proven valuable in
  4611. the analysis of cryptographic systems, and probabilistic encryption
  4612. schemes in particular.
  4613.  
  4614.  
  4615.    A.5 Status of some relevant problems.
  4616.  
  4617.  
  4618.    The security of several major cryptosystems mentioned herein
  4619. depends on the hardness of problems whose complexity status is
  4620. unresolved. This includes factoring and discrete logarithm. The
  4621. importance of the subclass of NP-complete problems emerges in this
  4622. regard: if a problem is known to be in NP but is not known to be
  4623. NP-complete, a solution to the problem in polynomial time (placing
  4624. the problem in P) would not imply that problems such as traveling
  4625. salesman are in P. The latter proposition is widely disbelieved.
  4626.  
  4627.    A second relevant class is co-NP, the complements of problems
  4628. in NP. For example, the complement of deciding whether n is prime
  4629. is deciding if n is composite. In fact, primality and compositeness
  4630. are in both NP and co-NP. Some experts have speculated (e.g.,
  4631. [GARE79]) that P is the intersection of NP and co-NP. For example,
  4632. linear programming was known to be in both of the latter long
  4633. before its status was resolved; eventually it was shown to be in
  4634. P, via the ellipsoid method [KHAC79]. This illustrates that it
  4635. would indeed be desirable to have available cryptosystems based on
  4636. NP-complete problems (but see below).
  4637.  
  4638.    Good surveys of the status of many problems important in
  4639. security of public-key systems are given in [ADLE86] and [POME86].
  4640. Let
  4641.  
  4642.  
  4643.       L(n) = exp((1 + o(1))(ln n * ln ln n)1/2).
  4644.  
  4645.  
  4646.    Then Adleman notes that many algorithms for factoring n have
  4647. probabilistic execution times believed to be of the form L(n)c
  4648. (e.g., [SCHN84]). However, only the algorithm of Dixon [DIXO81] has
  4649. been rigorously analyzed. Similarly, various algorithms for
  4650. discrete logarithms mod p are believed to take time L(p). These
  4651. results would be viewed with mistrust in the classical theory due
  4652. to their probabilistic nature and lack of rigorous upper bounds for
  4653. worst-case or average-case times. In contrast, Adleman [ADLE83]
  4654. gives a deterministic algorithm for primality testing which
  4655. executes in time
  4656.  
  4657.  
  4658.       O((ln n)c ln ln ln n).
  4659.  
  4660.  
  4661.    In the classical theory this result would be valuable, but we
  4662. have noted that probabilistic algorithms are more efficient and far
  4663. less complex, hence much more relevant in the present setting.
  4664. Again this is indicative of the divergence between classical
  4665. complexity and cryptocomplexity.
  4666.  
  4667.    The status of the problem of taking roots mod n, i.e., solving
  4668. xe ≡ c (mod n), depends on the parameters (e.g., [SALO85]). A
  4669. polynomial-time probabilistic algorithm to find x exists if e, c
  4670. and n are fixed and n is prime. If n is composite with unknown
  4671. factors, no polynomial-time algorithm exists, even probabilistic.
  4672. If e = 2 the complexity is essentially equivalent to factoring n
  4673. (lem. N.3.2). If e > 2 the status is less clear; as a consequence
  4674. it is not clear that the security of RSA is equivalent to
  4675. factoring.
  4676.  
  4677.    Brassard [BRAS79] has shown that the discrete logarithm has an
  4678. associated decision problem which lies in the intersection of NP
  4679. and co-NP. Thus, if either factoring or taking discrete logarithms
  4680. is NP-hard, it follows from the definition of this class that the
  4681. associated decision problem is NP-complete and in co-NP. In turn
  4682. this would imply NP = co-NP, which is widely disbelieved. 
  4683.  
  4684.    More generally, in [BRAS83] a function f is called restricted
  4685. one-way if f is easily computable, f-1 is not, and f is injective
  4686. and polynomially bounded. It is shown that if restricted one-way
  4687. functions exist then P is not the intersection of NP and co-NP as
  4688. many believe; and if f is restricted one-way and f-1 is NP-hard then
  4689. NP = co-NP. Discrete logarithm is thought to be restricted one-
  4690. way.
  4691.  
  4692.    We conclude that there is little hope for fulfilling the
  4693. Diffie/Hellman quest for public-key systems based on NP-complete
  4694. problems. The same may be true of the search for one-way functions
  4695. to employ as hash functions. Prospects for use of NP-hard problems
  4696. seem difficult to assess at this time.
  4697.  
  4698.  
  4699.    Appendix B. Algorithms and architectures.
  4700.  
  4701.  
  4702.    We briefly survey some of the considerations relevant to
  4703. determining what type of hardware and software support for
  4704. cryptanalysis, or to a lesser extent encryption, may be forthcoming
  4705. from the creators of algorithms and architectures of the future.
  4706. We also mention some examples already in existence. This represents
  4707. an excursion into high-performance computing, only a small fraction
  4708. of which is applicable to cryptography. Nonetheless, in order to
  4709. evaluate security of methods or ascertain key sizes, it is
  4710. necessary to make some educated guesses as to how this field will
  4711. progress over the next few decades.
  4712.  
  4713.  
  4714.    B.1 Technology.
  4715.  
  4716.  
  4717.    Computing at present is silicon-based. Thus all estimates of
  4718. achievable computer performance are geared to this technology. The
  4719. question arises as to whether a radically different technology such
  4720. as superconductivity or optical computing will make silicon-based
  4721. performance standards obsolete, and if so, when this might occur.
  4722. We have no idea, and hence we ignore these.
  4723.  
  4724.    Gallium arsenide technology is another matter. It has already
  4725. been integrated into some existing supercomputers. Some of the
  4726. differences between GaAs and silicon VLSI are (e.g., [MILU88]):
  4727.  
  4728.  
  4729.       a. GaAs gates have a higher switching speed.
  4730.  
  4731.       b. Off-chip communication in GaAs pays a relatively higher 
  4732.           penalty.
  4733.  
  4734.       c. GaAs chips have lower density.
  4735.  
  4736.  
  4737.    Gate delays in GaAs (DCFL E/D-MESFET) may be as low as 50
  4738. picoseconds, as opposed to at least 1 nanosecond in Silicon (NMOS).
  4739. Similarly, on-chip memory access in GaAs may take as little as 500
  4740. picoseconds, as opposed to at least 10 nanoseconds in silicon. This
  4741. indicates that performance of GaAs-based computers could
  4742. theoretically be as much as 20 times greater than even the fastest
  4743. silicon-based supercomputers. However, GaAs levels of integration
  4744. are currently much lower: at most about 50,000 transistors per
  4745. chip, as opposed to 1,000,000 in silicon. This is due to problems
  4746. in GaAs of power dissipation, yield and area limitations. Thus the
  4747. number of chips necessary to build systems using GaAs is higher;
  4748. minimizing chip count is important for high performance.
  4749.  
  4750.    Off-chip communication in GaAs is another factor at the system
  4751. level. The peak performance of a computer system is limited by the
  4752. bandwidth of the slowest subsystem [HWAN84]. Inter-chip signal
  4753. propagation is not significantly different for silicon or GaAs, but
  4754. the relative effect is different: off-chip communication is more
  4755. of a bottleneck in GaAs because of its ratio to on-chip speed.
  4756. Silicon solutions to the problem of CPU speed versus other
  4757. subsystem speeds include cache and multilevel memory hierarchies;
  4758. these may not carry over mutatis mutandis to GaAs. 
  4759.  
  4760.    We conclude that at the moment, GaAs technology does not present
  4761. a real threat to silicon performance standards. Furthermore, it
  4762. does not appear likely that problems such as yield and integration
  4763. will be solved in the near future. Thus, for the remainder of
  4764. appendix B we assume no radical change in technology from the
  4765. present.
  4766.  
  4767.  
  4768.    B.2. Computing modes. 
  4769.  
  4770.  
  4771.    Classically, computing was dominated by the Von Neumann model,
  4772. with a single processor executing a single instruction scheme on
  4773. a single data stream. This paradigm reached its peak with computers
  4774. such as the Cray-1 [CRAY80] and CYBER 205 [CONT80]. However, the
  4775. performance of a single processing unit is limited by its clock
  4776. speed. It does not seem feasible to reduce major cycles much below
  4777. 1 ns with silicon technology. Furthermore, at these speeds memory
  4778. access becomes a bottleneck, not to mention I/O. Thus it is not
  4779. likely that uniprocessors will exceed 109 operations per second,
  4780. barring radical new technologies.
  4781.  
  4782.    Two alternatives to the Von Neumann model are parallel and
  4783. distributed computing (e.g., [HWAN84]). Parallel computing
  4784. generally refers to processors in one box; distributed means each
  4785. processor is in its own box. Parallel computers may (loosely) be
  4786. subdivided into shared-memory, in which all processors share a
  4787. common address space, and distributed-memory, in which each
  4788. processor has its own address space. These modes remove the
  4789. restriction on the number of instruction and/or data streams which
  4790. may be processed concurrently. In theory these modes of computing
  4791. can produce unlimited computing power, by splicing together single
  4792. processing nodes and memory units (or processor/memory pairs) into
  4793. a unified system. However, there are three major limitations in
  4794. this regard:
  4795.  
  4796.  
  4797.       a. Cost-effectiveness.
  4798.  
  4799.       b. The interconnection network.
  4800.  
  4801.       c. Parallel algorithms.
  4802.  
  4803.  
  4804.    Cost-effectiveness alone has been a deterrent to the development
  4805. of parallel systems. The Denelcor HEP (e.g., [KOWA85]), Floating
  4806. Point T-Series [HAWK87] and ETA-10 [STEI86] are examples of
  4807. parallel systems which have not proven to be commercially
  4808. successful. Also, Cray and other supercomputer manufacturers have
  4809. been reluctant to expand into large-scale parallelism, partially
  4810. because of cost-related concerns. This creates an interesting
  4811. situation from a cryptographic point of view: there may be cases
  4812. where a computer powerful enough to break a given system could be
  4813. built in theory. Security of the system might then rest on the
  4814. assumption that no one will spend the money to build it, or that
  4815. the only units built will belong to wealthy government agencies and
  4816. be subject to tight controls.
  4817.  
  4818.    Even if computers with 1000 or more powerful processors are
  4819. constructed, the question arises as to whether such a configuration
  4820. can achieve computing power in proportion to the number of
  4821. processors, i.e., linear speedup. The mode of interconnecting the
  4822. processors and memories is critical. If the shared-memory
  4823. configuration is used, with a collection of processors accessing
  4824. common memory partitioned into modules, interference in paths
  4825. through the network or in simultaneous attempts to access a module
  4826. will cause a bottleneck if a low-cost, low-bandwidth network such
  4827. as a bus is used. If a high-bandwidth network such as a crossbar
  4828. is used (i.e., with concurrent data transfers possible between many
  4829. processors and memory modules), the number of units interconnected
  4830. is limited by cost which rises as the square of the number of
  4831. processors. Thus such systems seem to be inherently limited in the
  4832. extent to which they can improve on uniprocessor performance.
  4833.  
  4834.    An alternative is to connect processor/memory pairs using a
  4835. network such as a hypercube [SEIT85]. Machines of this type with
  4836. up to 65,536 weak processing elements (e.g., the Connection Machine
  4837. [HILL85]) or up to 1024 powerful processors (e.g., the NCUBE/10
  4838. [HAYE86]) have been constructed, and systems with up to 32,000
  4839. Cray-1 level processors have been proposed. There is debate (and
  4840. some controversy) over the speedups which such distributed-memory
  4841. machines can achieve. The latter consideration is related to cost-
  4842. effectiveness, which requires nearly-linear speedup. Also, the cost
  4843. of interconnection in a hypercube-based system rises as O(n log n),
  4844. where n is the number of processor/memory pairs.
  4845.  
  4846.    Another concern is algorithms. A problem must be highly
  4847. decomposable to be amenable to parallel or distributed computation.
  4848. Furthermore, algorithms for non-Von Neumann machines must be
  4849. tailored to individual architectures to a much greater extent than
  4850. their Von Neumann counterparts, adding to the cost of software
  4851. development.
  4852.  
  4853.    Because of inherent tradeoffs between performance and cost,
  4854. there may be a divergence between the computing power attainable
  4855. in theory and that which is practical (and in the event of
  4856. commercial machines, marketable). Within 10 years it is conceivable
  4857. that machines executing 1012 operations per second could be built
  4858. with refinements of existing technology; the real question seems
  4859. to be financing.
  4860.  
  4861.    An alternative to the single-machine approach is the use of
  4862. networks for completely distributed computing (e.g., [LENS89]). The
  4863. class of problems amenable to solution via networks (and wide-area
  4864. networks in particular) is restricted, since the nodes must
  4865. communicate infrequently (typically only at the beginning and end
  4866. of a computation). Nonetheless, in section 4 it was noted that some
  4867. of the strongest cryptanalytically-related results have been
  4868. obtained by networks of computers. This is possible because many
  4869. of the relevant cryptanalytic algorithms are fully decomposable
  4870. into independent portions which do not need to interact. An example
  4871. is the quadratic sieve.
  4872.  
  4873.    It may be possible to assemble more computing power in such a
  4874. network than is present in any single computer. Once again, the
  4875. constraints are largely pragmatic. Designers of cryptosystems must
  4876. therefore attempt to anticipate not only advances in algorithms and
  4877. architectures, but also the greatest amount of computing power
  4878. which might realistically be brought to bear against a given task.
  4879.  
  4880.  
  4881.    B.3 Some relevant algorithms and implementation.
  4882.  
  4883.  
  4884.    Most of the powerful algorithms for factoring and discrete
  4885. logarithm are fairly new. As we have noted, most of them have not
  4886. been fully analyzed for runtimes. Nonetheless, some standards have
  4887. emerged in this regard. The best guess for the future can only
  4888. amount to anticipation of improvements in the present algorithms.
  4889.  
  4890.  
  4891.    B.3.1 Quadratic sieve factoring algorithm.
  4892.  
  4893.  
  4894.    The quadratic sieve [POME84] provides an alternative to the
  4895. earlier continued fraction factorization algorithm [MORR75].
  4896.  
  4897.    As noted in [DAVI83b], the continued fraction approach uses
  4898. considerable multiple precision division. The quadratic sieve works
  4899. with larger residues but involves mainly single-precision
  4900. subtraction. Both have runtimes of exp(sqrt(c ln n ln ln n)) but
  4901. c = 2 for continued fraction, c = 9/8 for the quadratic sieve.
  4902.  
  4903.    In [DAVI84] the results of implementing the quadratic sieve on
  4904. a Cray X-MP [CRAY85] are reported. Factorization of 70-digit
  4905. numbers takes about an hour; 100-digit numbers should take about
  4906. a year. The key to this match of algorithm and architecture is the
  4907. utilization of the vector capability of the Cray architecture. In
  4908. particular, a steady stream of operands is necessary to take
  4909. advantage of a pipelined, register-to-register machine. The loops
  4910. in the sieve are amenable to streaming of operands, and about 75%
  4911. efficiency was obtained. However, the multitasking capability of
  4912. the X-MP was not utilized. Since Crays with up to 16 processors are
  4913. expected in the near future, with even greater parallelism to be
  4914. anticipated, it follows that the results of such experiments are
  4915. probably too conservative. On the other hand, utilizing both vector
  4916. and parallel capabilities of a system is nontrivial, partially as
  4917. a result of memory bank contention. Furthermore, adaption of the
  4918. algorithm to exploit both capabilities may be nontrivial. Hence it
  4919. is not clear to what extent the preceding efficiency can be
  4920. maintained as the degree of parallelism grows. 
  4921.  
  4922.    An alternative is distributed computing: Silverman [SILV87] has
  4923. used the quadratic sieve implemented via a network of 9 SUN 3
  4924. workstations to factor numbers up to 80 digits in 8 weeks. Recently
  4925. another network was used to factor 106-digit numbers [LENS89].
  4926.  
  4927.    It should be noted that the results obtained via the quadratic
  4928. sieve are directly relevant cryptanalytically, since the integers
  4929. factored are general. Integers of up to 155 digits, but with
  4930. special forms, have been factored, also by use of networks
  4931. [SIAM90]. However, these results are only indirectly relevant to
  4932. systems such as RSA, assuming moduli are properly chosen. 
  4933.  
  4934.  
  4935.    B.3.2 Computations in finite fields.
  4936.  
  4937.  
  4938.    This is a subject which has been explored fairly thoroughly
  4939. (e.g., [BART63]), and we do not review it here. 
  4940.  
  4941.    Multiplication of elements in GF(m) has classically been
  4942. implemented at the circuit level using linear feedback shift
  4943. registers. However, Laws [LAWS71] has noted the potential for using
  4944. cellular arrays. These are highly amenable to VLSI implementation.
  4945. A pipeline architecture for multiplication and inverses is proposed
  4946. in [WANG85].
  4947.  
  4948.    One class of algorithms of particular interest is for discrete
  4949. logarithms in GF(pn). Still more particularly, the case n = 2 has
  4950. been explored considerably ([BLAK84],[BLAK84b],[COPP84]). Since
  4951. finite logarithms are easy to compute in GF(m) if m has only small
  4952. factors [POHL78], n should be chosen so that 2n - 1 is (a Mersenne)
  4953. prime, e.g., n = 521. However, Odlyzko [ODLY84b] notes that a next-
  4954. generation supercomputer might break n = 521 in a year. A special-
  4955. purpose computer might attack n on the order of 700 in a year.
  4956.  
  4957.    Odlyzko also notes that with similar bounds on key size, GF(p)
  4958. may be preferable to GF(2n); e.g., n = 2000 is roughly equivalent
  4959. to p of about 750 bits. As noted above, this advantage may be
  4960. counterbalanced by implementation efficiency.
  4961.  
  4962.  
  4963.    B.3.3 Other algorithms.
  4964.  
  4965.  
  4966.    Many of the most fundamental operations in this setting seem to
  4967. be characterized by inherent sequentiality. An example is
  4968. exponentiation; computing the n-th power seems to take log n steps
  4969. regardless of the number of processors available.
  4970.  
  4971.    Another classical example is greatest common divisor. Although
  4972. some partial results are noted in [ADLE86], major improvement over
  4973. Euclid does not seem forthcoming regardless of advances in
  4974. architecture.
  4975.  
  4976.    Many of the powerful factoring algorithms are highly
  4977. parallelizable (e.g., [SCHN84]). The main requirement is existence
  4978. of appropriate architectures.
  4979.  
  4980.  
  4981.    B.4. Application-specific architectures.
  4982.  
  4983.  
  4984.    General-purpose architectures such as the Cray are of interest
  4985. in this setting because of their immediate availability. At the
  4986. other extreme, architectures closely matching the algorithms of
  4987. interest could be constructed, but their over-specialized nature
  4988. would virtually preclude their commercial distribution. In between
  4989. are classes of architectures which are more versatile but not truly
  4990. general-purpose. We note several examples of partly-specific
  4991. architectures and a proposed highly-specific machine.
  4992.  
  4993.  
  4994.    B.4.1 Systolic and wavefront arrays.
  4995.  
  4996.  
  4997.    The notion of systolic arrays ([KUNG82],[KUNG78]) is an
  4998. extension of pipelining. The idea is to have a collection of
  4999. processors operate on data which is pulsed rhythmically through the
  5000. array. If the original requirement of a synchronous mode of
  5001. operation is relaxed, the result is a wavefront array [KUNG82b].
  5002. Both types were originally targeted at applications such as signal
  5003. processing which are compute-intensive and involve repetitions of
  5004. operations on many operands. 
  5005.  
  5006.    A systolic array for the computation of GCDs is proposed in
  5007. [BREN83]. It is very amenable to VLSI implementation because of its
  5008. regular topology. Furthermore it is linear, limiting I/O
  5009. requirements which can constitute a bottleneck in VLSI
  5010. implementations. Supporting algorithms are noted in [BREN83b].
  5011.  
  5012.    It would be of interest to know what a more general-purpose
  5013. linear systolic array such as the Warp [ANNA87] (which curiously
  5014. more closely resembles a wavefront array) could accomplish on some
  5015. of the problems discussed in this paper, and factoring in
  5016. particular. The Warp is already in production.
  5017.  
  5018.    
  5019.    B.4.2 Proposal for a quadratic sieve machine.
  5020.  
  5021.  
  5022.    Pomerance et al. [POME88] describe a pipeline architecture which
  5023. would efficiently execute the quadratic sieve. This notion is of
  5024. considerable interest to anyone implementing an algorithm such as
  5025. RSA, since such a machine could presumably factor numbers beyond
  5026. the reach of present-day supercomputers.
  5027.  
  5028.    Cost-effectiveness is carefully analyzed, as is critical for an
  5029. application-specific architecture. They speculate that a $50,000
  5030. version of the architecture should factor 100-digit numbers in
  5031. about 2 weeks; or 140 digits in a year on a $10 million version;
  5032. or 200 digits in 1 year on a $100 billion version. It should be
  5033. noted that the last is clearly predicated on the notion that the
  5034. architecture and algorithm will scale linearly with the number of
  5035. processing units; we noted earlier that various bottlenecks such
  5036. as inter-processor communication and memory access make this
  5037. somewhat dubious. Nonetheless the possibility arises that moduli
  5038. approaching 200 digits may be necessary in RSA because of the
  5039. potential existence of machines such as these. 
  5040.  
  5041.    The crux of the architecture are the pipe and pipe I/O units.
  5042. These should be custom and should be able to handle variable
  5043. strides without the considerable loss of efficiency which usually
  5044. accompanies nonconstant stride. The two units should be chained
  5045. together. The pipe should consist of stages, all of which are bus-
  5046. connected to the pipe I/O unit. The cycle time of memory should be
  5047. the same as the processing elements.
  5048.  
  5049.    It is interesting to note that this architecture bears a close
  5050. resemblance to a linear systolic array.
  5051.  
  5052.  
  5053.    B.4.3 Massively parallel machines.
  5054.  
  5055.  
  5056.    An alternative to pipelined machines is to configure a large
  5057. number of primitive processing elements in an array and have them
  5058. execute the same instruction stream synchronously, processing a
  5059. large quantity of data in parallel (SIMD mode). Such machines are
  5060. generally applied to real-time image or signal processing, or to
  5061. large-scale matrix operations. 
  5062.  
  5063.    The MPP [BATC80] is an example. It consists of 16,384 processors
  5064. in a square array. It was intended mainly for image processing of
  5065. data from satellites; but in [WUND83] and [WILL87] it is used for
  5066. an implementation of the continued-fraction factoring algorithm.
  5067. Wunderlich [WUND85] also implements this algorithm on the DAP
  5068. (e.g., [HOCK81]), another massively parallel machine with 4096
  5069. processors. Unlike the MPP, the DAP has been marketed.
  5070.  
  5071.  
  5072.    Appendix C. The classical theory of computation.
  5073.  
  5074.  
  5075.    In appendix A a number of topics from the classical theory of
  5076. computation were mentioned. Here we give a more precise treatment
  5077. of some notions from the classical theory (e.g., [LEWI81]).
  5078.  
  5079.    An alphabet is a finite set of symbols. A string is a sequence
  5080. of symbols from an alphabet. A language on an alphabet is a set of
  5081. strings from the alphabet.  If S is an alphabet, S* denotes the set
  5082. of all strings from S, including the empty string. Concatenation
  5083. of strings a and b is written ab. If A and B are subsets of S*, AB
  5084. is the set of strings formed by concatenating elements from A and
  5085. B.
  5086.  
  5087.  
  5088.    C.1 Turing machines.
  5089.  
  5090.  
  5091.    A (one-tape, deterministic) Turing machine is a quadruple
  5092. (K,S,D,s) where:
  5093.  
  5094.  
  5095.       a. S is an alphabet which contains a blank = #, but not the 
  5096.          symbols L or R which are reserved for tape movement to the 
  5097.          left or right.
  5098.  
  5099.       b. K is a set of states which does not include the halt state 
  5100.          = h, which signals an end to computation.
  5101.  
  5102.       c. s = initial state; it is in K.
  5103.  
  5104.       d. D : K x S -> (K + {h}) x (S + {L,R}) where + denotes    
  5105.           union.
  5106.  
  5107.  
  5108.    A Turing machine = M may be interpreted semi-physically as
  5109. consisting of a control unit and a tape. At any time M is in some
  5110. state, and the read/write head of the tape is over some symbol on
  5111. the tape. If D(q,a) = (p,b) then initially the head is scanning a
  5112. and M is in state q; its next move will be to enter state p. If b
  5113. is in S the head will set a := b without moving; otherwise b = L
  5114. or R in which case the head will move to the left or right. M halts
  5115. when state h is entered. or M hangs (the left end of the tape is
  5116. surpassed). The tape has no right end. 
  5117.  
  5118.    Input to M consists of a string. The string is padded by a # on
  5119. each side and placed on the leftmost squares of the tape. The rest
  5120. of the tape consists of #'s. Initially the head is positioned over
  5121. the # which marks the right end of the input. Initially M is in
  5122. state s; its first move is thus D(s,#).
  5123.  
  5124.    At a given time M is in configuration (q,w,a,u), where:
  5125.  
  5126.  
  5127.       a. q = state (element of K + {h}).
  5128.  
  5129.       b. w = portion of the tape to the left of the head (element 
  5130.          of S*).
  5131.  
  5132.       c. a = symbol under the head (element of S).
  5133.  
  5134.       d. u = portion of the tape to the right of the head.
  5135.  
  5136.  
  5137.    If e denotes the empty string, u in (d) is required to be an
  5138. element of (S*)(S-{#})+{e}; i.e., either u = e, meaning the tape
  5139. has all #'s to the right of the head, or the last symbol of u is
  5140. the last nonblank symbol to the right of the head position. This
  5141. gives the configuration a unique description. In particular, if the
  5142. input to M is w then the initial configuration of M is (s,#w,#,e).
  5143.  
  5144.    M is said to halt on input w if some halted configuration (state
  5145. = h) is reached from (s,#w,#,e) in a finite number of steps; then
  5146. it is said that (s,#w,#,e) yields a halted configuration. If M
  5147. halts on input w, M is said to accept w. The language accepted by
  5148. M is the set of strings w accepted by M. Conversely, a language is
  5149. said to be Turing-acceptable if it is accepted by some Turing
  5150. machine.
  5151.  
  5152.    Suppose S is an alphabet, T and W are subsets of S, and 
  5153. f: W -> T. Suppose there exists a Turing machine M = (K,S,D,s) such
  5154. that for any w in W, the configuration (s,#w,#,e) yields
  5155. (h,#u,#,e), i.e., u is the output of M on input w, and furthermore
  5156. u = f(w). Then f is said to be computed by M.
  5157.  
  5158.    Suppose alphabet A does not contain #, Y or N. Suppose L is a
  5159. language in A* and X is its characteristic function, i.e., for w
  5160. in A*, X(w) = Y if w is in L, X(w) = N otherwise. If X is computed
  5161. by Turing machine M then M is said to decide (or recognize) L.
  5162. Conversely, if X is the characteristic function of a language L and
  5163. X is Turing-computable, i.e., there exists a Turing machine which
  5164. computes X, then L is said to be Turing-decidable.
  5165.  
  5166.    An extension of the basic model is to permit the control unit
  5167. to control (a finite number of) multiple tapes. However, a language
  5168. accepted by a multitape Turing machine is also accepted by a one-
  5169. tape Turing machine; i.e., additional tapes do not increase the
  5170. computing power of Turing machines in terms of expanding the class
  5171. of languages accepted.
  5172.  
  5173.  
  5174.    C.2 Nondeterministic Turing machines.
  5175.  
  5176.  
  5177.    The preceding Turing machines were deterministic; i.e., D was
  5178. a function: if D(q,a) = (p,b) then the next state p and scanned
  5179. symbol b were uniquely determined by the present state q and symbol
  5180. a. A nondeterministic Turing machine is defined similarly except
  5181. that D is now a relation on
  5182.  
  5183.  
  5184.         (K x S) x ((K + {h}) x (S + {L,R})).
  5185.  
  5186.  
  5187.    That is, D is now multiple-valued, so that the next
  5188. configuration is no longer uniquely determined by the present.
  5189. Instead, in a given number of steps a configuration may yield a
  5190. number of configurations. Consequently an input may yield many
  5191. outputs. A sequence of steps starting from a given input defines
  5192. a computation; in general many computations are possible on one
  5193. input. A nondeterministic machine is said to accept an input if
  5194. there exists a halting computation on it. Again the language
  5195. accepted by a machine is the set of strings accepted by it.
  5196. Trivially any language accepted by nondeterministic machines is
  5197. also accepted by deterministic machines, which are merely special
  5198. cases of the more general nondeterministic case.
  5199.  
  5200.    It is also true (but not as trivial) that any language accepted
  5201. by a nondeterministic Turing machine is also accepted by a
  5202. deterministic Turing machine. That is, nondeterminism does not
  5203. increase the power of Turing machines insofar as the class of
  5204. languages is concerned.
  5205.  
  5206.    Similar extensions hold for decidable languages.
  5207.  
  5208.  
  5209.    C.3 Computational complexity.
  5210.  
  5211.  
  5212.    The time complexity of Turing machines is measured by the number
  5213. of steps taken by a computation. If T is a function on the
  5214. nonnegative integers, a deterministic Turing machine M is said to
  5215. decide language L in time T if it decides in time T(n) or less
  5216. whether w is or is not in L, where w has length n. If T is a
  5217. polynomial then L is said to be decided in polynomial time. If a
  5218. language is decidable in polynomial time on a multitape
  5219. deterministic Turing machine then it is decidable in polynomial
  5220. time on a one-tape Turing machine.
  5221.  
  5222.    A nondeterministic Turing machine M is said to accept w in time
  5223. T if there is halting computation on w of T(n) or fewer steps,
  5224. where w has length n. M is said to accept language L in time T if
  5225. it accepts each string in L in time T. 
  5226.  
  5227.    The class of languages decidable in polynomial time on some
  5228. deterministic Turing machine is denoted by P. The class of
  5229. languages acceptable in polynomial time on some nondeterministic
  5230. Turing machine is denoted by NP. 
  5231.  
  5232.    It is not known whether P = NP.
  5233.  
  5234.  
  5235.    Appendix C. The classical theory of computation.
  5236.  
  5237.  
  5238.    In appendix A a number of topics from the classical theory of
  5239. computation were mentioned. Here we give a more precise treatment
  5240. of some notions from the classical theory (e.g., [LEWI81]).
  5241.  
  5242.    An alphabet is a finite set of symbols. A string is a sequence
  5243. of symbols from an alphabet. A language on an alphabet is a set of
  5244. strings from the alphabet.  If S is an alphabet, S* denotes the set
  5245. of all strings from S, including the empty string. Concatenation
  5246. of strings a and b is written ab. If A and B are subsets of S*, AB
  5247. is the set of strings formed by concatenating elements from A and
  5248. B.
  5249.  
  5250.  
  5251.    C.1 Turing machines.
  5252.  
  5253.  
  5254.    A (one-tape, deterministic) Turing machine is a quadruple
  5255. (K,S,D,s) where:
  5256.  
  5257.  
  5258.       a. S is an alphabet which contains a blank = #, but not the 
  5259.          symbols L or R which are reserved for tape movement to the 
  5260.          left or right.
  5261.  
  5262.       b. K is a set of states which does not include the halt state 
  5263.          = h, which signals an end to computation.
  5264.  
  5265.       c. s = initial state; it is in K.
  5266.  
  5267.       d. D : K x S -> (K + {h}) x (S + {L,R}) where + denotes    
  5268.           union.
  5269.  
  5270.  
  5271.    A Turing machine = M may be interpreted semi-physically as
  5272. consisting of a control unit and a tape. At any time M is in some
  5273. state, and the read/write head of the tape is over some symbol on
  5274. the tape. If D(q,a) = (p,b) then initially the head is scanning a
  5275. and M is in state q; its next move will be to enter state p. If b
  5276. is in S the head will set a := b without moving; otherwise b = L
  5277. or R in which case the head will move to the left or right. M halts
  5278. when state h is entered. or M hangs (the left end of the tape is
  5279. surpassed). The tape has no right end. 
  5280.  
  5281.    Input to M consists of a string. The string is padded by a # on
  5282. each side and placed on the leftmost squares of the tape. The rest
  5283. of the tape consists of #'s. Initially the head is positioned over
  5284. the # which marks the right end of the input. Initially M is in
  5285. state s; its first move is thus D(s,#).
  5286.  
  5287.    At a given time M is in configuration (q,w,a,u), where:
  5288.  
  5289.  
  5290.       a. q = state (element of K + {h}).
  5291.  
  5292.       b. w = portion of the tape to the left of the head (element 
  5293.          of S*).
  5294.  
  5295.       c. a = symbol under the head (element of S).
  5296.  
  5297.       d. u = portion of the tape to the right of the head.
  5298.  
  5299.  
  5300.    If e denotes the empty string, u in (d) is required to be an
  5301. element of (S*)(S-{#})+{e}; i.e., either u = e, meaning the tape
  5302. has all #'s to the right of the head, or the last symbol of u is
  5303. the last nonblank symbol to the right of the head position. This
  5304. gives the configuration a unique description. In particular, if the
  5305. input to M is w then the initial configuration of M is (s,#w,#,e).
  5306.  
  5307.    M is said to halt on input w if some halted configuration (state
  5308. = h) is reached from (s,#w,#,e) in a finite number of steps; then
  5309. it is said that (s,#w,#,e) yields a halted configuration. If M
  5310. halts on input w, M is said to accept w. The language accepted by
  5311. M is the set of strings w accepted by M. Conversely, a language is
  5312. said to be Turing-acceptable if it is accepted by some Turing
  5313. machine.
  5314.  
  5315.    Suppose S is an alphabet, T and W are subsets of S, and 
  5316. f: W -> T. Suppose there exists a Turing machine M = (K,S,D,s) such
  5317. that for any w in W, the configuration (s,#w,#,e) yields
  5318. (h,#u,#,e), i.e., u is the output of M on input w, and furthermore
  5319. u = f(w). Then f is said to be computed by M.
  5320.  
  5321.    Suppose alphabet A does not contain #, Y or N. Suppose L is a
  5322. language in A* and X is its characteristic function, i.e., for w
  5323. in A*, X(w) = Y if w is in L, X(w) = N otherwise. If X is computed
  5324. by Turing machine M then M is said to decide (or recognize) L.
  5325. Conversely, if X is the characteristic function of a language L and
  5326. X is Turing-computable, i.e., there exists a Turing machine which
  5327. computes X, then L is said to be Turing-decidable.
  5328.  
  5329.    An extension of the basic model is to permit the control unit
  5330. to control (a finite number of) multiple tapes. However, a language
  5331. accepted by a multitape Turing machine is also accepted by a one-
  5332. tape Turing machine; i.e., additional tapes do not increase the
  5333. computing power of Turing machines in terms of expanding the class
  5334. of languages accepted.
  5335.  
  5336.  
  5337.    C.2 Nondeterministic Turing machines.
  5338.  
  5339.  
  5340.    The preceding Turing machines were deterministic; i.e., D was
  5341. a function: if D(q,a) = (p,b) then the next state p and scanned
  5342. symbol b were uniquely determined by the present state q and symbol
  5343. a. A nondeterministic Turing machine is defined similarly except
  5344. that D is now a relation on
  5345.  
  5346.  
  5347.         (K x S) x ((K + {h}) x (S + {L,R})).
  5348.  
  5349.  
  5350.    That is, D is now multiple-valued, so that the next
  5351. configuration is no longer uniquely determined by the present.
  5352. Instead, in a given number of steps a configuration may yield a
  5353. number of configurations. Consequently an input may yield many
  5354. outputs. A sequence of steps starting from a given input defines
  5355. a computation; in general many computations are possible on one
  5356. input. A nondeterministic machine is said to accept an input if
  5357. there exists a halting computation on it. Again the language
  5358. accepted by a machine is the set of strings accepted by it.
  5359. Trivially any language accepted by nondeterministic machines is
  5360. also accepted by deterministic machines, which are merely special
  5361. cases of the more general nondeterministic case.
  5362.  
  5363.    It is also true (but not as trivial) that any language accepted
  5364. by a nondeterministic Turing machine is also accepted by a
  5365. deterministic Turing machine. That is, nondeterminism does not
  5366. increase the power of Turing machines insofar as the class of
  5367. languages is concerned.
  5368.  
  5369.    Similar extensions hold for decidable languages.
  5370.  
  5371.  
  5372.    C.3 Computational complexity.
  5373.  
  5374.  
  5375.    The time complexity of Turing machines is measured by the number
  5376. of steps taken by a computation. If T is a function on the
  5377. nonnegative integers, a deterministic Turing machine M is said to
  5378. decide language L in time T if it decides in time T(n) or less
  5379. whether w is or is not in L, where w has length n. If T is a
  5380. polynomial then L is said to be decided in polynomial time. If a
  5381. language is decidable in polynomial time on a multitape
  5382. deterministic Turing machine then it is decidable in polynomial
  5383. time on a one-tape Turing machine.
  5384.  
  5385.    A nondeterministic Turing machine M is said to accept w in time
  5386. T if there is halting computation on w of T(n) or fewer steps,
  5387. where w has length n. M is said to accept language L in time T if
  5388. it accepts each string in L in time T. 
  5389.  
  5390.    The class of languages decidable in polynomial time on some
  5391. deterministic Turing machine is denoted by P. The class of
  5392. languages acceptable in polynomial time on some nondeterministic
  5393. Turing machine is denoted by NP. 
  5394.  
  5395.    It is not known whether P = NP.
  5396.  
  5397.  
  5398.    Appendix D. The theory of probabilistic computing.
  5399.  
  5400.  
  5401.    Probabilistic algorithms are employed as adjuncts in
  5402. cryptosystems for purposes such as finding primes. They have also
  5403. produced virtually all major practical cryptanalytic algorithms for
  5404. factoring, discrete logarithm etc. Here we review an extension of
  5405. the classical theory of computation which incorporates
  5406. probabilistic computing. This extension has proven particularly
  5407. valuable in the study of probabilistic cryptosystems.
  5408.  
  5409.    An ordinary deterministic multitape Turing machine may be
  5410. considered to have an input tape, an output tape, and read-write
  5411. worktapes. A modification of the ordinary model (e.g., [GILL77])
  5412. is the probabilistic Turing machine. It has a distinguished state
  5413. called the coin-tossing state, which permits the machine to make
  5414. random decisions. In terms of languages recognized, these have the
  5415. same power as deterministic machines. However, time considerations
  5416. are more subtle. In particular, a notion of probabilistic run time
  5417. is needed, rather than measures such as maximum run time used for
  5418. ordinary machines. 
  5419.  
  5420.    A probabilistic Turing machine operates deterministically,
  5421. except when it is in a special coin-tossing state (or states). In
  5422. such a state the machine may enter either of two possible next
  5423. states. The choice between these is made via the toss of an
  5424. unbiased coin. The sequence of coin tosses may be considered to
  5425. constitute the contents of an auxiliary read-only input tape, the
  5426. random tape, which contains a binary string. Thus a computation by
  5427. a probabilistic machine is a function of two variables, the
  5428. ordinary input tape and the random tape. 
  5429.  
  5430.    If the random tape is unspecified, the output of the computation
  5431. of probabilistic machine M, M(x), is a random variable (e.g.,
  5432. [MCEL77]): M produces output y with probability Pr{M(x) = y}. For
  5433. a given input x, there may exist a y such that Pr{M(x) = y} > 1/2.
  5434. Such a y is clearly unique if it exists, in which case we can write
  5435. q(x) = y. This defines a partial function: q is undefined if no
  5436. such y exists. The partial function q is said to be computed by M.
  5437. The set accepted by M is the domain of q.
  5438.  
  5439.    If x is accepted by M let e(x) = Pr{M(x) != y}. It is direct
  5440. from definition that e(x) < 1/2. Suppose there exists a constant
  5441. c < 1/2 such that e(x) <= c for all x in the domain of e. Then it
  5442. may be said that M has bounded error probability (the error
  5443. probability e is bounded away from 1/2), another concept important
  5444. in zero-knowledge frameworks.  
  5445.  
  5446.    Again leaving the random tape unspecified, Pr{M(x) = y in time
  5447. n} is the probability that probabilistic Turing machine M with
  5448. input x gives output y in some computation of at most n steps. The
  5449. probabilistic run time T(x) of M is defined to be infinity if x is
  5450. not accepted by M, i.e., if x is not in the domain of the partial
  5451. function q computed by M. If x is in the domain of q, T(x) is the
  5452. smallest n such that Pr{M(x) = q(x) in time n} > 1/2. This is
  5453. somewhat analogous to defining the run time of a nondeterministic
  5454. Turing machine to be the length of the shortest accepting
  5455. computation.
  5456.  
  5457.    A function is probabilistically computable if it is computed by
  5458. some probabilistic Turing machine. There are many important
  5459. examples of functions which are probabilistically computable in
  5460. polynomial probabilistic run time and bounded error probability,
  5461. but are not known to be computable in polynomial deterministic
  5462. time, i.e., in P. An example is the characteristic function of the
  5463. set of primes, which is probabilistically computable in polynomial
  5464. time (e.g., [SOLO77]), but for which no deterministic algorithm is
  5465. known. 
  5466.  
  5467.    Let BPP be the class of languages recognized by polynomial-
  5468. bounded probabilistic Turing machines with bounded error
  5469. probability. Letting < denote inclusion, it follows easily that P
  5470. < BPP < NP. An important question, with implications for schemes
  5471. such as RSA as well as zero-knowledge schemes, probabilistic
  5472. encryption etc., is whether either of these inclusions is proper.
  5473.  
  5474.  
  5475.    Appendix E. Breaking knapsacks.
  5476.  
  5477.  
  5478.    We give a brief account of the demise of the Merkle/Hellman
  5479. trapdoor knapsack public-key system and some of its variants. A
  5480. much more complete discussion is given in [BRIC88].
  5481.  
  5482.    We recall from section 4.2.1 that the security of this approach
  5483. rests on the difficulty of solving knapsack problems of the form
  5484.  
  5485.  
  5486.       C = b1 * M1 + ... + bn * Mn,
  5487.  
  5488.  
  5489. where the {bi} are obtained from superincreasing {ai} by modular
  5490. "disguising:"
  5491.  
  5492.  
  5493.       bi = w * ai mod u.
  5494.  
  5495.  
  5496.    Around 1982, several authors (e.g.[DESM83]) made the observation
  5497. that if W * w ≡ 1 (mod u), where W may be found as in appendix H,
  5498. then for some {ki},
  5499.  
  5500.  
  5501.       ai = W * bi - u * ki.
  5502.  
  5503.  
  5504.    In particular
  5505.  
  5506.  
  5507.       a1 = W * b1 - u * k1,
  5508.  
  5509.  
  5510. and hence
  5511.  
  5512.  
  5513.       bi * k1 - b1 * ki = (b1 * ai - bi * a1)/u.
  5514.  
  5515.  
  5516.    Since u > a1 +...+ an, bi < u, and a1 < ai,
  5517.  
  5518.  
  5519.       |bi * k1 - b1 * ki| < uai/(a1+...+an).
  5520.  
  5521.  
  5522.    Now it is easily shown that
  5523.  
  5524.  
  5525.       ai+j ≥ 2j-1 * (ai + 1),
  5526.  
  5527.  
  5528. and hence
  5529.  
  5530.  
  5531.       |bi * k1 - b1 * ki| < 2i+1-n * u.
  5532.  
  5533.  
  5534.    Thus
  5535.  
  5536.  
  5537.       |k1/ki - b1/bi| < 2i+1-n*u/kibi < 2i+1-n*u/bi.
  5538.  
  5539.  
  5540.    This shows that the {ki} are in fact not random; they are
  5541. determinable via the above inequalities if u is known. Shamir
  5542. [SHAM84b] observed that an intruder merely seeks any trapdoor, as
  5543. represented by any u, w, and {ai} which produce an easy knapsack.
  5544. Thus the last inequality may be regarded as an integer programming
  5545. problem. In this particular instance Shamir noted that the
  5546. algorithm of Lenstra [LENS83] is applicable, together with
  5547. classical methods of Diophantine approximation. This yields the
  5548. {ki}, and the system is then broken easily. 
  5549.  
  5550.    Lenstra's algorithm made use of the Lovasz lattice basis
  5551. reduction algorithm [LENS82], one of the basic tools in "unusually
  5552. good" simultaneous diophantine approximation [LAGA84]. This
  5553. approach was utilized by Adleman [ADLE82] to break the
  5554. Shamir/Graham knapsack, and by Brickell [BRIC84] to break the
  5555. iterated Merkle/Hellman knapsack. The multiplicative version was
  5556. broken by Odlyzko [ODLY84]. In fact all major proposed knapsacks
  5557. based on modular disguises have been broken using this approach. 
  5558.  
  5559.    It should be noted that the low-density attacks
  5560. ([BRIC83],[LAGA83]) are successful where finding trapdoors fails.
  5561. These use a measure of density for a knapsack with coefficients
  5562. b1,...,bn defined by density = n/(log max {bi}). This type of attack
  5563. is independent of whether the knapsack is a disguised version of
  5564. another. Trapdoors, in contrast, are easiest to find for high-
  5565. density knapsacks.
  5566.  
  5567.    The concept of density is related to two important parameters
  5568. of cryptosystems, namely information rate and expansion factor d.
  5569. In [LAGA84] the information rate is defined to be the ratio of the
  5570. size of plaintext to the maximum size of the ciphertext. This is
  5571. the reciprocal of d, i.e., ciphertext/plaintext. Information rate
  5572. is essentially the same as density, although for the above knapsack
  5573. and modulus u it is defined slightly differently, namely as n/(log
  5574. nu). Both definitions are derived from approximations to the actual
  5575. ciphertext size, which is log(b1 * M1+...+bn * Mn). Lagarias notes
  5576. that the attack in [SHAM84b] runs in time O(P(n)*nd) for a
  5577. polynomial P. Hence the attack is feasible if d is fixed but not
  5578. if the expansion factor d is large. This illustrates the
  5579. interrelation between security and practicality.
  5580.  
  5581.  
  5582.    Appendix F. Birthday attacks.
  5583.  
  5584.  
  5585.    In section 4 we noted several usages of birthday attacks against
  5586. hash functions. Here we give a brief summary of the relevant
  5587. mathematics.
  5588.  
  5589.    Suppose H is a function which has m possible outputs. Whenever
  5590. H outputs a value it is totally random and independent of any
  5591. previous values which have been output.
  5592.  
  5593.    If H is evaluated k times, each output is akin to an object
  5594. placed in one of m cells corresponding to the range of H. Since the
  5595. k values of H are independent, any object could be placed in any
  5596. of m cells; the total number of ways of distributing the k objects
  5597. is mk. If no two objects are to be placed in any cell (i.e. if
  5598. there are to be no collisions in applying H k times), the first
  5599. object can be placed anywhere; the second can go in any of the m-
  5600. 1 remaining cells; the third in m-2 cells; etc. The total number
  5601. of ways of distributing the objects is m(m-1)...(m-k+1) (sometimes
  5602. called a falling factorial). The probability of no collisions is
  5603. m(m-1)...(m-k+1)/mk. Hence the probability of at least one
  5604. collision is
  5605.  
  5606.  
  5607.       P(m,k) = 1 - (m-1)...(m-k+1)/mk-1
  5608.  
  5609.              = 1 - (1 - 1/m)...(1 - (k-1)/m).
  5610.  
  5611.  
  5612.    This yields
  5613.  
  5614.  
  5615.    LEMMA F.1. Suppose the function H, with m possible outputs, is
  5616. evaluated k times, where m > k > (2cm)1/2 for some constant c. Then
  5617. the probability of at least one collision (i.e., x and y with H(x)
  5618. = H(y) for some x,y) is at least 1 - e-c, e = 2.718...
  5619.  
  5620.  
  5621.    Proof: for 0 < x < 1,
  5622.  
  5623.  
  5624.       1 - x < 1 - x + x2(1 - x/3)/2 + x4(1 - x/5)/24 + ...
  5625.  
  5626.             = e-x.
  5627.  
  5628.  
  5629.    For k < m this gives
  5630.  
  5631.  
  5632.       (1 - 1/m)...(1 - (k-1)/m) < e-1/m...-(k-1)/m)
  5633.  
  5634.                                 = e-k(k-1)/2m.
  5635.  
  5636.  
  5637.    Thus
  5638.  
  5639.  
  5640.       P(m,k) > 1 - e-k(k-1)/2m
  5641.  
  5642.  
  5643.    The lemma follows. QED.
  5644.  
  5645.  
  5646.    EXAMPLE F.1. Suppose the H of lemma F.1 is evaluated k times
  5647. where k > (2(ln 2)m)1/2 = 1.17 * m1/2. Then the probability of at
  5648. least one collision is > 1/2.
  5649.  
  5650.  
  5651.    This suggests an attack on hash functions. Its name derives from
  5652. the classical problem of computing the probability that two members
  5653. of a group of people have the same birthday.
  5654.  
  5655.  
  5656.    Appendix G. Modular arithmetic and Galois fields.
  5657.  
  5658.  
  5659.    We give a brief introduction to arithmetic modulo n where n is
  5660. a positive integer. A ring structure may be imposed on Zn =
  5661. {0,1,...,n-1} by doing addition, subtraction and multiplication mod
  5662. n (e.g., [DENN83], [HERS64] or any book on elementary number
  5663. theory). We use GCD for greatest common divisor; i.e., GCD(x,y) =
  5664. n if n is the largest positive integer dividing x and y. For n >
  5665. 1 let
  5666.  
  5667.  
  5668.       Zn* = {x ε Zn : x > 0 and GCD(x,n) = 1}.
  5669.  
  5670.  
  5671.    For example, Z10* = {1,3,7,9}. That is, Zn* consists of the
  5672. nonzero elements of Zn which are relatively prime to n. 
  5673.  
  5674.  
  5675.    If a ε Zn* let
  5676.  
  5677.       a * Zn* = {a * x mod n : x ε Zn*}.
  5678.  
  5679.  
  5680.    For example, 2 * Z10* = {2,6,14,18} mod 10 = {2,6,4,8}, 3 * Z10*
  5681. = {3,9,21,27} mod 10 = Z10*. We have:
  5682.  
  5683.  
  5684.    LEMMA G.1. Suppose n > 1 and a ε Zn*. Then
  5685.  
  5686.       a. For any x and y: a * x ≡ a * y ( mod n ) iff x ≡ y (mod 
  5687.           n).
  5688.  
  5689.       b. a * Zn* = Zn*.
  5690.  
  5691.       c. a has a multiplicative inverse modulo n; i.e.           
  5692.           there exists b ε Zn* such that b * a ≡ 1 (mod n).     
  5693.  
  5694.  
  5695.    Proof: if x ≡ y (mod n) then trivially a * x ≡ a * y (mod n).
  5696. Conversely, suppose a * x ≡ a * y (mod n). Then n | (a * (x - y)).
  5697. But GCD(a,n) = 1, so n | (x - y), i.e. x ≡ y (mod n). Thus (a)
  5698. holds.
  5699.  
  5700.    For (b): if x ε Zn* then GCD(x,n) = 1, so GCD(a*x,n) = 1. Thus
  5701. a * x mod n ε Zn*. Hence a * Zn* is contained in Zn*. By (a), if a *
  5702. x ≡ a * y (mod n), then x ≡ y (mod n). Thus a * Zn* consists of n
  5703. distinct elements, and cannot be a proper subset of Zn*; (b)
  5704. follows. In particular, since 1 ε Zn*, there exists some b ε Zn* such
  5705. that a * b mod n = 1; (c) follows. QED.
  5706.  
  5707.  
  5708.    G.1 The Euler Phi function.
  5709.  
  5710.  
  5711.    The cardinality of a set S is denoted by |S|. In particular,|Zn*|
  5712. is denoted by φ(n), the Euler totient function.
  5713.  
  5714.  
  5715.    LEMMA G.1.1.
  5716.  
  5717.       a. If p is prime then φ(p) = p-1.
  5718.  
  5719.       b. If n = p * q, p and q prime, then φ(n) = (p-1)(q-1). 
  5720.  
  5721.  
  5722.    Proof: (a) is trivial, since Zp* = {1,...,p-1}.
  5723.  
  5724.    For (b): let Yp = {p,...,(q-1)p}, i.e., the nonzero elements of
  5725. Zn divisible by p. Let Yq = {q,...,(p-1)q}, i.e., the nonzero
  5726. elements of Zn divisible by q. If a * p = b * q, then p | b and q
  5727. | a; hence a * p and b * q cannot be in Yp and Yq, respectively.
  5728. Thus Yp and Yq are disjoint. Letting + denote disjoint union,
  5729.  
  5730.  
  5731.       Zn = {0} + Yp + Yq + Zn*.
  5732.  
  5733.  
  5734.    Taking cardinalities,
  5735.  
  5736.  
  5737.       p * q = 1 + q-1 + p-1 + |Zn*|.
  5738.  
  5739.  
  5740.    Then (b) follows. QED.
  5741.  
  5742.  
  5743.    G.2 The Euler-Fermat Theorem.
  5744.  
  5745.  
  5746.    LEMMA G.2.1 (Euler's Theorem). Suppose n > 0 and a ε Zn*. Then
  5747.  
  5748.  
  5749.       aφ(n) ≡ 1 (mod n).
  5750.  
  5751.  
  5752.    Proof: if Zn* = {r1,...,rm} then a restatement of (b) of lemma G.1
  5753. is 
  5754.  
  5755.  
  5756.       {a * r1 mod n, ... , a * rm mod n} = Zn*.
  5757.  
  5758.  
  5759.    Hence
  5760.  
  5761.  
  5762.       a * r1 * ... * a * rm ≡ r1 * ... * rm (mod n).
  5763.  
  5764.  
  5765.    Thus
  5766.  
  5767.  
  5768.       am * r1 * ... * rm ≡ r1 *... * rm (mod n).
  5769.  
  5770.  
  5771.    By (a) of lemma G.1, each ri above may be canceled, leaving
  5772.  
  5773.  
  5774.       am ≡ 1 (mod n).
  5775.  
  5776.  
  5777.    Noting that by definition m = φ(n) gives Euler's Theorem. QED.
  5778.  
  5779.  
  5780.    COROLLARY G.2.1 (Fermat's Theorem). Suppose p is prime and a ε
  5781. Zp*. Then
  5782.  
  5783.  
  5784.       ap-1 ≡ 1 (mod p).
  5785.  
  5786.  
  5787.    Proof: use (a) of lemma G.1.1 in lemma G.2.1. QED.
  5788.  
  5789.  
  5790.    COROLLARY G.2.2. Suppose n > 0, a ε Zn*, and x ≡ 1 (mod m) where
  5791. m = φ(n). Then ax ≡ a (mod n).
  5792.  
  5793.  
  5794.    Proof: we have x = m * y + 1 for some y. Now by lemma G.2.1,
  5795.  
  5796.  
  5797.       ax ≡ (am)y * a ≡ 1y * a ≡ a (mod n).
  5798.  
  5799.  
  5800.    QED.
  5801.  
  5802.  
  5803.    COROLLARY G.2.3. Suppose n > 0. Let m = φ(n). Suppose e and d
  5804. are in Zm* and e * d ≡ 1 (mod m). Let E(M) = Me mod n and D(C) = Cd
  5805. mod n. Then D(E(M)) = E(D(M)) = M for any M in [0,n).
  5806.  
  5807.  
  5808.    Proof: 
  5809.  
  5810.  
  5811.       D(E(M)) ≡ (Me mod n)d mod n ≡ Me*d mod n ≡ M (mod n).
  5812.  
  5813.  
  5814.    The last step uses corollary G.2.2. Also 0 ≤ D(E(M)) < n and 0
  5815. ≤ M < n, so D(E(M)) = M. Similarly E(D(M)) = M. QED.
  5816.  
  5817.  
  5818.    G.3 Galois fields.
  5819.  
  5820.  
  5821.    Lemma G.1 shows that Zn* is an abelian group (e.g., [HERS64] p.
  5822. 27) under the operation of multiplication modulo n; Zn* is called
  5823. the multiplicative group of units of Zn. 
  5824.  
  5825.    In particular, if p is prime then Zp* = {1,...,p-1} is a group;
  5826. i.e., each nonzero element of Zp has a multiplicative inverse
  5827. modulo p. Thus the ring Zp = {0,1,...,p-1} is in fact a finite
  5828. field (e.g., [HERS64] p. 84) with p elements. 
  5829.  
  5830.    It can be shown (e.g., [HERS64] p. 314) that every finite field
  5831. has pn elements for some prime p. These are called the Galois
  5832. fields, and denoted GF(pn). We have already noted that GF(p) = Zp
  5833. is defined by doing arithmetic modulo p. The elements of Zp are
  5834. called the residues modulo p; i.e., each integer x has a unique
  5835. representation x = q * p + r where r ε Zp. To define GF(pn) we
  5836. choose an irreducible polynomial f(x) of degree n in the ring of
  5837. polynomials modulo p (e.g., [DENN83] p. 49). Now arithmetic may be
  5838. defined on this ring of polynomials, modulo f(x); i.e., write g(x)
  5839. ≡ h(x) iff f(x) is a divisor of g(x) - h(x). Each polynomial g(x)
  5840. has a unique representation g(x) = q(x)f(x) + r(x) for some
  5841. polynomial r(x) of degree at most n-1. The residues modulo f(x) are
  5842. the elements of GF(pn). These consist of polynomials of degree ≤ n-
  5843. 1 with coefficients from Zp. Each of the n coefficients of a
  5844. residue has p possible values, accounting for the pn element count
  5845. for GF(pn).
  5846.  
  5847.  
  5848.    Appendix H. Euclid's algorithm.
  5849.  
  5850.  
  5851.    On a number of occasions we referred to Euclid's algorithm,
  5852. which can be used to find greatest common divisors and
  5853. multiplicative inverses. We give some versions of it here. These
  5854. versions are recursive, and minimize storage requirements.
  5855.  
  5856.    Suppose x and y are arbitrary positive integers. Their greatest
  5857. common divisor GCD(x,y) can be computed in O(log max{x,y}) steps
  5858. by recursively employing GCD(s,t) = GCD(s,t mod s). This is
  5859. Euclid's algorithm:
  5860.  
  5861.  
  5862.       function GCD(x,y) returns integer;
  5863.          /* return greatest common divisor of x > 0 and y > 0 */
  5864.          s := x; t := y; 
  5865.          while (s > 0) do
  5866.             div := s; s := t mod s; t := div;
  5867.          end while;
  5868.          return(div);
  5869.       end GCD;
  5870.  
  5871.  
  5872.    This is readily generalized to
  5873.  
  5874.  
  5875.       function Multi_GCD(m; x : array[0..m]);
  5876.          /* for m > 0 return greatest common divisor of 
  5877.             x1,...,xm > 0 */
  5878.          if (m = 1) return(x1)
  5879.          else return(GCD(xm,Multi_GCD(m-1,x)));
  5880.       end Multi_GCD;
  5881.  
  5882.  
  5883.    The above runs in O(m * log max{xi}) time.
  5884.  
  5885.    For x ε Zn*, with latter as in appendix G, a simple extension of
  5886. GCD yields the multiplicative inverse of x modulo n, i.e., u with
  5887. x * u ≡ 1 (mod n). With [y] denoting the largest integer ≤ y, the
  5888. extended Euclid algorithm to find u is:
  5889.  
  5890.  
  5891.       function INVERSE(n,x) returns integer;
  5892.          /* for n > 0 and x ε Zn* return u ε Zn* 
  5893.             with u * x ≡ 1 (mod n) */
  5894.          procedure Update(a,b);
  5895.             temp := b; b := a - y * temp; a := temp;
  5896.          end Update;
  5897.          g := n; h := x; w := 1; z := 0; v := 0; r := 1;
  5898.          while (h > 0) do
  5899.             y : = [g/h]; Update(g,h); Update(w,z); Update(v,r);
  5900.          end while;
  5901.          return(v mod n);
  5902.       end INVERSE;
  5903.  
  5904.  
  5905.    For example, for n = 18, x = 7, this gives the values
  5906.  
  5907.  
  5908.       g:        18  7   4   3   1
  5909.       h:        7   4   3   1   0
  5910.       w:        1   0   1  -1   2
  5911.       z:        0   1  -1   2  -7
  5912.       v:        0   1  -2   3  -5
  5913.       r:        1  -2   3  -5  18
  5914.       y:            2   1   1   3
  5915.  
  5916.  
  5917.    Finally u = -5 mod 18 = 13 is returned. This is equivalent to
  5918. finding the sequence 7/18, 2/5, 1/3, 1/2, 0/1 in which each
  5919. neighboring pair is a pair of Farey fractions; a/b and c/d are
  5920. Farey fractions (e.g., [RADE64]) if a * d - b * c = ±1. We have
  5921. found 2 * 18 - 5 * 7 = 1, so that -5 * 7 ≡ 1 (mod 18), or
  5922. equivalently 13 * 7 ≡ 1 (mod 18). Thus finding multiplicative
  5923. inverses modulo n can also be done in O(log n) steps.
  5924.  
  5925.    This will also find s with u * x + s * n = 1: take s = (1 - u
  5926. * x) / n. More generally we have (with GCD(x) = x):
  5927.  
  5928.  
  5929.       procedure Coeffs(m; x : in array[1..m]; u : out array[1..m]);
  5930.          /* given m > 0 and x1,...,xm > 0 with GCD(x1,...,xm) = 1, 
  5931.             find u1,...,um with u1x1 + ... + umxm = 1 */
  5932.          if (m = 1) return(x1)
  5933.          else
  5934.             g = Multi_GCD(m-1,x);
  5935.             for i := 1 to m-1 do yi := xi/g;
  5936.             Coeffs(m-1,y,u');
  5937.             um := INVERSE(g,xm);
  5938.             b := (1 - um*xm)/g;
  5939.             for i := 1 to m-1 do ui := b*ui';
  5940.          end else;
  5941.       end Coeffs;
  5942.  
  5943.  
  5944.    This runs in O(m*log max{xi}) time.
  5945.  
  5946.  
  5947.    Appendix I. The Chinese Remainder Theorem.
  5948.  
  5949.  
  5950.    The Chinese Remainder Theorem is useful for purposes such as
  5951. simplifying modular arithmetic. In particular we note in a later
  5952. appendix that its use increases the efficiency of decryption in
  5953. RSA.
  5954.  
  5955.    We begin with a special case: with Zn as in appendix G, we have
  5956.  
  5957.  
  5958.    LEMMA I.1. Suppose p and q are primes and p < q. Then:
  5959.  
  5960.  
  5961.       a. For arbitrary a ε Zp and b ε Zq, there exists a unique   
  5962.          x ε Zpq with 
  5963.  
  5964.             x ≡ a (mod p),
  5965.  
  5966.             x ≡ b (mod q).
  5967.  
  5968.       b. If u * q ≡ 1 (mod p), the x in (a) is given by 
  5969.  
  5970.             x = (((a - b) * u) mod p) * q + b.
  5971.  
  5972.  
  5973.    Proof: we note that for any y and s, 0 ≤ y mod s ≤ s-1. Thus if
  5974. x and u are as in (b), 0 ≤ x ≤ (p-1) * q + q - 1 = p * q - 1. Hence
  5975. x ε Zpq. Trivially x ≡ b (mod q). Also 
  5976.  
  5977.  
  5978.       x ≡ (((a - b) * u) mod p) * q + b
  5979.  
  5980.         ≡ (a - b) * u * q + b
  5981.  
  5982.         ≡ (a - b) * 1 + b
  5983.  
  5984.         ≡ a   (mod p).
  5985.  
  5986.  
  5987.    Thus x is a solution to the simultaneous linear system in (a).
  5988. To show that it is unique, suppose x' ≡ a (mod p) and x' ≡ b (mod
  5989. q). Then for some k and m, x - x' = k * p = m * q. Thus k = q * k'
  5990. for some k'; hence x - x' = p * q * k', i.e., x' = x - p * q * k'.
  5991. Since 0 ≤ x ≤ p * q - 1, if k' > 0 then x' < 0; if k' < 0 then x'
  5992. ≥ p * q. Hence x' ε Zpq iff k' = 0, i.e., x' = x. QED.
  5993.  
  5994.    We note that in (b) above, u can be found via the INVERSE
  5995. function of appendix H.
  5996.  
  5997.    The condition p < q is arbitrary, but useful in noting
  5998.  
  5999.    COROLLARY I.1. Suppose p and q are primes, p < q, 0 ≤ x < p *
  6000. q, and a = x mod p, b = x mod q. Then
  6001.  
  6002.  
  6003.       a. x = (((a - (b mod p)) * u) mod p) * q + b    
  6004.                                                  (a ≥ b mod p)
  6005.  
  6006.       b. x = (((a + p - (b mod p)) * u) mod p) * q + b   
  6007.                                                  (a ≤ b mod p)
  6008.  
  6009.  
  6010.    Proof: immediate from lemma I.1. QED.
  6011.  
  6012.  
  6013.    The corollary provides an optimal framework for representing x
  6014. via a and b, i.e., the residues of x modulo p and q, respectively.
  6015.  
  6016.    Although the most general case of the Chinese Remainder Theorem
  6017. is not used in this exposition, we remark that the above can be
  6018. extended:
  6019.  
  6020.  
  6021.    THEOREM I.1. Given pairwise relatively prime moduli {p1,...,pn}
  6022. and arbitrary {a1,...,an}, there exists a unique x ε [0,p1*..*pn)
  6023. satisfying x ≡ ai (mod pi) for each i.
  6024.  
  6025.  
  6026.    Proof: a straightforward generalization of the above (e.g.,
  6027. [DENN83] p. 47).
  6028.  
  6029.  
  6030.    Appendix J. Quadratic residues and the Jacobi symbol.
  6031.  
  6032.  
  6033.    Quadratic residues play a role in primality testing as we note
  6034. in a later appendix. In appendices O and P we also note their usage
  6035. in encryption.
  6036.  
  6037.    Let Zn* be as in appendix G. For a positive integer n and a ε Zn*,
  6038. a is called a quadratic residue modulo n if x2 ≡ a (mod n) for some
  6039. x; otherwise a is a quadratic nonresidue. 
  6040.  
  6041.  
  6042.    LEMMA J.1. Suppose n > 0 and a is a quadratic residue modulo n.
  6043. Then every y with y2 ≡ a (mod n) has the form y = x + k * n where
  6044. k is an integer and x ε Zn*.
  6045.  
  6046.  
  6047.    Proof: suppose y2 ≡ a (mod n). Let x = y mod n. Then x ε [0,n).
  6048. Also, x2 ≡ a (mod n). Now x2 = a + j * n for some j. Suppose for
  6049. some m we have m > 0, m | x and m | n. Then m | a, so m = 1 since
  6050. GCD(a,n) = 1. Hence x ε Zn*; also y = x + k * n for some k. QED.
  6051.  
  6052.  
  6053.    Thus the square roots of a quadratic residue modulo n can be
  6054. taken to be elements of Zn*; all other square roots are obtained by
  6055. adding multiples of n to these.
  6056.  
  6057.  
  6058.    J.1 Quadratic residues modulo a prime.
  6059.  
  6060.  
  6061.    If p is prime and 0 < a < p, a is a quadratic residue modulo p
  6062. if and only if x2 ≡ a (mod p) for some x with 0 < x < p. For
  6063. example, the quadratic residues modulo 7 are
  6064.  
  6065.  
  6066.       {12,22,32,42,52,62} mod 7 = {1,2,4}.
  6067.  
  6068.  
  6069.    The quadratic nonresidues modulo 7 are {3,5,6}.
  6070.  
  6071.    Given a prime p, let s = (p-1)/2 and
  6072.  
  6073.  
  6074.       Sp = {x2 mod p : 0 < x ≤ s}.
  6075.  
  6076.  
  6077.    Then Sp is a set of quadratic residues modulo p. In fact we have
  6078.  
  6079.  
  6080.    LEMMA J.1.1. Suppose p > 2 is prime. Let s = (p-1)/2. Then
  6081.  
  6082.       a. The elements of Sp are precisely the quadratic residues  
  6083.          modulo p.
  6084.  
  6085.       b. There are s quadratic residues modulo p.
  6086.  
  6087.       c. There are s quadratic nonresidues modulo p.
  6088.  
  6089.  
  6090.    Proof: as noted above, Sp is a subset of the set of quadratic
  6091. residues modulo p. Furthermore, if x2 ≡ y2 (mod p) then p | x2-y2;
  6092. hence p | x-y or p | x+y. If x and y are in (0,s] then 1 < x+y <
  6093. p; thus p | x-y; hence x = y. It follows that Sp contains distinct
  6094. elements. QED.
  6095.  
  6096.    Now suppose a is a quadratic residue, x2 ≡ a (mod p), and x ε
  6097. Zp*. We note 
  6098.  
  6099.  
  6100.       (p - x)2 ≡ p2 - 2 * p * x + x2 ≡ a (mod p).
  6101.  
  6102.  
  6103.    Since 0 < x < p, either x or p - x is in (0,s]. It follows that
  6104. a ε Sp. Thus the set of quadratic residues modulo p is contained in
  6105. S. Hence the two sets are identical, establishing (a). Since |Sp|
  6106. = s, (b) follows. Also, the complement of Sp in Zp* is the set of
  6107. quadratic nonresidues modulo p. Since |Zp*| = 2s, the complement of
  6108. Sp also has cardinality s; (c) follows. QED.
  6109.  
  6110.  
  6111.    J.2 The Jacobi symbol.
  6112.  
  6113.  
  6114.    If p is a prime > 2 and 0 < a < p, the Legendre symbol (a/p) is
  6115. a characteristic function of the set of quadratic residues modulo
  6116. p (e.g., [RADE64]):         
  6117.  
  6118.  
  6119.         a. (a/p) = 1 if a is a quadratic residue mod p.
  6120.  
  6121.         b. (a/p) = -1 if a is a quadratic nonresidue mod p.
  6122.  
  6123.  
  6124.    More generally, if k > 1 is odd and h is in Zk*, the Jacobi
  6125. symbol (h/k) may be defined as follows:
  6126.  
  6127.  
  6128.       a. The Jacobi symbol (h/p) coincides with the Legendre symbol 
  6129.          if p is prime. 
  6130.  
  6131.       b. If k = p1*...*pm with pi prime, (h/k) = (h/p1)*...*(h/pm). 
  6132.  
  6133.  
  6134.     An efficient mode for computing the Jacobi symbol is via the
  6135. recursion:
  6136.  
  6137.  
  6138.       a. (1/k) = 1.
  6139.  
  6140.       b. (a*b/k) = (a/k)(b/k).
  6141.  
  6142.       c. (2/k) = 1 if (k2-1)/8 is even, -1 otherwise.
  6143.  
  6144.       d. (b/a) = ((b mod a)/a).
  6145.  
  6146.       e. If GCD(a,b) = 1:
  6147.  
  6148.          i. (a/b)(b/a) = 1 if (a-1)(b-1)/4 is even.
  6149.  
  6150.          ii. (a/b)(b/a) = -1 if (a-1)(b-1)/4 is odd.
  6151.  
  6152.  
  6153.    The key step in the recursion is (e), which is Gauss' law of
  6154. quadratic reciprocity (e.g., [RADE64]). The above shows that the
  6155. Jacobi symbol (a/n) can be computed in O(log n) steps.
  6156.  
  6157.  
  6158.    J.3 Square roots modulo a prime.
  6159.  
  6160.  
  6161.    Regarding solutions of x2 ≡ a (mod p), i.e., the square roots of
  6162. a modulo p, we have:
  6163.  
  6164.  
  6165.    LEMMA J.3.1. Suppose p > 2 is prime. Let s = (p-1)/2. Suppose
  6166. a is a quadratic residue modulo p. Then
  6167.  
  6168.  
  6169.       a. a has exactly two square roots modulo p in Zp*. One of   
  6170.          these lies in (0,s] and the other in (s,p-1].
  6171.  
  6172.       b. the square roots of a modulo p can be found in          
  6173.           probabilistic polynomial time.
  6174.  
  6175.  
  6176.    Proof: by lemma J.1.1 we know that a ε Sp as defined in J.1;
  6177. hence there exists a unique x in (0,s] with x2 ≡ a (mod p). Then y
  6178. = p - x satisfies y2 ≡ a (mod p), and y is in (s,p-1]. Conversely,
  6179. suppose y is in (s,p-1] and y2 ≡ a (mod p). Then x = p - y is in
  6180. (0,s], and x2 ≡ a (mod p). Hence y is unique. Thus we have (a).
  6181.  
  6182.    For (b) we invoke a probabilistic polynomial-time algorithm for
  6183. finding square roots modulo a prime (e.g., [PERA86] or p. 22 of
  6184. [KRAN86]). QED.
  6185.  
  6186.  
  6187.    J.4 Quadratic residuosity modulo a prime.
  6188.  
  6189.  
  6190.    Deciding quadratic residuosity plays a role in both primality
  6191. testing and probabilistic encryption. For a prime p > 2, to decide
  6192. whether a given element a ε Zp* is a quadratic residue modulo p,
  6193. define
  6194.  
  6195.  
  6196.       ep(a) = as mod p     (s = (p-1)/2).
  6197.  
  6198.  
  6199.    Then we have
  6200.  
  6201.  
  6202.    LEMMA J.4.1. If p > 2 is a prime and a ε Zp*, ep(a) = 1 if and
  6203. only if a is a quadratic residue modulo p; ep(a) = p - 1 if and
  6204. only if a is a quadratic nonresidue modulo p.
  6205.  
  6206.  
  6207.    Proof: by the Euler/Fermat Theorem (cor. G.2.1), ep(a)2 ≡ 1 (mod
  6208. p). By lemma J.3.1, 1 has exactly two square roots modulo p in Zp*,
  6209. namely 1 and p - 1. Hence ep(a) = 1 or p - 1. If a is a quadratic
  6210. residue modulo p, then a = x2 mod p for some x with 0 < x < p. Then
  6211. ep(a) = xp-1 mod p. Again by Euler/Fermat, ep(a) = 1. Thus all s
  6212. quadratic residues a satisfy as - 1 = 0 (mod p). An s-th degree
  6213. congruence modulo p has at most s solutions (e.g., [RADE64] p. 21).
  6214. Thus all quadratic nonresidues b must have ep(b) = p - 1. QED.
  6215.  
  6216.  
  6217.    Also, ep can be evaluated in O(log p) time. Thus quadratic
  6218. residuosity mod p can be decided in O(log p) time.
  6219.  
  6220.  
  6221.    Appendix K. Primitive roots and discrete logarithms.
  6222.  
  6223.  
  6224.    The use of primitive roots was noted in sections 2.2 and 4.2.2.
  6225. We also observed that the security of exponentiation-based
  6226. cryptosystems depends in part on the difficulty of computing
  6227. discrete logarithms. Here we briefly explore these topics.
  6228.  
  6229.    Let Zp* be as in appendix G. Suppose p is a prime and a ε Zp*.
  6230. Suppose m > 0, am ≡ 1 (mod p), but ar !≡ 1 (mod p) for any r with
  6231. 0 < r < m. Then we say that a belongs to the exponent m modulo p.
  6232. The existence of m is guaranteed by the Euler/Fermat Theorem (cor.
  6233. G.2.1), which shows m < p. Let
  6234.  
  6235.  
  6236.       Cp(a) = {ax mod p : 0 ≤ x < m}.
  6237.  
  6238.  
  6239.    Then we have
  6240.  
  6241.  
  6242.    LEMMA K.1. Suppose p is prime, a ε Zp*, and a belongs to the
  6243. exponent m modulo p. Then:
  6244.  
  6245.  
  6246.       a. Cp(a) contains distinct elements; i.e. |Cp(a)| = m.
  6247.  
  6248.       b. Cp(a) is a cyclic subgroup of Zp*.
  6249.  
  6250.       c. m | p-1.
  6251.  
  6252.  
  6253.      Proof: suppose Cp(a) does not contain distinct elements. Then
  6254. for some {k,j} in [0,m) with k < j we have ak ≡ aj (mod p). Thus 
  6255. aj-k ≡ 1 (mod p), contradiction. This gives (a). Now suppose x and
  6256. y are in [0,m) and x + y = k * m + r where r is in [0,m). Since am
  6257. ≡ 1 (mod p), ax * ay mod p = ar mod p. Thus Cp(a) is closed under
  6258. multiplication, and forms a subgroup of Zp*; this is called the
  6259. cyclic subgroup generated by a (e.g., [HERS64]). This gives (b).
  6260. The order of a subgroup divides the order (= p - 1) of the whole
  6261. group Zp* (ibid). This gives (c). QED. 
  6262.  
  6263.    If g belongs to the exponent p - 1 modulo prime p, g is called
  6264. a primitive root modulo p. 
  6265.  
  6266.  
  6267.    LEMMA K.2. Suppose p is a prime and g is a primitive root modulo
  6268. p. Then Cp(g) = Zp*; that is, each y ε [1,p) has a unique
  6269. representation y = gx mod p for some x ε [0,p-1).
  6270.  
  6271.  
  6272.    Proof: Cp(g) is a subset of Zp*. The result follows from lemma
  6273. K.1, which shows |Cp(g)| = p - 1 = |Zp*|. QED.
  6274.  
  6275.  
  6276.    The x in lemma K.2 is the discrete logarithm, or index, of y
  6277. modulo p with base = g. However, the range of the logarithm can be
  6278. any interval of length p - 1. We have used [0,p-2], but, e.g., we
  6279. could also take x to lie in [1,p-1].
  6280.  
  6281.    A restatement of lemma K.2 is that the cyclic subgroup generated
  6282. by the primitive root g modulo p is the whole group Zp*. Thus g is
  6283. a generator of Zp*.
  6284.  
  6285.  
  6286.    LEMMA K.3. Suppose p > 2 is prime and p-1 has k distinct prime
  6287. factors which are known. Then:
  6288.  
  6289.  
  6290.       a. The number of primitive roots modulo p is φ(p-1), where 
  6291.           φ is the Phi function (app. G.1).
  6292.  
  6293.       2. Testing a given a to determine if it is a primitive root 
  6294.          modulo p can be done in time O(k * log p) = O((log p)2).
  6295.  
  6296.  
  6297.    Proof: for (a) see, e.g., [RADE64] p. 49. For (b), if the
  6298. exponent of a modulo p is m, then m | p-1 by lemma K.1. Now m < p -
  6299. 1 iff m | (p-1)/q for some prime factor q of p, whence a(p-1)/q ≡ 1
  6300. (mod p). Thus a is a primitive root modulo p iff a(p-1)/q !≡ 1 (mod
  6301. p) for each prime factor q of p. This condition can be tested for
  6302. each of the k factors in O(log p) time. Clearly k = O(log p). QED.
  6303.  
  6304.  
  6305.    In particular, if p has the form 2q + 1 for prime q, it is easy
  6306. to find the exponent m modulo p for a given a, since m = 2, q, or
  6307. 2q. It is also easy to find primitive roots modulo p: φ(p-1) = q -
  6308.  1 = (p-3)/2; thus for large p, a random element of Zp* has about
  6309. a 1/2 probability of being a primitive root.
  6310.  
  6311.  
  6312.    LEMMA K.4. Suppose p > 2 is prime and g is a primitive root
  6313. modulo p. Let s = (p-1)/2. Then:
  6314.  
  6315.  
  6316.        a. gs ≡ -1 (mod p).
  6317.  
  6318.        b. g is a quadratic nonresidue modulo p.
  6319.  
  6320.  
  6321.    Proof: for (a): we note g0 ≡ 1 (mod p). Since g is a generator
  6322. of {1,g,...,gp-2} and 0 < s < p-1 we thus know gs !≡ 1 (mod p). Also,
  6323. g2s ≡ 1 (mod p), so that gs is a square root of 1 modulo p. By lemma
  6324. J.3.1, 1 has exactly two square roots modulo p, namely 1 and -1.
  6325. Thus gs ≡ -1 (mod p). 
  6326.  
  6327.    For (b): suppose x2 ≡ g (mod p). Now x ≡ gr (mod p) for some r;
  6328. hence g2r ≡ g (mod p), and g2r-1 ≡ 1 (mod p). Thus 2r - 1 ≡ 0 (mod p-
  6329. 1), impossible since p - 1 is even. QED. 
  6330.  
  6331.  
  6332.    Appendix L. Primality testing.
  6333.  
  6334.  
  6335.    Testing large integers to determine whether they are prime plays
  6336. a major role in key generation in RSA and other public-key systems.
  6337. We give a few examples of algorithms to effect this.
  6338.  
  6339.    It is well-known (e.g., [KNUT81] p. 366) that if the number of
  6340. primes between 1 and x is f(x), then with ln denoting natural
  6341. logarithm (to base e = 2.718..),
  6342.  
  6343.  
  6344.       f(x) = x/(ln x) + O(x/(ln x)2).
  6345.  
  6346.  
  6347.    The number of primes between x and x + h is f(x + h) - f(x), and
  6348. hence the probability that a number between x and x + h is prime
  6349. is roughly
  6350.  
  6351.  
  6352.       (f(x+h)-f(x))/h = f'(x) = 1/(ln x) - 1/(ln x)2.
  6353.  
  6354.  
  6355.    That is, roughly ln x numbers must be tested before a prime is
  6356. found near x; but the evens may be ignored, so that roughly (ln
  6357. x)/2 odd numbers need be tested. For example, about (ln 10100)/2 =
  6358. 115 odd numbers must be tested to find a prime of about 100 digits.
  6359. If multiples of small primes > 2 are eliminated, even fewer numbers
  6360. need be tested before a prime is found (e.g., [GORD84]).
  6361.  
  6362.    A number of tests have been given to establish the primality of
  6363. a candidate. Proving primality deterministically (i.e., with
  6364. certainty) is less difficult than factoring or computing discrete
  6365. logarithms, but is nonetheless nontrivial. For example, the
  6366. algorithms of [ADLE83] or [COHE84] could be used; but they have a
  6367. run time on the order of
  6368.  
  6369.  
  6370.       (log n)c log log log n.
  6371.  
  6372.  
  6373.    Such deterministic algorithms are computationally infeasible or
  6374. inadvisable unless high-performance computers are used for key
  6375. generation. This may be undesirable even if a high-performance
  6376. computer is available, since it may not constitute a
  6377. cryptographically secure environment. For key generation on, e.g.,
  6378. personal computers or smart cards, which is preferable from a
  6379. security standpoint, more efficient algorithms are desirable. Thus,
  6380. probabilistic tests may be used in practice to make an "educated
  6381. guess" as to whether a candidate is prime. 
  6382.  
  6383.    Often a Monte Carlo approach is employed. In this event there
  6384. is a slight possibility of an erroneous conclusion; however, the
  6385. error probability can be made arbitrarily small. Typically, a
  6386. sequence of "witnesses" attest to the primality or compositeness
  6387. of a number. Agreement among a group of about 100 witnesses is
  6388. generally sufficient to reach a conclusion beyond any reasonable
  6389. doubt, although evidently the legality of this procedure has not
  6390. been tested in the courts.
  6391.  
  6392.  
  6393.    L.1 The Solovay/Strassen test.
  6394.  
  6395.  
  6396.    One example of a probabilistic polynomial-time primality test
  6397. is the Solovay/Strassen test [SOLO77] mentioned in section 4.1.1
  6398. (although this approach is commonly attributed to Solovay and
  6399. Strassen, it was noted implicitly by Lehmer [LEHM76]; cf.
  6400. [LENS86]). If n is an odd positive integer and a ε Zn*, with the
  6401. latter as in Appendix G, let
  6402.  
  6403.  
  6404.       e(a,n) ≡ a(n-1)/2 (mod n), -1 ≤ e(a,n) ≤ n - 2.
  6405.  
  6406.  
  6407.    For convenience we have e(a,n) take on the value -1 instead of
  6408. the usual n - 1.
  6409.  
  6410.    If p is prime we have e(a,p) ≡ ep(a) (mod p) with ep as in
  6411. appendix J.4. Lemma J.4.1 shows that e(a,p) = (a/p), where the
  6412. latter is the Jacobi symbol (app. J.3). The latter equality thus
  6413. provides evidence of primality. That is, if p is prime and a ε Zn*
  6414. then e(a,p) = (a/p). Per se this is useless, but the contrapositive
  6415. provides a proof of compositeness: if (a/n) ■ e(a,n) then n is
  6416. composite. Also, both (a/n) and e(a,n) can be computed in O(log n)
  6417. steps, so this proof of compositeness runs in deterministic
  6418. polynomial time. The converse is more subtle. Suppose n is an odd
  6419. positive integer and 0 < a < n. If GCD(a,n) > 1 then n is certainly
  6420. composite. Let
  6421.  
  6422.  
  6423.       G = {a ε Zn*: (a/n) = e(a,n)}.
  6424.  
  6425.  
  6426.    Now the Jacobi symbol is multiplicative; i.e.,
  6427.  
  6428.  
  6429.       (a*b/n) = (a/n) * (b/n).
  6430.  
  6431.  
  6432.    Also
  6433.  
  6434.  
  6435.       e(a*b,n) ≡ e(a,n) * e(b,n)    (mod n).
  6436.  
  6437.  
  6438.    That is, e is also multiplicative. It follows that G is a
  6439. subgroup of Zn*. The order of G must divide the order of Zn*  (e.g.,
  6440. [HERS64] p. 35). Thus if G ■ Zn*, G has cardinality at most (n-
  6441. 1)/2. Solovay and Strassen showed that indeed G ■ Zn* if n is
  6442. composite. Hence if n is composite and a is chosen at random, the
  6443. probability that a is in G is at most 1/2. We thus test as follows:
  6444.  
  6445.  
  6446.       function Solovay_Strassen(a,n) returns charstring;
  6447.          /* for n > 2, n odd, a ε Zn, decides probabilistically   
  6448.             whether n is prime */
  6449.          if (GCD(a,n) > 1) return("composite")
  6450.          else
  6451.             if ((a/n) = e(a,n)) return("prime")
  6452.             else return("composite");
  6453.       end Solovay_Strassen;
  6454.  
  6455.  
  6456.    We will certainly reach a correct conclusion in any of the
  6457. following cases:
  6458.  
  6459.  
  6460.       a. n is prime.
  6461.  
  6462.       b. n is composite and GCD(a,n) > 1.
  6463.  
  6464.       c. n is composite, GCD(a,n) = 1, and (a/n) ■ e(a,n).
  6465.  
  6466.  
  6467.    In the remaining case, i.e. n is composite, GCD(a,n) = 1, and
  6468. (a/n) = e(a,n), n "masquerades" as a prime due to the perjury of
  6469. a. But such an a is in G above; hence the probability of false
  6470. testimony from an a is at most 1/2 in this case. If 100 random a's
  6471. are used as witnesses, we conclude n is prime or composite with
  6472. probability of error zero if n is prime, and at most 2-100 otherwise. 
  6473. At most 6 * log n operations are needed (see [SOLO77]).
  6474.  
  6475.  
  6476.    L.2 Lehman's test.
  6477.  
  6478.  
  6479.    Lehman [LEHM82] noted that the Jacobi function is not needed in
  6480. Monte Carlo testing for primality. He defines
  6481.  
  6482.  
  6483.       e'(a,n) = a(n-1)/2 mod n,
  6484.  
  6485.       G = {e'(a,n) : a ε Zn*}.
  6486.  
  6487.  
  6488.    We note that e' differs only slightly from e, taking on the
  6489. value p - 1 instead of -1.
  6490.  
  6491.    He shows that if n is odd, G = {1,p-1} iff n is prime. Again 100
  6492. a's are tested, but only a(n-1)/2 mod n is computed. If anything
  6493. except 1 or -1 is found, n is composite. If only 1's and -1's are
  6494. found, conclude n is prime if any -1's are found; otherwise
  6495. conclude n is composite. Again the probability of error is at most
  6496. 2-100.
  6497.  
  6498.  
  6499.    L.3 The Miller/Rabin test.
  6500.  
  6501.  
  6502.    Another Monte Carlo test was noted by Miller [MILL76] and Rabin
  6503. [RABI80]. If n - 1 = u * 2k where u is odd and k > 0, let exp(i) =
  6504. 2i, 0 ≤ i ≤ k - 1. If a ■ Zn* then a is a witness to the
  6505. compositeness of n if au !≡ 1 (mod n) and au*exp(i) !≡ -1 (mod n), 0
  6506. ≤ i ≤ k - 1. Again, e.g., 100 witnesses may be tested; if none
  6507. attest to compositeness of n then n may be assumed prime.
  6508.  
  6509.    When n ≡ 3 (mod 4) this test is similar to Lehman's.
  6510.  
  6511.  
  6512.    Appendix M. Mathematics of RSA and other exponential systems.
  6513.  
  6514.  
  6515.    In section 1.5 the basic exponential cipher was introduced;
  6516. i.e., E(M) = Mk mod p, D(C) = CI mod p, where K * I ≡ 1 (mod p-1).
  6517. We recall (appendix H) that I can be computed from K using Euclid's
  6518. algorithm in O(log p) time. Also, by lemma G.1.1 we have φ(p) = p-
  6519. 1. Thus, by corollary G.2.3 we have D(E(M)) = M and E(D(C)) = C.
  6520.  
  6521.    The RSA system is analogous: we have E(M) = Me mod n, D(C) = Cd
  6522. mod n, n = p * q, e * d ≡ 1 (mod m), m = (p-1)(q-1). By lemma G.1.1
  6523. we have φ(n) = m, so once again corollary G.2.3 gives D(E(M)) = M
  6524. and E(D(C)) = C.
  6525.  
  6526.    We have noted in appendix L how the Solovay/Strassen or Lehman
  6527. tests can be used to choose p and q efficiently, i.e., in O(log n)
  6528. steps. However, these involve multiple-precision arithmetic
  6529. [KNUT81]. Hence the total time can be significant, especially in
  6530. software.
  6531.  
  6532.    Once p and q have been chosen, e is chosen easily; then d is
  6533. computed via e * d ≡ 1 (mod m). This can be done in O(log n) steps
  6534. using INVERSE from appendix H. Thus key material can be generated
  6535. in linear time.
  6536.  
  6537.    Encryption is easy since e can be chosen small. However,
  6538. efficient decryption requires the Chinese remainder theorem. In
  6539. general we have
  6540.  
  6541.  
  6542.       (y mod n) mod p = y mod p,
  6543.  
  6544.       (y mod n) mod q = y mod q.
  6545.  
  6546.  
  6547.    Suppose we are given ciphertext C; we wish to efficiently
  6548. compute 
  6549.  
  6550.  
  6551.       M = Cd mod n.
  6552.  
  6553.  
  6554.    To use the machinery of appendix I, let y = Cd and x = M = y mod
  6555. n. Then 
  6556.  
  6557.  
  6558.       a = Cd mod p,
  6559.  
  6560.       b = Cd mod q.
  6561.  
  6562.  
  6563.    Also, suppose d = k * (p - 1) + r. Then by the Euler/Fermat
  6564. theorem,
  6565.  
  6566.  
  6567.       a = (Cp-1)k * Cr mod p = 1k * Cr mod p = (C mod p)r mod p.
  6568.  
  6569.  
  6570.    Similarly if d = j * (q - 1) + s,
  6571.  
  6572.  
  6573.       b = (C mod q)s mod q.
  6574.  
  6575.  
  6576.    Also r = d mod p-1 and s = d mod q-1. Thus by corollary I.1, an
  6577. algorithm for decryption [QUIS82] is as follows:
  6578.  
  6579.  
  6580.       a. Compute
  6581.  
  6582.             i.  a = (C mod p)d mod (p-1) mod p,
  6583.  
  6584.             ii. b = (C mod q)d mod (q-1) mod q.
  6585.  
  6586.       b. Find u with 0 < u < p and
  6587.  
  6588.             u * q ≡ 1   (mod p).
  6589.  
  6590.       c. Use one of
  6591.  
  6592.             i.  M = (((a - (b mod p)) * u) mod p) * q + b       
  6593.                                                  (a ≥ b mod p),
  6594.  
  6595.             ii. M = (((a + p - (b mod p)) * u) mod p) * q + b   
  6596.                                                  (a < b mod p).  
  6597.  
  6598.  
  6599.  
  6600.    These represent roughly optimal formulae for deciphering. Again
  6601. u is found easily using INVERSE, and M is easy to compute once a
  6602. and b have been found. Finding a and b requires at most 2 log p and
  6603. 2 log q multiplications, respectively ([KNUT81] p. 442). Thus both
  6604. encryption and decryption can be done in O(log n) operations, i.e.,
  6605. linear time. Nonetheless, these operations are relatively time-
  6606. consuming (though elementary), since they involve multiplications
  6607. and divisions of numbers of about 100 digits. For efficiency this
  6608. requires hardware support.
  6609.  
  6610.  
  6611.    Appendix N. Quadratic residuosity modulo a composite.
  6612.  
  6613.  
  6614.    Deciding quadratic residuosity modulo a composite played a major
  6615. role in appendices O and P. In particular, suppose N = p * q where
  6616. p and q are large primes. Deciding quadratic residuosity modulo
  6617. such N when p and q are unknown is regarded as computationally
  6618. intractable. This forms the basis of many probabilistic encryption
  6619. and zero-knowledge schemes.
  6620.  
  6621.    Also, it was noted by Rabin that finding square roots modulo N
  6622. in this event has essentially the same complexity as factoring N,
  6623. the intractability of which forms the basis for RSA. This was
  6624. exploited by Rabin (cf. sec. 4.1.4) to obtain a modification of RSA
  6625. which is provably equivalent to factoring. Essentially his scheme
  6626. was to encrypt via 
  6627.  
  6628.  
  6629.       EN(x) = x2 mod N. 
  6630.  
  6631.  
  6632.    Let ZN* be as in appendix G. 
  6633.  
  6634.   
  6635.    N.1 Characterizing quadratic residues.
  6636.  
  6637.  
  6638.    The basic extension of quadratic residuosity modulo a prime to
  6639. the composite modulus case is:
  6640.  
  6641.  
  6642.    LEMMA N.1.1. If N = p * q, p and q primes > 2, then:
  6643.  
  6644.  
  6645.       a. Suppose z ε ZN*. Then z is a quadratic residue modulo    
  6646.          N iff z mod p is a quadratic residue modulo p and z mod 
  6647.           q is a quadratic residue modulo q.
  6648.  
  6649.       b. A quadratic residue z modulo N has exactly four square  
  6650.           roots of the form {x,N-x,y,N-y} in ZN*.
  6651.  
  6652.       c. If z is a quadratic residue modulo N, and p and q are   
  6653.           known, then the square roots of z modulo N can be found 
  6654.           in probabilistic polynomial time.
  6655.  
  6656.  
  6657.    Proof: suppose z ε ZN*, z mod p is a quadratic residue modulo p,
  6658. and z mod q is a quadratic residue modulo q. Then for some r and
  6659. t in Zp* and Zq*, respectively, we have r2 ≡ z (mod p) and t2 ≡ z
  6660. (mod q). By the Chinese Remainder Theorem (app. I) there exists w
  6661. in ZN with w ≡ r (mod p) and w ≡ t (mod q). Then w2 ≡ z (mod p or
  6662. q), so w2 ≡ z (mod N). Thus z is a quadratic residue modulo N. This
  6663. proves one direction of (a).
  6664.  
  6665.    Now suppose z is a quadratic residue modulo N. Let zp = z mod p
  6666. and zq = z mod q. Then z ε ZN*, and hence zp ε Zp* and zq ε Zq*. Also,
  6667. w2 ≡ z (mod N) for some w in ZN*. Thus w2 ≡ z (mod p or q) and hence
  6668. w2 ≡ zp (mod p) and w2 ≡ zq (mod q). Thus zp and zq are quadratic
  6669. residues modulo p and q, respectively, proving (a) in the other
  6670. direction. 
  6671.  
  6672.    Furthermore, by lemma J.3.1, zp has exactly two square roots
  6673. {x1,x2} in Zp*, and zq has exactly two square roots {y1,y2} in Zq*.
  6674. Hence w ≡ xi (mod p) and w ≡ yj (mod q) for some i and j. There are
  6675. four possible pairs (i = 1,2 and j = 1,2). The Chinese Remainder
  6676. Theorem shows that w is uniquely determined in ZN by a given i and
  6677. j; hence z has at most four square roots modulo N in ZN*.
  6678. Conversely, by the Chinese Remainder Theorem once again, w can be
  6679. found for each (i,j) pair. Thus z has exactly four square roots
  6680. modulo N in ZN*. Let x denote one root. Then N - x is another. If
  6681. y is a third, then N - y is the fourth. This proves (b). 
  6682.  
  6683.    By lemma J.3.1, {xi} and {yj} can be found in probabilistic
  6684. polynomial time; the corresponding w's can then be found in
  6685. polynomial time. This proves (c). QED.
  6686.  
  6687.  
  6688.    COROLLARY N.1.1. Suppose N = p * q, p and q primes > 2. Then:
  6689.  
  6690.  
  6691.       a. EN is a four-to-one function.
  6692.  
  6693.       b. If p and q are known and z is a quadratic residue modulo 
  6694.          N, the four values of x for which EN(x) = z can be found 
  6695.          in probabilistic polynomial time.
  6696.  
  6697.  
  6698.    Proof: immediate from the previous lemma. QED.
  6699.  
  6700.  
  6701.    N.2 The Jacobi symbol once more.
  6702.  
  6703.  
  6704.    Suppose N = p * q where p and q are primes > 2. Then for x in
  6705. ZN*, the Jacobi symbol (x/N) is given by
  6706.  
  6707.  
  6708.       (x/N) = (x/p)(x/q).
  6709.  
  6710.  
  6711.    If the Jacobi symbol (x/N) = -1, then (x/p) or (x/q) = -1. Hence
  6712. x mod p and x mod q are quadratic nonresidues modulo p and q,
  6713. respectively. By lemma N.1.1, x is a quadratic nonresidue modulo
  6714. N. Since (x/N) can be evaluated in O(log N) time, (x/N) = -1 is a
  6715. deterministic polynomial-time test for quadratic nonresiduosity of
  6716. x modulo N, N = p * q. The interesting case is (x/N) = 1, whence
  6717. no conclusion can be drawn regarding quadratic residuosity of x
  6718. modulo N. To study this further, ZN* may be partitioned into four
  6719. subclasses, according to the Jacobi symbols (x/p) and (x/q):
  6720.  
  6721.  
  6722.       (x/p)   (x/q)      class      (x/N)
  6723.  
  6724.         1       1        Q00(N)       1
  6725.  
  6726.        -1      -1        Q11(N)       1
  6727.  
  6728.         1      -1        Q01(N)      -1
  6729.  
  6730.        -1       1        Q10(N)      -1
  6731.  
  6732.  
  6733.    LEMMA N.2.1. Suppose N = p*q, p and q primes > 2. Then:       
  6734.  
  6735.  
  6736.  
  6737.       a. The {Qij(N)} partition ZN* into disjoint classes.
  6738.  
  6739.       b. Q00(N) is the set of quadratic residues modulo N; the    
  6740.          other Q's contain nonresidues.
  6741.  
  6742.       c. For i = 0 or 1 and j = 0 or 1, |Qij(N)| = (p-1)(q-1)/4.
  6743.  
  6744.  
  6745.    Proof: (a) is trivial, and (b) is immediate from lemma N.1.1.
  6746. For (c), let g and h be generators for Zp* and Zq*, respectively. For
  6747. w ε ZN*, suppose w ≡ gr (mod p) and w ≡ hs (mod q), where 0 ≤ r < p -
  6748. 1 and 0 ≤ s < q - 1. Then r and s are unique. Conversely, any such
  6749. pair (r,s) uniquely determines w, by the Chinese Remainder Theorem.
  6750. Let f(w) = (r,s). Then f is a bijection from ZN* to Zp x Zq. Also,
  6751. if f(w) = (r,s) then
  6752.  
  6753.  
  6754.       (w/p) = (gr/p) = (g/p)r,
  6755.  
  6756.       (w/q) = (hs/q) = (h/q)s.
  6757.  
  6758.  
  6759.    By lemma K.4, g and h are quadratic nonresidues modulo p and q,
  6760. respectively. Thus (w/p) = (-1)r and (w/q) = (-1)s. Let i = r mod
  6761. 2 and j = s mod 2. Then (w/p) = (-1)i and (w/q) = (-1)j. Hence w is
  6762. in Qij(N). For k = 0,1 let Zpk  and Zqk be the subsets of Zp* and Zq*,
  6763. respectively, which contain elements = k (mod 2). Then for i = 0,1
  6764. and j = 0,1, f is a bijection from Qij(N) to Zpi x Zqj. The latter
  6765. has cardinality (p-1)(q-1)/2; this gives (c). QED.
  6766.  
  6767.    Thus exactly half of the elements of ZN* have (x/N) = -1; these
  6768. are nonresidues modulo N. The other half have (x/N) = 1. Of the
  6769. latter, half (i.e., Q00(N)) are quadratic residues and half (i.e.,
  6770. Q11(N)) are nonresidues. The quadratic residuosity conjecture is
  6771. that determining which of the elements of ZN* with (x/N) = 1 are
  6772. quadratic residues modulo N is not solvable in probabilistic
  6773. polynomial time, for N a product of two primes. This is in
  6774. contradistinction to the case of one prime p, for which we have
  6775. noted that quadratic residuosity is decidable in deterministic
  6776. polynomial time.
  6777.  
  6778.  
  6779.    LEMMA N.2.2. Suppose N = p * q, p and q primes > 2. Then:
  6780.  
  6781.  
  6782.       a. For x,y ε ZN*, x * y is a quadratic residue modulo N if and 
  6783.          only if x and y are in the same Qij(N).
  6784.  
  6785.       b. The product of quadratic residues is a quadratic residue.
  6786.  
  6787.       c. The product of a quadratic residue and a nonresidue is a 
  6788.          nonresidue.
  6789.  
  6790.  
  6791.    Proof: suppose x ε Qij(N) and y ε Qrt(N). Then (x/p) = 
  6792. (-1)i, (x/q) = (-1)j, (y/p) = (-1)r, (y/q) = (-1)t. Hence (x*y/p) =
  6793. (-1)i+r and (x*y/q) = (-1)j+t. Now x * y mod N will be a residue if
  6794. and only if i = r and j = t. This gives (a). In particular, x * y
  6795. mod N is a residue if both are in Q00(N), yielding (b). If x is a
  6796. residue and y a nonresidue, x is in Q00(N) but y is not; (c)
  6797. follows. QED.
  6798.  
  6799.  
  6800.    Thus the quadratic residues modulo N form a subgroup of ZN*.
  6801.  
  6802.  
  6803.    N.3 Quadratic residuosity and factoring.
  6804.  
  6805.  
  6806.    We note the connection between quadratic residuosity and
  6807. factoring observed by Rabin [RABI79].
  6808.  
  6809.  
  6810.    LEMMA N.3.1. Suppose N = p * q, p and q prime, x and y are in
  6811. ZN*, x2 ≡ y2 (mod N), and y !≡ x or -x (mod N). Then possession of
  6812. x and y permits factoring N in deterministic polynomial time.
  6813.  
  6814.  
  6815.    Proof: we have x - y !≡ 0 (mod N) and x + y !≡ 0 (mod N), so
  6816. GCD(N,y+x) < N and GCD(N,y-x) < N. Now x2 - y2 ≡ (x-y)(x+y) ≡ 0 (mod
  6817. N). Hence (x-y)(x+y) ≡ 0 (mod p). Thus p | y-x or p | y+x; also p
  6818. | N. If p | y-x, p | GCD(N,y-x) < N, so p = GCD(N,y-x). The latter
  6819. can be found via Euclid's algorithm (app. H). If p | y+x, p |
  6820. GCD(N,y+x) < N, so p = GCD(N,y+x). QED.
  6821.  
  6822.  
  6823.    LEMMA N.3.2. Suppose N = p * q, p and q prime. Suppose there
  6824. exists an algorithm to find in probabilistic polynomial time a
  6825. square root of a quadratic residue modulo N, which works for at
  6826. least a fraction 1/logc N of quadratic residues, c a constant
  6827. positive integer. Then N can be factored in probabilistic
  6828. polynomial time.
  6829.  
  6830.  
  6831.    Proof: let m = logc N. Choose x1,...,xm randomly in ZN* and
  6832. compute zi = xi2 mod N, i = 1,...,m. If any zi has a square root w
  6833. computable in probabilistic polynomial time via the hypothetical
  6834. algorithm, find w. The probability that w !≡ xi or -xi (mod N) is
  6835. 1/2. In this event possession of xi and w factors N by lemma N.3.1.
  6836. The probability that some zi has a computable square root is at
  6837. least 1/2. Thus the probability of factoring N is at least 1/4. If
  6838. this procedure is repeated m times, the probability of success is
  6839. at least 1 - (3/4)m. Also, the problem size is log N, so m is a
  6840. polynomial in the problem size. QED.
  6841.  
  6842.  
  6843.    COROLLARY N.3.2. If N = p * q, p and q prime, and the
  6844. factorization of N is computationally intractable, then the Blum
  6845. encryption function EN above is a trapdoor one-way function, with
  6846. (p,q) forming the trapdoor.
  6847.  
  6848.  
  6849.    Proof: by the previous theorem, an algorithm to invert EN would
  6850. yield an algorithm to factor N. QED.
  6851.  
  6852.  
  6853.    N.4 Quadratic residuosity and Blum integers.
  6854.  
  6855.  
  6856.    Suppose N = p * q where p ≡ 3 (mod 4) and q ≡ 3 (mod 4). Then
  6857. N is called a Blum integer (normally p and q are specified to have
  6858. roughly the same size). For example, N = 77 is used in appendix O.
  6859.  
  6860.  
  6861.    LEMMA N.4.1. If p,q ≡ 3 (mod 4) then (-1/p) = (-1/q) = -1.
  6862.  
  6863.  
  6864.    Proof: in lemma J.4.1 take a = -1. We recall that (-1/p) = 1 if
  6865. and only if -1 is a quadratic residue modulo p. Thus (-1/p) = (-
  6866. 1)(p-1)/2 (mod p) and similarly (-1/q) = (-1)(q-1)/2 (mod q). The result
  6867. follows. QED.
  6868.  
  6869.  
  6870.    LEMMA N.4.2. If N = p * q is a Blum integer then (-x/p) = -
  6871. (x/p), (-x/q) = -(x/q), (-1/N) = 1, and (-x/N) = (x/N).
  6872.  
  6873.  
  6874.    Proof: the first two are immediate from the previous lemma; also
  6875. (-1/N) = (-1/p)(-1/q). QED.
  6876.  
  6877.  
  6878.    LEMMA N.4.3. Suppose N = p * q is a Blum integer, x and y are
  6879. in ZN*, x2 ≡ y2 (mod N), and x !≡ y or -y (mod N). Then (x/N) = -
  6880. (y/N).
  6881.  
  6882.  
  6883.    Proof: x2 ≡ y2 (mod p), so (y-x)(y+x) ≡ 0 (mod p), so y ≡ d * x
  6884. (mod p) where d = 1 or -1. Similarly y ≡ e * x (mod q) where e =
  6885. 1 or -1. Now (x/N) = (x/p)(x/q) and (y/N) = (y/p)(y/q) =
  6886. (d*x/p)(e*x/q) = (d/p)(e/q)(x/N). Since (1/p) = (1/q) = 1, by lemma
  6887. N.4.1, (y/N) = e * d * (x/N). If e = d then y ≡ d * x (mod q or p),
  6888. so y ≡ d * x (mod N). But y !≡ x or -x (mod N), contradiction. Thus
  6889. e ■ d and e * d = -1. QED.
  6890.  
  6891.  
  6892.    LEMMA N.4.4. If N = p * q is a Blum integer and z is a quadratic
  6893. residue modulo N, then z has a square root in each Qij(N), i = 0,1,
  6894. j = 0,1. 
  6895.  
  6896.  
  6897.    Proof: let {x,N-x,y,N-y} be the square roots of z in ZN*. Since
  6898. N-x ≡ -x (mod p), by lemma N.4.2, (N-x/p) = -(x/p). Similarly (N-
  6899. x/q) = -(x/q), so if x ε Qij(N), N-x ε Q1-i,1-j(N); similarly for y and
  6900. N-y. Now x2 ≡ y2 (mod N) and y !≡ x or -x (mod N). Since by lemma
  6901. N.4.3, (y/N) = -(x/N), y cannot be in the same Q as x. By lemma
  6902. N.4.2, ((N-y)/N) = (y/N), so N-y cannot be in the same Q as x. Thus
  6903. y and N-y must be in Qi,1-j(N) and Q1-i,j(N) in some order. QED.
  6904.  
  6905.    For Blum integers we can restrict the function EN to Q00(N);
  6906. i.e., let BN : Q00(N) -> Q00(N) by BN(x) = x2 mod N. Then we have
  6907.  
  6908.    LEMMA N.4.5. If N = p * q is a Blum integer then:
  6909.  
  6910.  
  6911.       a. BN is a permutation on Q00(N), i.e., on the set of        
  6912.          quadratic residues modulo N.
  6913.  
  6914.       b. If the factorization of N is computationally intractable 
  6915.          then BN is a trapdoor one-way permutation, with (p,q)    
  6916.          constituting the trapdoor.
  6917.  
  6918.  
  6919.    Proof: by corollary N.1.1 we know that if p and q are known and
  6920. y is in Q00(N), the equation EN(x) = y has exactly four solutions
  6921. which can be found in probabilistic polynomial time. By lemma
  6922. N.4.4, exactly one of these, x00, lies in Q00(N); x00 is easily
  6923. extracted from the set of four since only it satisfies (x/p) =
  6924. (x/q) = 1. Hence x00 is the unique solution of BN(x) = y. Thus BN is
  6925. a permutation on Q00(N) whose inverse may be computed in
  6926. probabilistic polynomial time with knowledge of the trapdoor (p,q).
  6927. On the other hand, lemma N.3.2 shows that an algorithm to invert
  6928. BN can be converted to an algorithm to factor N. QED.
  6929.  
  6930.  
  6931.    LEMMA N.4.6. If N = p * q, p and q prime, then it is possible
  6932. to find x in Q11(N), i.e., x ε ZN* such that x is a quadratic
  6933. nonresidue modulo N and (x/N) = 1, in probabilistic polynomial
  6934. time.
  6935.  
  6936.  
  6937.    Proof: choose a in Zp* and evaluate a(p-1)/2; if the latter is not
  6938. 1 then choose a new a, etc. The probability of failure each time
  6939. is 1/2, so that the probability of not finding an a with a(p-1)/2 =
  6940. 1 (mod p) in n tries is 2-n. Hence a can be found in probabilistic
  6941. polynomial time (in n = length of p). Now (a/p) = 1. Similarly,
  6942. find b with (b/q) = 1, also in probabilistic polynomial time. Use
  6943. the Chinese Remainder Theorem to find y in ZN* with y ≡ a (mod p)
  6944. and y ≡ b (mod q), in polynomial time (in length of N). QED.
  6945.  
  6946.  
  6947.    Appendix O. An introduction to zero-knowledge.
  6948.  
  6949.  
  6950.    The notion of zero-knowledge proofs was introduced in [GOLD89].
  6951. The essence of zero-knowledge is that one party can prove something
  6952. to another without revealing any additional information. In
  6953. deference to the depth and scope of this area, we give only an
  6954. illustrative example in this section. However, there is a close
  6955. connection between zero-knowledge schemes and probabilistic public-
  6956. key encryption. Furthermore, some zero-knowledge schemes which have
  6957. drawn attention because of applicability to smart card
  6958. implementations, such as the one used as the basis of the example
  6959. in this section, use Shamir's notion of identity-based public-key
  6960. systems. Thus the reader desiring a more formal introduction to
  6961. these topics may wish to skip to appendix P.
  6962.  
  6963.    Suppose that Alice knows a fact P. She wants to convince Bob
  6964. that she knows P, but she does not trust Bob. Thus, Alice does not
  6965. want to reveal any more knowledge to Bob than is necessary. What
  6966. Alice needs is a zero-knowledge proof of P.
  6967.  
  6968.    For example, suppose that Alice wants to prove to Bob that she
  6969. really is Alice. Suppose for convenience that there is some
  6970. authority which verifies identities. One possibility is that the
  6971. authority could issue Alice an identification. If this were
  6972. contained on a device such as a smart card, Alice could simply show
  6973. it to Bob. However, if Alice and Bob are communicating over a
  6974. network, then Alice's identifying information would have to be
  6975. transmitted to Bob over the network. Upon receiving it, Bob could
  6976. use it to impersonate Alice. Even if Bob were trusted, an
  6977. eavesdropper such as Alice's adversary Carol could do the same.
  6978.  
  6979.    This situation also arises commonly in computer access control:
  6980. Bob might then be a host computer or network server, and Alice's
  6981. identification might be a password. If Alice uses her password to
  6982. identify herself, her password is exposed to the host software as
  6983. well as eavesdroppers; anyone who knows this password can
  6984. impersonate Alice.
  6985.  
  6986.    It is thus desirable for Alice to be able to prove her identity
  6987. without revealing any private information. More generally, we need
  6988. a scheme through which Alice can prove to Bob that she possesses
  6989. something (e.g., a password) without having to reveal it. Such a
  6990. scheme is an example of a zero-knowledge proof. In fact, this
  6991. example is the major practical usage of zero-knowledge which has
  6992. been suggested to date.
  6993.  
  6994.    Here is one way that such a system could be organized: the
  6995. authority decides on a number N used for everyone; e.g., take N =
  6996. 77. Everyone knows this number. The authority may then choose,
  6997. e.g., two numbers which form an ID for Alice. Suppose these are
  6998. {58,67}. Everyone knows Alice's ID. The authority then computes two
  6999. other numbers {9,10} which are given to Alice alone; she keeps
  7000. these private. The latter numbers were chosen because 92 * 58 ≡ 1
  7001. (mod 77) and 102 * 67 ≡ 1 (mod 77).  
  7002.  
  7003.    Now Alice can identify herself to Bob by proving that she
  7004. possesses the secret numbers {9,10} without revealing them. Each
  7005. time she wishes to do this she can proceed as follows: she can
  7006. choose some random numbers such as {19,24,51} and compute
  7007.  
  7008.  
  7009.       192 ≡ 53  (mod 77),
  7010.  
  7011.       242 ≡ 37  (mod 77),
  7012.  
  7013.       512 ≡ 60  (mod 77).
  7014.  
  7015.  
  7016.    Alice then sends {53,37,60} to Bob. Bob chooses a random 3 by
  7017. 2 matrix of 0's and 1's, e.g.,
  7018.  
  7019.  
  7020.                 0  1
  7021.       E    =    1  0 .
  7022.                 1  1
  7023.  
  7024.  
  7025.    Bob sends E to Alice. On receipt, Alice computes
  7026.  
  7027.  
  7028.       19 * 90 * 101 ≡ 36  (mod 77),
  7029.  
  7030.       24 * 91 * 100 ≡ 62  (mod 77),
  7031.  
  7032.       51 * 91 * 101 ≡ 47  (mod 77).
  7033.  
  7034.  
  7035.    Alice sends {36,62,47} to Bob. Finally, Bob can check to see
  7036. that Alice is who she says she is. He does this by checking that
  7037.  
  7038.  
  7039.       362 * 580 * 671 ≡ 53 (mod 77),
  7040.  
  7041.       622 * 581 * 670 ≡ 37 (mod 77),
  7042.  
  7043.       472 * 581 * 671 ≡ 60 (mod 77).
  7044.  
  7045.  
  7046.    The original numbers {53,37,60} that Alice sent reappear.
  7047. Actually, this doesn't really prove Alice's identity; she could
  7048. have been an impersonator. But the chances of an impersonator
  7049. succeeding would have only been 1 in 64.
  7050.  
  7051.    In an actual system, the number N would have been much larger
  7052. (e.g., 160 digits). Also, Alice would have been assigned an ID
  7053. consisting of more numbers, e.g., 4, by the authority, with a
  7054. secret also consisting of 4 numbers. Furthermore, Alice would have
  7055. generated more random numbers, e.g., 5, to send to Bob. The ID
  7056. numbers, secret numbers, and random numbers would have been about
  7057. as large as N. This would have reduced an impersonator's chances
  7058. of cheating successfully to about 1 in a million (more precisely
  7059. 2-20) if 4 and 5 are the parameters, which certainly would have
  7060. convinced Bob of Alice's identity.
  7061.  
  7062.    Why does this work? Because the authority chose {58,67} and
  7063. {9,10} so that
  7064.  
  7065.  
  7066.       92  * 58 ≡ 1  (mod 77),
  7067.  
  7068.       102 * 67 ≡ 1  (mod 77).
  7069.  
  7070.  
  7071.    This says that 92 and 58 are multiplicative inverses modulo 77,
  7072. as are 102 and 67. 
  7073.  
  7074.    Thus
  7075.  
  7076.  
  7077.       362 * 580 * 671 ≡ 192 * 92*0 * 580 * 102*1 * 671
  7078.  
  7079.                       ≡ 192 * (92 * 58)0 * (102 * 67)1 
  7080.  
  7081.                       ≡ 192 ≡ 36  (mod 77),
  7082.  
  7083.       622 * 581 * 670 ≡ 242 * 92*1 * 581 * 102*0 * 670 
  7084.  
  7085.                       ≡ 242 * (92 * 58)1 * (102 * 67)0 
  7086.  
  7087.                       ≡ 242 ≡ 37  (mod 77),
  7088.  
  7089.       472 * 581 * 671 ≡ 512 * 92*1 * 581 * 102*1 * 671
  7090.  
  7091.                       ≡ 512 * (92 * 58)1 * (102 * 67)1
  7092.  
  7093.                       ≡ 472 ≡ 53  (mod 77).
  7094.  
  7095.  
  7096.    Thus the checks that Bob uses serve their purpose properly;
  7097. i.e., Alice is identified. Also, Bob has learned nothing that would
  7098. permit him to masquerade as Alice; nor has Carol, who may have been
  7099. eavesdropping. Either would need to know that 92 and 102 are the
  7100. multiplicative inverses of 58 and 67, respectively, modulo 77. To
  7101. see this, suppose Carol tries to convince Bob that she is really
  7102. Alice; i.e., Carol pretends that {58,67} is her own ID. For
  7103. simplicity, suppose Carol tries to identify herself as Alice by
  7104. generating the same random {19,24,51}. Then she sends {53,37,60}
  7105. to Bob. Again for simplicity suppose Bob generates the same E and
  7106. sends it to Carol. Now Carol is in trouble; she doesn't know the
  7107. numbers 9 and 10, and can only guess them. The protocol requires
  7108. Carol to send three numbers, say {x,y,z}, to Bob. Then Bob will
  7109. check:
  7110.  
  7111.  
  7112.       x2 * 580 * 671 ≡ 53  (mod 77),
  7113.  
  7114.       y2 * 581 * 670 ≡ 37  (mod 77),
  7115.  
  7116.       z2 * 581 * 671 ≡ 60  (mod 77).
  7117.  
  7118.  
  7119.    Carol will have succeeded in her masquerade if she chose {x,y,z}
  7120. to make these checks come out right. But 67-1 ≡ 102 ≡ 23 (mod 77)
  7121. and 58-1 ≡ 92 ≡ 4 (mod 77), so x2 ≡ 53 * 23 ≡ 64 (mod 77), y2 ≡ 37
  7122. * 4 ≡ 71 (mod 77) and z2 ≡ 60 * 23 * 4 ≡ 53 (mod 77). Could Carol
  7123. solve these quadratic equations to find, e.g., x = 36, y = 62, z
  7124. = 47? For a small value of N such as N = 77, she could indeed.
  7125. However, if N is a product of two appropriately-chosen large primes
  7126. (e.g., each 80 digits or more), and if these primes are kept secret
  7127. by the authority, then the answer is no. That is, computing square
  7128. roots modulo a composite is computationally infeasible (app. N).
  7129. Thus, anyone who does not know Alice's secret ({9,10} in the above)
  7130. cannot impersonate her when N is large. 
  7131.  
  7132.    Another possibility is that Alice's interaction with Bob might
  7133. give Bob information which could allow impersonation of Alice, at
  7134. least on one occasion, by replay. Suppose Bob tries to convince
  7135. Carol that he is really Alice. Bob might try to imitate Alice by
  7136. sending (53,37,60} to Carol to start the protocol. Now Carol
  7137. doesn't necessarily select the E above. Suppose she selects
  7138.  
  7139.  
  7140.                1  1
  7141.       F   =    0  0 .
  7142.                0  1
  7143.  
  7144.  
  7145. and sends F to Bob. Now Bob is in trouble; he might try to imitate
  7146. Alice again by sending {36,62,47} to Carol. Then Carol will check
  7147.  
  7148.  
  7149.       362 * 581 * 671  ≡ 71  (mod 77).
  7150.  
  7151.  
  7152.    Since 71 ■ 53 (mod 77), Carol knows Bob is a fraud even without
  7153. the other two checks. Can Bob send some {r,s,t} instead of
  7154. {36,62,47} ? This will only work if
  7155.  
  7156.  
  7157.  
  7158.       r2 * 581 * 671 ≡ 53  (mod 77),
  7159.  
  7160.       s2 * 580 * 670 ≡ 37  (mod 77),
  7161.  
  7162.       t2 * 580 * 671 ≡ 60  (mod 77).
  7163.  
  7164.  
  7165.    As before, this gives r2 ≡ 58-1 * 67-1 * 53 ≡ 25 (mod 77), and
  7166. similarly s2 ≡ 37 (mod 77), t2 ≡ 71 (mod 77). As above, Bob can
  7167. solve these quadratic equations to find r,s,t because N = 77 is
  7168. small, but could not do so if N were large. Also, in the above
  7169. there is one chance in 64 that Carol would choose F = E, in which
  7170. case Bob's deception would go unmasked; but for larger parameters
  7171. such as 4 and 5 instead of 2 and 3, this would again be improbable
  7172. (one chance in a million (2-20) instead of 64).
  7173.  
  7174.    Another possibility is that when Alice identified himself to
  7175. Bob, she may have inadvertently revealed some information which
  7176. could enable Bob to learn his secret, i.e., {9,10}, which would
  7177. permit impersonation. For this protocol to be zero-knowledge this
  7178. should not be possible. Can Bob deduce the numbers {9,10} from the
  7179. two sets of numbers {53,37,60} and {36,62,47}, and E? He knows that
  7180. Alice started with three numbers {a,b,c}, but he doesn't know these
  7181. were {19,24,51}. He knows that Alice's secret is {u,v} but doesn't
  7182. know these are {9,10}. He knows that the authority computed u and
  7183. v from
  7184.  
  7185.  
  7186.       u2 ≡ 58-1 ≡ 4   (mod 77),
  7187.  
  7188.       v2 ≡ 67-1 ≡ 23  (mod 77).
  7189.  
  7190.  
  7191.    He also knows that Alice computed 
  7192.  
  7193.  
  7194.       a2 ≡ 53  (mod 77),
  7195.  
  7196.       b2 ≡ 37  (mod 77),
  7197.  
  7198.       c2 ≡ 60  (mod 77),
  7199.  
  7200.       a * u0 * v1 ≡ 36  (mod 77),
  7201.  
  7202.       b * u1 * v0 ≡ 62  (mod 77),
  7203.  
  7204.       c * u1 * v1 ≡ 47  (mod 77).
  7205.  
  7206.  
  7207.    This gives Bob 8 equations from which to deduce {u,v}. However,
  7208. the last 3 are redundant, and as we have noted, the first 5 cannot
  7209. be solved when N is large.
  7210.  
  7211.    This shows informally that the above protocol works:
  7212.  
  7213.  
  7214.       a. It identifies Alice by proving that she possesses the   
  7215.           secret {9,10}. 
  7216.  
  7217.       b. It identifies Alice uniquely: anyone who doesn't know   
  7218.           this secret cannot impersonate Alice.
  7219.  
  7220.       c. Alice's secret is not revealed in the process of        
  7221.           proving she possesses it.
  7222.  
  7223.  
  7224.    Actually, (a) means that the possessor of {9,10} is identified
  7225. as the system user who has ID = {58,67} assigned by the authority.
  7226. Also, no matter how many times Alice proves her identity, her
  7227. secret will not be revealed (if N is sufficiently large); i.e., (c)
  7228. states loosely that the protocol is zero-knowledge. All of this
  7229. depends on the assumption that equations of the form x2 ≡ y (mod N)
  7230. cannot be solved if N is the product of two large primes which are
  7231. not known, but can be solved easily if the primes are known (app.
  7232. N). Such equations lie at the heart of most concrete zero-knowledge
  7233. schemes.
  7234.  
  7235.    The formal definition of zero-knowledge is more complicated (see
  7236. [GOLD89]), but the above example demonstrates its essence in a
  7237. context which has been proposed as a candidate for actual
  7238. implementation in smart-card based identification schemes.
  7239.  
  7240.  
  7241.    Appendix P. Alternatives to the Diffie/Hellman model.
  7242.  
  7243.  
  7244.    The text of this treatise has been based on the work of Diffie
  7245. and Hellman [DIFF76b]. This model of public-key cryptography
  7246. includes two characteristics which have received some criticism:
  7247.  
  7248.  
  7249.        a. Security of Diffie/Hellman type systems is generally   
  7250.            established empirically, i.e., by failure of          
  7251.             cryptanalysis.
  7252.  
  7253.        b. Security of Diffie/Hellman type systems is dependent upon 
  7254.           a superstructure which binds user IDs and public       
  7255.            components.
  7256.  
  7257.  
  7258.    In appendix A we noted that it has proven to be difficult to
  7259. develop a comprehensive axiomatic framework in which to establish
  7260. the security of Diffie/Hellman type public-key systems in some
  7261. provable sense. For example, it is difficult to guarantee that
  7262. partial information about plaintext (e.g., its least significant
  7263. bit) cannot be recovered from the corresponding ciphertext even
  7264. when the entire plaintext cannot be found.
  7265.  
  7266.    In section 5 we noted some examples of authentication frameworks
  7267. (e.g., use of certificates) which bind user IDs and public keys.
  7268. Without such a superstructure a public-key system is useless, since
  7269. a user would not be certain that he was employing the correct
  7270. public key for encryption or decryption. The security of the
  7271. public-key system thus depends on proper functioning of the
  7272. authentication framework, which is a priori unrelated to the
  7273. underlying cryptosystem.
  7274.  
  7275.    In this section we briefly examine two modifications of the
  7276. basic Diffie/Hellman model. In one case the goal is to incorporate
  7277. the binding between a user ID and public key directly into the
  7278. cryptosystem, thereby eliminating the separation between the
  7279. cryptosystem and the authentication framework. The other scheme
  7280. addresses the subject of knowledge concealment; it is closely
  7281. related to zero-knowledge proofs. Both schemes have received
  7282. considerable attention not only because of possibly enhanced
  7283. security, but also because of their potential relevance to smart-
  7284. card implementations of public-key cryptography.
  7285.  
  7286.  
  7287.    P.1 Probabilistic encryption.
  7288.  
  7289.  
  7290.    Goldwasser and Micali [GOLD84] note that the public-key systems
  7291. of Diffie and Hellman are not provably secure. They observe that
  7292. use of a trapdoor function f to generate such systems does not
  7293. exclude the possibility that f(x) = y may be solvable for x without
  7294. the (original) trapdoor under certain conditions. Also, even if x
  7295. cannot be found from f(x), it may be possible to extract partial
  7296. information about x. One problem is that such trapdoor systems
  7297. proceed block by block. This makes it difficult to prove security
  7298. with respect to concealment of partial information such as least
  7299. significant bit.
  7300.  
  7301.    In [GOLD84] Goldwasser and Micali suggest an alternative to
  7302. trapdoor-based public-key systems. Their procedure is to encrypt
  7303. bit by bit. They call this probabilistic encryption. It introduces
  7304. several advantages, namely uniformly difficult decoding and hiding
  7305. of partial information. Their scheme has the following properties:
  7306.  
  7307.  
  7308.       a. Decoding is equivalent to deciding quadratic residuosity 
  7309.          modulo a composite N, whose factorization is not known to 
  7310.          an adversary.
  7311.  
  7312.       b. Suppose a predicate P has probability p of being true in 
  7313.          message space M. For c > 0, assuming intractability of  
  7314.           quadratic residuosity, an adversary given ciphertext   
  7315.            cannot decide with probability > p + c whether the    
  7316.             corresponding plaintext satisfies P; i.e., the
  7317. adversary           does not have a c-advantage in guessing P.
  7318.  
  7319.  
  7320.    In (a) the reference is to the problem of deciding for a given
  7321. x whether there is a y such that y2 ≡ x (mod N). As in the case of
  7322. computing discrete logarithms or extracting roots, this is
  7323. computationally infeasible if the factorization of N is unknown
  7324. (app. N).
  7325.  
  7326.    An example of (b): if the messages consist of uniformly
  7327. distributed bit strings and P is "least significant bit = 0," then
  7328. p = 1/2. If the Goldwasser/Micali scheme is employed, an adversary
  7329. cannot guess the least significant bit of plaintext with
  7330. probability greater than 1/2 + c. It may be very difficult to
  7331. verify that traditional public-key systems conceal such partial
  7332. information.
  7333.  
  7334.    The public-key system proposed by Goldwasser and Micali is as
  7335. follows: a user A chooses primes p and q and makes public N = p*q;
  7336. p and q are private. Also, A selects a random y with (y/N) = 1
  7337. (app. N.2) with y a quadratic nonresidue modulo N; y is public. By
  7338. lemma N.4.6, y can be found in probabilistic polynomial time.
  7339.  
  7340.    To send the binary string m = (m1,...,mk) to A, B randomly
  7341. selects {x1,...,xk} in ZN* and computes 
  7342.  
  7343.  
  7344.       zi = xi2 mod N    (i = 1,...,k).
  7345.  
  7346.  
  7347.    Then B sets ei = zi if mi = 0, ei = y * zi otherwise. The encoding
  7348. of m is e = (e1,...,ek), which B sends to A. To decode e, A sets mi
  7349. = 1 if ei is a quadratic residue modulo N, and mi = 0 otherwise.
  7350. This can be effected by A in polynomial time since A knows p and
  7351. q (lemmas J.4.1, N.1.1). It is correct because y * zi, the product
  7352. of a quadratic nonresidue and residue, is a quadratic nonresidue
  7353. modulo N (lemma N.2.2). 
  7354.  
  7355.    The security of partial information follows from the fact that
  7356. each bit of the message m is encoded independently. A disadvantage
  7357. of the technique is data expansion: if |N| = n, then n bits are
  7358. transmitted for each bit of a message.
  7359.  
  7360.    One application is coin flipping by telephone: A randomly
  7361. chooses r in ZN* with (r/N) = 1, where (r/N) is the Jacobi symbol
  7362. (app. N.2). Then B guesses whether or not r is a quadratic residue
  7363. modulo N; B wins if and only if he guesses correctly. The
  7364. probability of the latter is 1/2; i.e., exactly half of the
  7365. elements of ZN* satisfying (r/N) = 1 are quadratic residues modulo
  7366. N (lemma N.2.1). The correctness of B's guess can be checked by A;
  7367. the result can be verified by B if A releases the factorization of
  7368. N to B.
  7369.  
  7370.    A second application is to mental poker (e.g., [DENN83b] pp.
  7371. 110-117). Goldwasser and Micali show that their implementation
  7372. corrects some deficiencies in hiding partial information in a
  7373. scheme of Shamir, Rivest and Adleman.
  7374.  
  7375.    Quadratic residuosity modulo a composite is an example of a
  7376. trapdoor function. Yao [YAO-82] showed that under certain
  7377. conditions, trapdoor functions in general can be used to construct
  7378. provably secure probabilistic public-key cryptosystems. An
  7379. important role is also played by probabilistic encryption in zero-
  7380. knowledge proofs, especially for problems in NP.
  7381.  
  7382.    We remark briefly that the above scheme is only one of a class
  7383. of encryption schemes which Rivest and Sherman [RIVE82] term
  7384. randomized encryption techniques; various other schemes are
  7385. summarized there. We have characterized schemes such as the above
  7386. as bit-by-bit; more generally, a randomized scheme is any scheme
  7387. in which a ciphertext for a given plaintext is randomly chosen from
  7388. a set of possible ciphertexts. Rivest and Sherman also develop a
  7389. classification for such schemes. A major aspect of randomized
  7390. schemes is often significant data expansion. For example, the
  7391. Goldwasser/Micali scheme would probably have ciphertext around 512
  7392. times as large as the plaintext. On the other hand, probabilistic
  7393. schemes may be much faster than their deterministic counterparts,
  7394. an attractive feature for smart-card implementations.
  7395.  
  7396.  
  7397.    P.2 Identity-based schemes.
  7398.  
  7399.  
  7400.    In [SHAM84], Shamir suggests yet another modification of
  7401. traditional public-key systems. In Shamir's framework a user's
  7402. public key coincides with his system ID. This eliminates the need
  7403. for any superstructure for distribution of public keys. It also
  7404. trivializes the authentication of public keys. However, unlike a
  7405. traditional public-key scheme this modification requires a trusted
  7406. key generation center. 
  7407.  
  7408.    The center issues a smart card to each user, containing the
  7409. user's private key. Thus the "private" key is really a shared
  7410. secret key. A card can generate the user's digital signature. The
  7411. center does not maintain a database of keys; in fact it need not
  7412. even keep information beyond a list of user IDs (needed to ensure
  7413. that there are no duplicate IDs).
  7414.  
  7415.    Security for such a system differs from the usual requirement
  7416. that a user keep his private key a secret. The latter condition is
  7417. retained, in that a user must guard his card. As in a certificate-
  7418. based traditional system, the center must ascertain a user's
  7419. identity before issuing a card. In addition, however, the
  7420. cryptographic function used by the center to generate private keys
  7421. from IDs must be kept secret. Typically this function would employ
  7422. trapdoor information such as the factorization of a modulus. The
  7423. requirement is that computing the private key from an ID is easy
  7424. if the trapdoor information is known, but knowing any polynomial
  7425. number of public/secret pairs should not reveal the trapdoor.
  7426.  
  7427.    A weakness in such a scheme is that anyone (intruder or insider)
  7428. possessing the trapdoor information can forge the signature of any
  7429. user. This is in contradistinction, e.g., to a credit-card scheme
  7430. in which a transaction is generally valid only if accompanied by
  7431. a user's physical signature. Also, the center is not required to
  7432. maintain any information on lost or stolen cards; thus the loss of
  7433. a card is disastrous since the possessor can forge the legitimate
  7434. user's signature indefinitely. Furthermore, the center may find
  7435. itself involved in litigation produced by any such security
  7436. problems, since it is providing the means by which users generate
  7437. signatures. Again this in contrast to the credit-card situation:
  7438. if a credit card is stolen, the thief cannot forge the legitimate
  7439. holder's physical signature, providing a means of distinguishing
  7440. between legal and illegal usage of the card. Use of passwords
  7441. (PINs) with cards could largely eliminate the problems accruing
  7442. from lost or stolen cards, but compromise of the trapdoor would
  7443. still be disastrous.
  7444.  
  7445.    Shamir's notion was later ([FEIG87],[FIAT86]) incorporated into
  7446. zero-knowledge schemes. One of these was used as the basis for the
  7447. example in appendix O.
  7448.  
  7449.  
  7450.                             REFERENCES                   
  7451.  
  7452.  
  7453. [ADLE79] L. Adleman, "A subexponential algorithm for the discrete
  7454. logarithm problem with applications to cryptography," in 20th
  7455. Annual Symposium on Foundations of Computer Science, San Juan,
  7456. Puerto Rico, October 29-31, 1979, pp. 55-60. Silver Spring, MD:
  7457. IEEE Computer Society Press, 1979.
  7458.  
  7459. [ADLE82] L. M. Adleman, "On breaking the iterated Merkle-Hellman
  7460. public-key cryptosystems," in D. Chaum, R. L. Rivest, and A. T.
  7461. Sherman, Eds., Advances in Cryptology: proceedings of CRYPTO 82,
  7462. a Workshop on the Theory and Application of Cryptographic
  7463. Techniques, Santa Barbara, CA, August 23-25, 1982, pp. 303-308. New
  7464. York: Plenum Press, 1983.
  7465.  
  7466. [ADLE86] L. M. Adleman and K. S. McCurley, "Open problems in number
  7467. theoretic complexity," in D. S. Johnson, T. Nishizeki, A. Nozaki,
  7468. and H. S. Wilf, Eds., Discrete Algorithms and Complexity,
  7469. proceedings of the Japan-US Joint Seminar, Kyoto, Japan, June 4-
  7470. 6, 1986, pp. 237-262. Orlando, FL: Academic Press, 1987.
  7471.  
  7472. [ADLE83] L. M. Adleman, C. Pomerance, and R. S. Rumely, "On
  7473. distinguishing prime numbers from composite numbers," Annals of
  7474. Mathematics, Vol. 117, 1983, pp. 173-206.
  7475.  
  7476. [AKL-83] S. G. Akl, "Digital signatures: a tutorial survey,"
  7477. Computer, Vol. 16, No. 2, February 1983, pp. 15-24.
  7478.  
  7479. [AKL-84] S. G. Akl and H. Meijer, "A fast pseudo random permutation
  7480. generator with applications to cryptology," in G. R. Blakley and
  7481. D. Chaum, Eds., Lecture Notes in Computer Science Vol. 196:
  7482. Advances in Cryptology: Proceedings of CRYPTO 84, a Workshop on the
  7483. Theory and Application of Cryptographic Techniques, Santa Barbara,
  7484. CA, August 19-22, 1984, pp. 269-275. Berlin/New York: Springer-
  7485. Verlag, 1985.
  7486.  
  7487. [ANSI85] American National Standard X9.17-1985, Financial
  7488. Institution Key Management (Wholesale), American Bankers
  7489. Association, Washington, DC, 1985.
  7490.  
  7491. [ANNA87] M. Annaratone, E. Arnould, T. Gross, H. T. Kung, M. Lam,
  7492. O. Menzilcioglu, and J. A. Webb, "The Warp computer: architecture,
  7493. implementation and performance," IEEE Transactions on Computers,
  7494. Vol. C-36, No. 12, December 1987, pp. 1523-1538.
  7495.  
  7496. [BANE82] S. K. Banerjee, "High speed implementation of DES,"
  7497. Computers & Security, Vol. 1, No. 3, November 1982, pp. 261-267. 
  7498.  
  7499. [BART63] T. C. Bartee and D. I. Schneider, "Computation with Finite
  7500. Fields," Information and Control, Vol. 6, 1963, pp. 79-98.
  7501.  
  7502. [BATC80] K. E. Batcher, "Design of a massively parallel processor,"
  7503. IEEE Transactions on Computers, Vol. C-29, No. 9, September 1980,
  7504. pp. 836-840.
  7505.  
  7506. [BLAK84] I. F. Blake, R. Fuji-Hara, R. C. Mullin, and S. A.
  7507. Vanstone, "Computing logarithms in finite fields of characteristic
  7508. two," SIAM Journal on Algebraic and Discrete Methods, Vol. 5, No.
  7509. 2, June 1984, pp. 276-285.
  7510.  
  7511. [BLAK84b] I. F. Blake, R. C. Mullin, and S. A. Vanstone, "Computing
  7512. logarithms in GF(2n)," in G. R. Blakley and D. Chaum, Eds., Lecture
  7513. Notes in Computer Science Vol. 196: Advances in Cryptology:
  7514. Proceedings of CRYPTO 84, a Workshop on the Theory and Application
  7515. of Cryptographic Techniques, Santa Barbara, CA, August 19-22, 1984,
  7516. pp. 73-82. Berlin/New York: Springer-Verlag, 1985.
  7517.  
  7518. [BLAK83] G. R. Blakley, "A computer algorithm for calculating the
  7519. product AB modulo M," IEEE Transactions on Computers, Vol. C-32,
  7520. No. 5, May 1983, pp. 497-500.
  7521.  
  7522. [BLUM84] M. Blum and S. Micali, "How to generate cryptographically
  7523. strong sequences of pseudo-random bits," SIAM  Journal on
  7524. Computing, Vol. 13, No. 4, November 1984, pp. 850-864.
  7525.  
  7526. [BOOT81] K. S. Booth, "Authentication of signatures using public
  7527. key encryption," Communications of the ACM, Vol. 24, No. 11,
  7528. November 1981, pp. 772-774.
  7529.  
  7530. [BRAN75] D. K. Branstad, "Encryption protection in computer data
  7531. communications," in Proceedings of the 4th Data Communications
  7532. Symposium, October 7-9, 1975, pp. 8.1 - 8.7. IEEE.
  7533.  
  7534. [BRAS79] G. Brassard, "A note on the complexity of cryptography,"
  7535. IEEE Transactions on Information Theory, Vol. IT-25, No. 2, March
  7536. 1979, pp. 232-233.
  7537.  
  7538. [BRAS83] G. Brassard, "Relativized cryptography," IEEE Transactions
  7539. on Information Theory, Vol. IT-29, No. 6, November 1983, pp. 877-
  7540. 894.
  7541.  
  7542. [BRAS88] G. Brassard, Lecture Notes in Computer Science Vol. 325:
  7543. Modern  Cryptology: a Tutorial. Berlin/New York: Springer-Verlag,
  7544. 1988. 
  7545.  
  7546. [BREN83] R. P. Brent and H. T. Kung, "Systolic VLSI arrays for
  7547. linear-time GCD computation," in F. Anceau and E. J. Aas, Eds.,
  7548. VLSI 83, proceedings of the IFIP TC 10/WG 10.5 International
  7549. Conference on VLSI, Trondheim, Norway, August 16-19, 1983, pp. 145-
  7550. 154. Amsterdam/New York: North-Holland, 1983.
  7551.  
  7552. [BREN83b] R. P. Brent, H. T. Kung, and F. T. Luk, "Some linear-
  7553. time algorithms for systolic arrays," in R. E. A. Mason, Ed., IFIP
  7554. Congress Series Vol. 9: Information Processing 83, proceedings of
  7555. the IFIP 9th World Congress, Paris, France, September 19-23, 1983,
  7556. pp. 865-876. Amsterdam/New York: North-Holland, 1983.
  7557.  
  7558. [BRIC82] E. F. Brickell, "A fast modular multiplication algorithm
  7559. with application to two key cryptography," in D. Chaum, R. L.
  7560. rivest, and A. T. Sherman, Eds., Advances in Cryptology:
  7561. proceedings of CRYPTO '82, a Workshop on the Theory and Application
  7562. of Cryptographic Techniques, Santa Barbara, CA, August 23-25, 1982,
  7563. pp. 51-60. New York: Plenum Press, 1983.
  7564.  
  7565. [BRIC83] E. F. Brickell, "Solving low density knapsacks," in D.
  7566. Chaum, Ed., Advances in Cryptology: proceedings of CRYPTO 83, a
  7567. Workshop on the Theory and Application of Cryptographic Techniques,
  7568. Santa Barbara, CA, August 22-24, 1983, pp. 25-37. New York: Plenum
  7569. Press, 1984.
  7570.  
  7571. [BRIC84] E. F. Brickell, "Breaking iterated knapsacks," in G. R.
  7572. Blakley and D. Chaum, Eds., Lecture Notes in Computer Science Vol.
  7573. 196: Advances in Cryptology: Proceedings of CRYPTO 84, a Workshop
  7574. on the Theory and Application of Cryptographic Techniques, Santa
  7575. Barbara, CA, August 19-22, 1984, pp. 342-358. Berlin/New York:
  7576. Springer-Verlag, 1985.
  7577.  
  7578. [BRIC89] E. F. Brickell, "A survey of hardware implementations of
  7579. RSA," in G. Brassard, Ed., Lecture Notes in Computer Science Vol.
  7580. 435: Advances in Cryptology - Proceedings of CRYPTO '89, pp. 368-
  7581. 370. Berlin/New York: Springer-Verlag, 1990.
  7582.  
  7583. [BRIC88] E. F. Brickell and A. M. Odlyzko, "Cryptanalysis: a survey
  7584. of recent results," Proceedings of the IEEE, Vol. 76, No. 5, May
  7585. 1988, pp. 578-593. 
  7586.  
  7587. [BRIG76] H. S. Bright and R. L. Enison, "Cryptography using modular
  7588. software elements," in S. Winkler, Ed., AFIPS Conference
  7589. Proceedings Vol. 45: National Computer Conference, New York, NY,
  7590. June 7-10, 1976, pp. 113-123. Montvale, NJ: AFIPS Press, 1976.
  7591.  
  7592. [CCIT87] CCITT, Draft Recommendation X.509: The Directory -
  7593. Authentication Framework. Gloucester, November 1987.
  7594.  
  7595. [CARO87] T. R. Caron and R. D. Silverman, "Parallel implementation
  7596. of the quadratic scheme," Journal of Supercomputing, Vol. 1, No.
  7597. 3, 1987.
  7598.  
  7599. [COHE87] H. Cohen and A. K. Lenstra, "Implementation of a new
  7600. primality test," Mathematics of Computation, Vol. 48, No. 177,
  7601. January 1987, pp. 103-121.
  7602.  
  7603. [COHE84] H. Cohen and H. W. Lenstra, Jr., "Primality testing and
  7604. Jacobi sums," Mathematics of Computation, Vol. 42, No. 165, January
  7605. 1984, pp. 297-330.
  7606.  
  7607. [CONT80] Control Data Corporation, CDC CYBER 200 Model 205 Computer
  7608. System. Minneapolis, MN, 1980.
  7609.  
  7610. [COPP84] D. Coppersmith, "Fast evaluation of logarithms in fields
  7611. of characteristic two," IEEE Transactions on Information Theory,
  7612. Vol. IT-30, No. 4, July 1984, pp. 587-594.
  7613.  
  7614. [COPP85] D. Coppersmith, "Another birthday attack," in H. C.
  7615. Williams, Ed., Lecture Notes in Computer Science Vol. 218: Advances
  7616. in Cryptology - CRYPTO '85, proceedings of a Conference on the
  7617. Theory and Applications of Cryptographic Techniques, Santa Barbara,
  7618. CA, August 18-22, 1985, pp. 14-17. Berlin/New York: Springer-
  7619. Verlag, 1986.
  7620.  
  7621. [COPP87] D. Coppersmith, "Cryptography," IBM Journal of Research
  7622. and Development, Vol. 31, No. 2, March 1987, pp. 244-248.
  7623.  
  7624. [COPP86] D. Coppersmith, A. M. Odlyzko, and R. Schroeppel,
  7625. "Discrete logarithms in GF(p)," Algorithmica, Vol. 1, No. 1, 1986,
  7626. pp. 1-15.
  7627.  
  7628. [CRAY80] Cray Research, Inc., Cray 1-S Series Hardware Reference
  7629. Manual. Mendota Heights, MN, June 1980.
  7630.  
  7631. [CRAY85] Cray Research, Inc., Cray X-MP Series of Computer Systems.
  7632. Mendota Heights, MN, August 1985.
  7633.  
  7634. [DAVI83] D. W. Davies, "Applying the RSA digital signature to
  7635. electronic mail," Computer, Vol. 16, No. 2, February 1983, pp. 55-
  7636. 62.
  7637.  
  7638. [DAVI80] D. W. Davies and W. L. Price, "The application of digital
  7639. signatures based on public key cryptosystems," NPL Report DNACS
  7640. 39/80, National Physics Laboratory, Teddington, Middlesex, England,
  7641. December 1980.
  7642.  
  7643. [DAVI83b] J. A. Davis and D. B. Holdridge, "Factorization using the
  7644. quadratic sieve algorithm," in D. Chaum, Ed., Advances in
  7645. Cryptology: proceedings of CRYPTO 83, a Workshop on the Theory and
  7646. Application of Cryptographic Techniques, Santa Barbara, CA, August
  7647. 22-24, 1983, pp. 103-113. New York: Plenum Press, 1984.
  7648.  
  7649. [DAVI84] J. A. Davis, D. B. Holdridge, and G. J. Simmons, "Status
  7650. report on factoring," in T. Beth, N. Cot, and I. Ingemarsson, Eds.,
  7651. Lecture Notes in Computer Science Vol. 209: Advances in Cryptology:
  7652. Proceedings of EUROCRYPT 84, a Workshop on the Theory and
  7653. Application of Cryptographic Techniques, Paris, France, April 9-
  7654. 11, 1984, pp. 183-215. Berlin/New York: Springer-Verlag, 1985.
  7655.  
  7656. [DEMI83] R. DeMillo and M. Merritt, "Protocols for data security,"
  7657. Computer, Vol. 16, No. 2, February 1983, pp. 39-51.
  7658.  
  7659. [DENN79] D. E. Denning, "Secure personal computing in an insecure
  7660. network," Communications of the ACM, Vol. 22, No. 8, August 1979,
  7661. pp. 476-482.
  7662.  
  7663. [DENN83b] D. E. Denning, "Protecting public keys and signature
  7664. keys," Computer, Vol. 16, No. 2, February 1983, pp. 27-35.
  7665.  
  7666. [DENN81] D. E. Denning and G. M. Sacco, "Timestamps in key
  7667. distribution protocols," Communications of the ACM, Vol. 24, No.
  7668. 8, August 1981, pp. 533-536.
  7669.  
  7670. [DENN83] D. E. R. Denning, Cryptography and Data Security. Reading,
  7671. MA: Addison-Wesley, 1983. 
  7672.  
  7673. [DESM83] Y. Desmedt, J. Vandewalle, and R. J. M. Govaerts, "A
  7674. critical analysis of the security of knapsack public key
  7675. algorithms," IEEE Transactions on Information Theory, Vol. IT-30,
  7676. No. 4, July 1984, pp. 601-611.
  7677.  
  7678. [DIFF82] W. Diffie, "Conventional versus public key cryptosystems,"
  7679. in G. J. Simmons, Ed., Secure Communications and Asymmetric
  7680. Cryptosystems, pp. 41-72. Boulder, CO: Westview Press, 1982.
  7681.  
  7682. [DIFF84] W. Diffie, "Network security problems and approaches,"
  7683. Proceedings of the National Electronics Conference, Vol. 38, 1984,
  7684. pp. 292-314.
  7685.  
  7686. [DIFF86] W. Diffie, "Communication security and national security
  7687. business, technology, and politics," Proceedings of the National
  7688. Communications Forum, Vol. 40, 1986, pp. 734-751. 
  7689.  
  7690. [DIFF88] W. Diffie, "The first ten years of public-key
  7691. cryptography," Proceedings of the IEEE, Vol. 76, No. 5, May 1988,
  7692. pp. 560-577. 
  7693.  
  7694. [DIFF76] W. Diffie and M. E. Hellman, "Multiuser cryptographic
  7695. techniques," in S. Winkler, Ed., AFIPS Conference Proceedings Vol.
  7696. 45: National Computer Conference, New York, NY, June 7-10, 1976,
  7697. pp. 109-112. Montvale, NJ: AFIPS Press, 1976. 
  7698.  
  7699. [DIFF76b] W. Diffie and M. E. Hellman, "New directions in
  7700. cryptography," IEEE Transactions on Information Theory, Vol. IT-22,
  7701. No. 6, November 1976, pp. 644-654. 
  7702.  
  7703. [DIFF79] W. Diffie and M. E. Hellman, "Privacy and authentication:
  7704. an introduction to cryptography," Proceedings of the IEEE, Vol. 67,
  7705. No. 3, March 1979, pp. 397-427. 
  7706.  
  7707. [DIFF87] W. Diffie, B. O'Higgins, L. Strawczynski, and D. Steer,
  7708. "An ISDN secure telephone unit," Proceedings of the National
  7709. Communications Forum, Vol. 41, No. 1, 1987, pp. 473-477. 
  7710.  
  7711. [DIXO81] J. D. Dixon, "Asymptotically fast factorization of
  7712. integers," Mathematics of Computation, Vol. 36, No. 153, January
  7713. 1981, pp. 255-260.
  7714.  
  7715. [DOLE81] D. Dolev and A. C. Yao, "On the security of public key
  7716. protocols," in 22nd Annual Symposium on Foundations of Computer
  7717. Science, Nashville, TN, October 28-30, 1981, pp. 350-357. Silver
  7718. Spring, MD: IEEE Computer Society Press, 1981.
  7719.  
  7720.  
  7721. [DUSS90] S. R. Dusse and B. S. Kaliski, Jr., "A cryptographic
  7722. library for the Motorola DSP 56000," presented at EUROCRYPT '90,
  7723. Aarhuis, DEnmark, May 21-24, 1990.
  7724.  
  7725. [EHRS78] W. F. Ehrsam, S. M. Matyas, C. H. Meyer, and W. L.
  7726. Tuchman, "A cryptographic key management scheme for implementing
  7727. the Data Encryption Standard," IBM Systems Journal, Vol. 17, No.
  7728. 2, 1978, pp. 106-125.
  7729.  
  7730. [ELGA85] T. ElGamal, "A public key cryptosystem and a signature
  7731. scheme based on discrete logarithms," IEEE Transactions on
  7732. Information Theory, Vol. IT-31, No. 4, July 1985, pp. 469-472. 
  7733.  
  7734. [ELGA85b] T. ElGamal, "On computing logarithms over finite fields,"
  7735. in H. C. Williams, Ed., Lecture Notes in Computer Science Vol. 218:
  7736. Advances in Cryptology - CRYPTO '85, proceedings of a Conference
  7737. on the Theory and Applications of Cryptographic Techniques, Santa
  7738. Barbara, CA, August 18-22, 1985, pp. 396-402. Berlin/New York:
  7739. Springer-Verlag, 1986.
  7740.  
  7741. [EVAN74] A. Evans Jr. and W. Kantrowitz, "A user authentication
  7742. scheme not requiring secrecy in the computer," Communications of
  7743. the ACM,  Vol. 17, No. 8, August 1974, pp. 437-442. 
  7744.  
  7745. [FEIG87] U. Feige, A. Fiat, and A. Shamir, "Zero knowledge proofs
  7746. of identity," in Proceedings of the Nineteenth Annual ACM Symposium
  7747. on Theory of Computing, New York, NY, May 25-27, 1987, pp. 210-
  7748. 217. New York: ACM, 1987.
  7749.  
  7750. [FIAT86] A. Fiat and A. Shamir, "How to prove yourself: practical
  7751. solutions to identification and signature problems," in A. M.
  7752. Odlyzko, Ed., Lecture Notes in Computer Science Vol. 263: Advances
  7753. in Cryptology - CRYPTO '86, proceedings of a Conference on the
  7754. Theory and Applications of Cryptographic Techniques, Santa Barbara,
  7755. CA, August 11-15, 1986, pp. 186-194. Berlin/New York: Springer-
  7756. Verlag, 1987.
  7757.  
  7758. [FLYN78] R. Flynn and A. S. Campasano, "Data dependent keys for a
  7759. selective encryption terminal," in S. P. Ghosh and L. Y. Liu, Eds.,
  7760. AFIPS Conference Proceedings Vol. 47: National Computer Conference,
  7761. Anaheim, CA, June 5-8, 1978, pp. 1127-1129. Montvale, NJ: AFIPS
  7762. Press, 1978.
  7763.  
  7764. [GARE79] M. R. Garey and D. S. Johnson, Computers and
  7765. Intractability. New York: W. H. Freeman, 1979. 
  7766.  
  7767. [GILL77] J. Gill, "Computational complexity of probabilistic Turing
  7768. machines," SIAM Journal on Computing, Vol. 6, No. 4, December 1977,
  7769. pp. 675-695.
  7770.  
  7771. [GOLD84] S. Goldwasser and S. Micali, "Probabilistic encryption,"
  7772. Journal of Computer and System Sciences, Vol. 28, No. 2, April
  7773. 1984, pp. 270-299.
  7774.  
  7775. [GOLD89] S. Goldwasser, S. Micali, and C. Rackoff, "The knowledge
  7776. complexity of interactive proof systems," SIAM Journal on
  7777. Computing, Vol. 18, No. 1, February 1989, pp. 186-208.
  7778.  
  7779. [GOLD88] S. Goldwasser, S. Micali, and R. L. Rivest, "A digital
  7780. signature scheme secure against adaptive chosen-message attacks,"
  7781. SIAM Journal on Computing, Vol. 17, No. 2, April 1988, pp. 281-308.
  7782.  
  7783. [GORD84b] J. Gordon, "Strong RSA keys," Electronics Letters, Vol.
  7784. 20, No. 12, June 7, 1984, pp. 514-516.
  7785.  
  7786. [GORD84] J. A. Gordon, "Strong primes are easy to find," in T.
  7787. Beth, N. Cot, and I. Ingemarsson, Eds., Lecture Notes in Computer
  7788. Science Vol. 209: Advances in Cryptology: Proceedings of EUROCRYPT
  7789. 84, a Workshop on the Theory and Application of Cryptographic
  7790. Techniques, Paris, France, April 9-11, 1984, pp. 216-223.
  7791. Berlin/New York: Springer-Verlag, 1985.
  7792.  
  7793. [GROL88] J. Grollman and A. L. Selman, "Complexity measures for
  7794. public-key cryptosystems," SIAM Journal on Computing, Vol. 17, No.
  7795. 2, April 1988, pp. 309-335.
  7796.  
  7797. [HAST88] J. Hastad, "Solving simultaneous modular equations of low
  7798. degree," SIAM Journal on Computing, Vol. 17, No. 2, April 1988, pp.
  7799. 336-341.
  7800.  
  7801. [HAWK87] S. Hawkinson, "The FPS T Series: a parallel vector
  7802. supercomputer," in W. J. Karplus, Ed., Multiprocessors and Array
  7803. Processors, pp. 147-155. San Diego: Simulation Councils Inc., 1987.
  7804.  
  7805. [HAYE86] J. P. Hayes, T. Mudge, Q. F. Stout, S. Colley, and J.
  7806. Palmer, "A microprocessor-based hypercube supercomputer," IEEE
  7807. Micro, Vol. 6, No. 5, October 1986, pp. 6-17.
  7808.  
  7809. [HAYK88] M. E. Haykin and R. B. J. Warnar, "Smart card technology:
  7810. new methods for computer access control," NIST Special Publication
  7811. 500-157, September 1988.
  7812.  
  7813. [HENR81] P. S. Henry, "Fast decryption algorithm for the knapsack
  7814. cryptographic system," Bell System Technical Journal, Vol. 60, No.
  7815. 5, May-June 1981, pp. 767-773.
  7816.  
  7817. [HERS64] I. N. Herstein, Topics in Algebra. Waltham: Blaisdell,
  7818. 1964.
  7819.  
  7820. [HILL85] D. Hillis, The Connection Machine. Cambridge, MA: MIT
  7821. Press, 1985.
  7822.  
  7823. [HOCK81] R. W. Hockney and C. R. Jesshope, Parallel Computers:
  7824. Architecture, Programming and Algorithms. Bristol: Adam Hilger,
  7825. 1981.
  7826.  
  7827. [HORO78] E. Horowitz and S. Sahni, Fundamentals of Computer
  7828. Algorithms. Rockville: Computer Science Press, 1978.
  7829.  
  7830. [HWAN84] K. Hwang and F. A. Briggs, Computer Architecture and
  7831. Parallel Processing. New York: McGraw-Hill, 1984.
  7832.  
  7833. [IAB-90] IAB Privacy and Security Research Group, "Privacy
  7834. enhancement for Internet electronic mail: Part I: Message
  7835. encipherment and authentication procedures," RFC 1113B, December
  7836. 18, 1990.
  7837.  
  7838. [ISO-87] International Organization for Standards, Draft
  7839. International Standard ISO/DIS 7498-2, Information processing
  7840. systems - Open Systems Interconnection Model - Part 2: Security
  7841. Architecture, 1987.
  7842.  
  7843. [JUEN82] R. R. Jueneman, "Analysis of certain aspects of output
  7844. feedback mode," in D. Chaum, R. L. Rivest, and A. T. Sherman, Eds.,
  7845. Advances in Cryptology - proceedings of CRYPTO 82, a Workshop on
  7846. the Theory and Application of Cryptographic Techniques, Santa
  7847. Barbara, CA, August 23-25, 1982, pp. 99-127. New York: Plenum
  7848. Press, 1983.
  7849.  
  7850. [JUEN86] R. R. Jueneman, "A high speed manipulation detection
  7851. code," in A. M. Odlyzko, Ed., Lecture Notes in Computer Science
  7852. Vol. 263: Advances in Cryptology - CRYPTO '86, proceedings of a
  7853. Conference on Theory and Applications of Cryptographic Techniques,
  7854. Santa Barbara, CA, August 11-15, 1986, pp. 327-346. Berlin/New
  7855. York: Springer-Verlag, 1987. 
  7856.  
  7857. [KHAC79] L. G. Khacian, "A polynomial algorithm in linear
  7858. programming," Dokl. Akad. Nauk. SSSR 244, pp. 1093-1096. English
  7859. translation in Soviet Math. Dokl. 20, pp. 191-194.
  7860.  
  7861. [KLIN79] C. S. Kline and G. J. Popek, "Public key vs. conventional
  7862. key  encryption," in R. E. Merwin, Ed., AFIPS Conference
  7863. Proceedings Vol. 48: National Computer Conference, June 4-7, 1979,
  7864. New York, NY, pp. 831-837. Montvale, NJ: AFIPS Press, 1979. 
  7865.  
  7866. [KNUT81] D. E. Knuth, The Art of Computer Programming, Vol. 2:
  7867. Seminumerical Algorithms. Reading, MA: Addison-Wesley, 1981. 
  7868.  
  7869. [KOHN78b] L. M. Kohnfelder, "On the signature reblocking problem
  7870. in public-key cryptosystems," Communications of the ACM, Vol. 21,
  7871. No. 2, February 1978, p. 179.
  7872.  
  7873. [KOHN78] L. M. Kohnfelder, "A method for certification," MIT
  7874. Laboratory for Computer Science, Cambridge, MA, May 1978.
  7875.  
  7876. [KONH81] A. G. Konheim, Cryptography: a Primer. New York: John
  7877. Wiley & Sons, 1981. 
  7878.  
  7879. [KOWA85] J. Kowalik, Ed., Parallel MIMD Computation: the HEP
  7880. supercomputer and its Applications. Cambridge, MA: MIT Press, 1985.
  7881.  
  7882. [KRAN86] E. Kranakis, Primality and Cryptography. Chichester/New
  7883. York: John Wiley & Sons, 1986. 
  7884.  
  7885. [KUNG82] H. T. Kung, "Why systolic architectures," Computer, Vol.
  7886. 15, No. 1, January 1982, pp. 37-46.
  7887.  
  7888. [KUNG78] H. T. Kung and C. Leiserson, "Systolic arrays (for VLSI),"
  7889. in I. S. Duff and G. W. Stewart, Eds., Sparse Matrix Proceedings,
  7890. pp. 245-282. Philadelphia: SIAM, 1978.
  7891.  
  7892. [KUNG82b] S. Y. Kung, K. S. Arun, R. J. Gal-Ezer, and D. V. B. Rao,
  7893. "Wavefront array processor: language, architecture, and
  7894. applications," IEEE Transactions on Computers, Vol. C-31, No. 11,
  7895. November 1982, pp. 1054-1066.
  7896.  
  7897. [LAGA84] J. C. Lagarias, "Performance analysis of Shamir's attack
  7898. on the basic Merkle-Hellman knapsack system," in J. Paredaens, Ed.,
  7899. Lecture Notes in Computer Science Vol. 172: Automata, Languages and
  7900. Programming: 11th Colloquium, Antwerp, Belgium, July 16-20, 1984,
  7901. pp. 312-323. Berlin/New York: Springer-Verlag, 1984.
  7902.  
  7903. [LAGA83] J. C. Lagarias and A. M. Odlyzko, "Solving low-density
  7904. subset sum problems," in 24th Annual Symposium on Foundations of
  7905. Computer Science, Tucson, AZ, November 7-9, 1983, pp. 1-10. Silver
  7906. Spring, MD: IEEE Computer Society Press, 1983. Revised version in
  7907. Journal of the Association for Computing Machinery, Vol. 32, No.
  7908. 1, January 1985, pp. 229-246.
  7909.  
  7910. [LAKS83] S. Lakshmivarahan, "Algorithms for public key
  7911. cryptosystems: theory and application," Advances in Computers, Vol.
  7912. 22, 1983, pp. 45-108. 
  7913.  
  7914. [LAWS71] B. A. Laws, Jr. and C. K. Rushforth, "A cellular-array
  7915. multiplier for GF(2m)," IEEE Transactions on Computers, Vol. 20,
  7916. No. 12, December 1971, pp. 1573-1578.
  7917.  
  7918. [LEHM82] D. J. Lehman, "On primality tests," SIAM Journal on
  7919. Computing, Vol. 11, No. 2, May 1982, pp. 374-375.
  7920.  
  7921. [LEHM76] D. H. Lehmer, "Strong Carmichael numbers," Journal of the
  7922. Australian Mathematical Society, Vol. 21 (Series A), 1976, pp. 508-
  7923. 510.
  7924.  
  7925. [LEMP79] A. Lempel, "Cryptology in transition," ACM Computing
  7926. Surveys, Vol. 11, No. 4, December 1979, pp. 285-303. 
  7927.  
  7928. [LENS82] A. K. Lenstra, H. W. Lenstra, Jr., and L. Lovasz,
  7929. "Factoring polynomials with rational coefficients," Mathematische
  7930. Annalen, Vol. 261, 1982, pp. 515-534.
  7931.  
  7932. [LENS90] A. K. Lenstra, H. W. Lenstra, Jr., M. S. Manasse, and J.
  7933. M. Pollard, "The number field sieve."
  7934.  
  7935. [LENS89] A. K. Lenstra and M. S. Manasse, "Factoring by electronic
  7936. mail," to appear in proceedings of EUROCRYPT '89.
  7937.  
  7938. [LENS83] H. W. Lenstra, Jr., "Integer programming with a fixed
  7939. number of variables," Mathematics of Operations Research, Vol. 8,
  7940. No. 4, November 1983, pp. 538-548.
  7941.  
  7942. [LENS86] H. W. Lenstra, Jr., "Primality testing," in J. W. de
  7943. Bakker et al., Eds., Mathematics and Computer Science, CWI
  7944. Monographs, I, pp. 269-287. Amsterdam/New York: North-Holland,
  7945. 1986.
  7946.  
  7947. [LENS87] H. W. Lenstra, Jr., "Factoring integers with elliptic
  7948. curves," Annals of Mathematics, Vol. 126, 1987, pp. 649-673.
  7949.  
  7950. [LEWI81] H. R. Lewis and C. H. Papadimitriou, Elements of the
  7951. Theory of Computation. Englewood Cliffs, NJ: Prentice-Hall, 1981.
  7952.  
  7953. [LINN89] J. Linn and S. T. Kent, "Privacy for DARPA-Internet mail,"
  7954. in Proceedings of the 12th National Computer Security Conference,
  7955. Baltimore, MD, October 10-13, 1989, pp. 215-229.
  7956.  
  7957. [MACM81] D. MacMillan, "Single chip encrypts data at 14 Mb/s,"
  7958. Electronics, Vol. 54, No. 12, June 16, 1981, pp. 161-165. 
  7959.  
  7960. [MASS88] J. L. Massey, "An introduction to contemporary
  7961. cryptology,"  Proceedings of the IEEE, Vol. 76, No. 5, May 1988,
  7962. pp. 533-549. 
  7963.  
  7964. [MATY78] S. M. Matyas and C. H. Meyer, "Generation, distribution,
  7965. and installation of cryptographic keys," IBM Systems Journal, Vol.
  7966. 17, No. 2, 1978, pp. 126-137.
  7967.  
  7968. [MCCU89] K. S. McCurley, "The discrete logarithm problem,"
  7969. preprint.
  7970.  
  7971. [MCEL78] R. J. McEliece, "A public-key cryptosystem based on
  7972. algebraic coding theory," DSN Progress Report 42-44, Jet Propulsion
  7973. Laboratory, 1978, pp. 114-116.
  7974.  
  7975. [MERK78] R. C. Merkle, "Secure communications over insecure
  7976. channels,"  Communications of the ACM, Vol. 21, No. 4, April 1978,
  7977. pp. 294-299. 
  7978.  
  7979. [MERK82] R. C. Merkle, Secrecy, Authentication, and Public Key
  7980. Systems. Ann Arbor: UMI Research Press, 1982. 
  7981.  
  7982. [MERK82b] R. C. Merkle, "Protocols for public key cryptosystems,"
  7983. in G. J. Simmons, Ed., Secure Communications and Asymmetric
  7984. Cryptosystems, pp. 73-104. Boulder, CO: Westview Press, 1982.
  7985.  
  7986. [MERK89] R. C. Merkle, "One way hash functions and DES," preprint.
  7987.  
  7988. [MERK78b] R. C. Merkle and M. E. Hellman, "Hiding information and
  7989. signatures in trapdoor knapsacks," IEEE Transactions on Information
  7990. Theory, Vol. 24, No. 5, September 1978, pp. 525-530.
  7991.  
  7992. [MILL76] G. L. Miller, "Riemann's hypothesis and tests for
  7993. primality," Journal of Computer and System Sciences, Vol. 13, No.
  7994. 3, December 1976, pp. 300-317.
  7995.  
  7996. [MILU88] V. M. Milutinovic, Computer Architecture: Concepts and
  7997. Systems. New York: North-Holland, 1988.
  7998.  
  7999. [MONT85] P. L. Montgomery, "Modular multiplication without trial
  8000. division," Mathematics of Computation, Vol. 44, No. 170, April
  8001. 1985, pp. 519-521.
  8002.  
  8003. [MOOR88] J. H. Moore, "Protocol failures in cryptosystems,"
  8004. Proceedings of the IEEE, Vol. 76, No. 5, May 1988, pp. 594-602. 
  8005.  
  8006. [MORR75] M. A. Morrison and J. Brillhart, "A method of factoring
  8007. and the factorization of F7," Mathematics of Computation, Vol. 29,
  8008. No. 129, January 1975, pp. 183-205.
  8009.  
  8010. [NATI77] National Bureau of Standards, Federal Information
  8011. Processing Standards Publication 46: Data Encryption Standard,
  8012. January 15, 1977. 
  8013.  
  8014. [NATI80] National Bureau of Standards, Federal Information
  8015. Processing Standards Publication 81: DES Modes of Operation,
  8016. December 2, 1980.
  8017.  
  8018. [NATI81] National Bureau of Standards, Federal Information
  8019. Processing Standards Publication 74: Guidelines for Implementing
  8020. and Using the NBS Data Encryption Standard, April 1, 1981.
  8021.  
  8022. [NEED78] R. M. Needham and M. D. Schroeder, "Using encryption for
  8023. authentication in large networks of computers," Communications of
  8024. the ACM, Vol. 21, No. 12, December 1978, pp. 993-999. 
  8025.  
  8026. [ODLY84] A. M. Odlyzko, "Cryptanalytic attacks on the
  8027. multiplicative knapsack cryptosystem and on Shamir's fast signature
  8028. scheme," IEEE Transactions on Information Theory, Vol. IT-30, No.
  8029. 4, July 1984, pp. 594-601. 
  8030.  
  8031. [ODLY84b] A. M. Odlyzko, "Discrete logarithms in finite fields and
  8032. their cryptographic significance," in T. Beth, N. Cot, and I.
  8033. Ingemarsson, Eds., Lecture Notes in Computer Science Vol. 209:
  8034. Advances in Cryptology: Proceedings of EUROCRYPT 84, a Workshop on
  8035. the Theory and Application of Cryptographic Techniques, Paris,
  8036. France, April 9-11, 1984, pp. 224-314. Berlin/New York: Springer-
  8037. Verlag, 1985.
  8038.  
  8039. [ORTO86] G. A. Orton, M. P. Roy, P. A. Scott, L. E. Peppard, and
  8040. S. E. Tavares, "VLSI implementation of public-key encryption
  8041. algorithms," in A. M. Odlyzko, Ed., Lecture Notes in Computer
  8042. Science Vol. 263: Advances in Cryptology - CRYPTO '86, proceedings
  8043. of a Conference on the Theory and Applications of Cryptographic
  8044. Techniques, Santa Barbara, CA, August 11-15, 1986, pp. 277-301.
  8045. Berlin/New York: Springer-Verlag, 1987.
  8046.  
  8047. [PATT87] W. Patterson, Mathematical Cryptology for Computer
  8048. Scientists and Mathematicians. Totowa, NJ: Rowman & Littlefield,
  8049. 1987. 
  8050.  
  8051. [PERA86] R. C. Peralta, "A simple and fast probabilistic algorithm
  8052. for computing square roots modulo a prime number," IEEE
  8053. Transactions on Information Theory, Vol. 32, No. 6, November 1986,
  8054. pp. 846-847.
  8055.  
  8056. [POHL78] S. C. Pohlig and M. E. Hellman, "An improved algorithm for
  8057. computing logarithms over GF(p) and its cryptographic
  8058. significance," IEEE Transactions on Information Theory, Vol. IT-24,
  8059. No. 1, January 1978, pp. 106-110. 
  8060.  
  8061. [POME84] C. Pomerance, "The quadratic sieve factoring algorithm,"
  8062. in T. Beth, N. Cot, and I. Ingemarsson, Eds., Lecture Notes in
  8063. Computer Science Vol. 209: Advances in Cryptology: proceedings of
  8064. EUROCRYPT 84, a Workshop on the Theory and Application of
  8065. Cryptographic Techniques, Paris, France, April 9-11, 1984, pp. 169-
  8066. 182. Berlin/New York: Springer-Verlag, 1985.
  8067.  
  8068. [POME86] C. Pomerance, "Fast, rigorous factorization and discrete
  8069. logarithm algorithms," in D. S. Johnson, T. Nishizeki, A. Nozaki,
  8070. and H. S. Wilf, Eds., Discrete Algorithms and Complexity,
  8071. proceedings of the Japan-US Joint Seminar, Kyoto, Japan, June 4-
  8072. 6, 1986, pp. 119-143. Orlando, FL: Academic Press, 1987.
  8073.  
  8074. [POME88] C. Pomerance, J. W. Smith, and R. Tuler, "A pipeline
  8075. architecture for factoring large integers with the quadratic sieve
  8076. algorithm," SIAM Journal on Computing, Vol. 17, No. 2, April 1988,
  8077. pp. 387-403. 
  8078.  
  8079. [POPE78] G. J. Popek and C. S. Kline, "Encryption protocols, public
  8080. key algorithms and digital signatures in computer networks," in R.
  8081. A. DeMillo, D. P. Dobkin, A. K. Jones, and R. J. Lipton, Eds.,
  8082. Foundations of Secure Computation, pp. 133-153. New York: Academic
  8083. Press, 1978.
  8084.  
  8085. [POPE79] G. L. Popek and C. S. Kline, "Encryption and secure
  8086. computer networks," ACM Computing Surveys, Vol. 11, No. 4, December
  8087. 1979, pp. 331-356. 
  8088.  
  8089. [QUIN87] M. J. Quinn, Designing Efficient Algorithms for Parallel
  8090. Computers. New York: McGraw-Hill, 1987.
  8091.  
  8092. [QUIS82] J.-J. Quisquater and C. Couvreur, "Fast decipherment
  8093. algorithm for RSA public-key cryptosystem," Electronics Letters,
  8094. Vol. 18, No. 21, October 14, 1982, pp. 905-907. 
  8095.  
  8096. [RABI76] M. O. Rabin, "Probabilistic algorithms," in J. F. Traub,
  8097. Ed., Algorithms and Complexity: New Directions and Recent Results,
  8098. proceedings of a Symposium, Pittsburgh, PA, April 7-9, 1976, pp.
  8099. 21-39. New York: Academic Press, 1976.
  8100.  
  8101. [RABI78] M. O. Rabin, "Digitalized signatures," in R. A. DeMillo,
  8102. D. P. Dobkin, A. K. Jones, and R. J. Lipton, Eds., Foundations of
  8103. Secure Computation, pp. 155-168. New York: Academic Press, 1978. 
  8104.  
  8105. [RABI79] M. O. Rabin, "Digitalized signatures and public-key
  8106. functions as intractable as factorization," MIT Laboratory for
  8107. Computer Science, Technical Report LCS/TR-212, January 1979.
  8108.  
  8109. [RABI80] M. O. Rabin, "Probabilistic algorithms for testing
  8110. primality," Journal of Number Theory, Vol. 12, 1980, pp. 128-138.
  8111.  
  8112. [RADE64] H. Rademacher, Lectures on Elementary Number Theory. New
  8113. York: Blaisdell, 1964.
  8114.  
  8115. [RIVE84] R. L. Rivest, "RSA chips (past/present/future)," in T.
  8116. Beth, N. Cot, and I. Ingemarsson, Eds., Lecture Notes in Computer
  8117. Science Vol. 209: Advances in Cryptology: proceedings of EUROCRYPT
  8118. 84, a Workshop on the Theory and Application of Cryptographic
  8119. Techniques, Paris, France, April 9-11, 1984, pp. 159-165.
  8120. Berlin/New York: Springer-Verlag, 1985.
  8121.  
  8122. [RIVE90] R. L. Rivest, "The MD4 message digest algorithm," February
  8123. 1990.
  8124.  
  8125. [RIVE78] R. L. Rivest, A. Shamir, and L. Adleman, "A method for
  8126. obtaining digital signatures and public-key cryptosystems,"
  8127. Communications  of the ACM, Vol. 21, No. 2, February 1978, pp.
  8128. 120-127. 
  8129.  
  8130. [RIVE82] R. L. Rivest and A. T. Sherman, "Randomized encryption
  8131. techniques," in D. Chaum, R. L. Rivest, and A. T. Sherman, Eds.,
  8132. Advances in Cryptology: Proceedings of CRYPTO 82, a Workshop on the
  8133. Theory and Application of Cryptographic Techniques, Santa Barbara,
  8134. CA, August 23-25, 1982, pp. 145-163. New York: Plenum Press, 1983.
  8135.  
  8136. [SIAM90] "Number field sieve produces factoring breakthrough," SIAM
  8137. News, Vol. 23, No. 4, July 1990.
  8138.  
  8139. [SALO85] Salomaa, "Cryptography," in A. Salomaa, Encyclopedia of
  8140. Mathematics and its Applications Vol. 25: Computation and Automata,
  8141. pp. 186-230. Cambridge, UK: Cambridge University Press, 1985.
  8142.  
  8143. [SCHA82] B. P. Schanning, "Applying public key distribution to
  8144. local area networks," Computers & Security, Vol. 1, No. 3, November
  8145. 1982, pp. 268-274. 
  8146.  
  8147. [SCHA80] B. P. Schanning, S. A. Powers, and J. Kowalchuk, "MEMO:
  8148. privacy and authentication for the automated office," in
  8149. proceedings of the 5th Conference on Local Computer Networks,
  8150. Minneapolis, MN, October 6-7, 1980, pp. 21-30. Silver Spring, MD:
  8151. IEEE Computer Society Press, 1980.
  8152.  
  8153. [SCHN84] C. P. Schnorr and H. W. Lenstra, Jr., "A Monte Carlo
  8154. factoring algorithm with linear storage," Mathematics of
  8155. Computation, Vol. 43, No. 167, July 1984, pp. 289-311.
  8156.  
  8157. [SEDL87] H. Sedlak, "The RSA Cryptography Processor," in D. Chaum
  8158. and W. L. Price, Eds., Lecture Notes in Computer Science Vol. 304:
  8159. Advances in Cryptology - EUROCRYPT '87, a Workshop on the Theory
  8160. and Applications of Cryptographic Techniques, Amsterdam, The
  8161. Netherlands, April 13-15, 1987, pp. 95-105. Berlin/New York:
  8162. Springer-Verlag, 1988.
  8163.  
  8164. [SEIT85] C. L. Seitz, "The Cosmic Cube," Communications of the ACM,
  8165. Vol. 28, No. 1, January 1985, pp. 22-33.
  8166.  
  8167. [SHAM79] A. Shamir, "On the cryptocomplexity of knapsack systems,"
  8168. in proceedings of the Eleventh Annual ACM Symposium on Theory of
  8169. Computing, Atlanta, GA, April 30 - May 2, 1979, pp. 118-129. New
  8170. York: ACM, 1979.
  8171.  
  8172. [SHAM84b] A. Shamir, "Identity-based cryptosystems and signature
  8173. schemes," in G. R. Blakley and D. Chaum, Eds., Lecture Notes in
  8174. Computer Science Vol. 196: Advances in Cryptology: Proceedings of
  8175. CRYPTO 84, a Workshop on the Theory and Application of
  8176. Cryptographic Techniques, Santa Barbara, CA, August 19-22, 1984,
  8177. pp. 47-53. Berlin/New York: Springer-Verlag, 1985.
  8178.  
  8179. [SHAM84] A. Shamir, "A polynomial-time algorithm for breaking the
  8180. basic Merkle-Hellman cryptosystem," IEEE Transactions on
  8181. Information Theory, Vol. IT-30, No. 5, September 1984, pp. 699-704.
  8182.  
  8183. [SHAN90] M. Shand, P. Bertin, and J. Vuillemin, "Hardware speedups
  8184. in long integer multiplication," presented at the Second ACM
  8185. Symposium on Parallel Algorithms and Architectures, Crete, July 2-
  8186. 6, 1990.
  8187.  
  8188. [SILV87] R. D. Silverman, "The multiple polynomial quadratic
  8189. sieve," Mathematics of Computation, Vol. 48, No. 177, January 1987,
  8190. pp. 329-339.
  8191.  
  8192. [SIMM79] G. J. Simmons, "Symmetric and asymmetric encryption," ACM
  8193. Computing Surveys, Vol. 11, No. 4, December 1979, pp. 305-330. 
  8194.  
  8195. [SIMM88] G. J. Simmons, "How to ensure that data acquired to verify
  8196. treaty compliance are trustworthy," Proceedings of the IEEE, Vol.
  8197. 76, No. 5, May 1988, pp. 621-627. 
  8198.  
  8199. [SMID81] M. E. Smid, "Integrating the data encryption standard into
  8200. computer networks," IEEE Transactions on Computers, Vol. COM-29,
  8201. No. 6, June 1981, pp. 762-772.
  8202.  
  8203. [SMID88b] M. E. Smid and D. K. Branstad, "The Data Encryption
  8204. Standard: past and future," Proceedings of the IEEE, Vol. 76, No.
  8205. 5, May 1988, pp. 550-559. 
  8206.  
  8207. [SOLO77] R. Solovay and V. Strassen, "A fast Monte-Carlo test for
  8208. primality," SIAM Journal on Computing, Vol. 6, No. 1, March 1977,
  8209. pp. 84-85. Erratum: Ibid., Vol. 7, No. 1, February 1978, p. 118.
  8210.  
  8211. [STEI86] L. K. Steiner, "The ETA-10 supercomputer system," in
  8212. Proceedings of the 1986 IEEE International Conference on Computer
  8213. Design, Port Chester, NY, October 6-9, p. 42. Washington, DC: IEEE
  8214. Computer Society Press, 1986.
  8215.  
  8216. [TANE81] A. S. Tanenbaum, Computer Networks. Englewood Cliffs, NJ:
  8217. Prentice-Hall, 1981.
  8218.  
  8219. [WAGN84] N. R. Wagner and M. R. Magyarik, "A public-key
  8220. cryptosystem based on the word problem," in G. R. Blakley and D.
  8221. Chaum, Eds., Lecture Notes in Computer Science Vol. 196: Advances
  8222. in Cryptology - Proceedings of CRYPTO 84, a Workshop on the Theory
  8223. and Applications of Cryptographic Techniques, Santa Barbara, CA,
  8224. August 19-22, 1984, pp. 19-36. Berlin/New York: Springer-Verlag,
  8225. 1985.
  8226.  
  8227. [WANG85] C. C. Wang, T. K. Truong, H. M. Shao, L. J. Deutsch, J.
  8228. K. Omura, and I. S. Reed, "VLSI architectures for computing
  8229. multiplications and inverses in GF(2m)," IEEE Transactions on
  8230. Computers, Vol. C-34, No. 8, August 1985, pp. 709-717.
  8231.  
  8232. [WILK68] M. V. Wilkes, Time-Sharing Computer Systems. New York:
  8233. Elsevier, 1968. 
  8234.  
  8235. [WILL80] H. C. Williams, "A modification of the RSA public-key
  8236. encryption procedure," IEEE Transactions on Information Theory,
  8237. Vol. IT-26, No. 6, November 1980, pp. 726-729. 
  8238.  
  8239. [WILL87] H. C. Williams and M. C. Wunderlich, "On the parallel
  8240. generation of the residues for the continued fraction factoring
  8241. algorithm," Mathematics of Computation, Vol. 48, No. 177, January
  8242. 1987, pp. 405-423.
  8243.  
  8244. [WUND83] M. C. Wunderlich, "Factoring numbers on the Massively
  8245. Parallel computer," in D. Chaum, Ed., Advances in Cryptology -
  8246. proceedings of CRYPTO 83, a Workshop on the Theory and Applications
  8247. of Cryptographic Techniques, Santa Barbara, CA, August 22-24, 1983,
  8248. pp. 87-102. New York: Plenum Press, 1984.
  8249.  
  8250. [WUND85] M. C. Wunderlich, "Implementing the continued  fraction
  8251. factoring algorithm on parallel machines," Mathematics of
  8252. Computation, Vol. 44, No. 169, January 1985, pp. 251-260.
  8253.  
  8254. [YAO-82] A. C. Yao, "Theory and applications of trapdoor
  8255. functions," in 23rd Annual Symposium on Foundations of Computer
  8256. Science, Chicago, IL, November 3-5, 1982, pp. 80-91. IEEE Computer
  8257. Society Press, 1982.
  8258.  
  8259.  
  8260.