home *** CD-ROM | disk | FTP | other *** search
/ Hacker Chronicles 2 / HACKER2.BIN / 1096.PUBKEY.FAQ < prev    next >
Text File  |  1993-12-24  |  346KB  |  8,269 lines

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