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

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