8274 lines
338 KiB
Plaintext
8274 lines
338 KiB
Plaintext
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
PUBLIC-KEY CRYPTOGRAPHY
|
|||
|
NIST Special Publication 800-2
|
|||
|
|
|||
|
|
|||
|
James Nechvatal
|
|||
|
Security Technology Group
|
|||
|
National Computer Systems Laboratory
|
|||
|
National Institute of Standards and Technology
|
|||
|
Gaithersburg, MD 20899
|
|||
|
|
|||
|
|
|||
|
April 1991
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
PREFACE
|
|||
|
|
|||
|
|
|||
|
This publication presents a state-of-the-art survey of public-
|
|||
|
key cryptography circa 1988 - 1990. In doing so, it covers a number
|
|||
|
of different topics including:
|
|||
|
|
|||
|
|
|||
|
1. The theory of public-key cryptography.
|
|||
|
|
|||
|
2. Comparisons to conventional (secret-key) cryptography.
|
|||
|
|
|||
|
3. A largely self-contained summary of relevant mathematics.
|
|||
|
|
|||
|
4. A survey of major existing public-key systems.
|
|||
|
|
|||
|
5. An exploration of digital signatures and hash functions.
|
|||
|
|
|||
|
6. A survey of public-key implementations in networks.
|
|||
|
|
|||
|
7. An introduction to zero-knowledge protocols and
|
|||
|
probabilistic encryption.
|
|||
|
|
|||
|
8. An exploration of security issues and key sizes.
|
|||
|
|
|||
|
|
|||
|
The treatment of public-key cryptography in this publication
|
|||
|
includes both theory and practice. Much of the existing published
|
|||
|
work, including those documents listed in the references, treats
|
|||
|
either the theory or specific systems/implementations, but not
|
|||
|
both. The viewpoint here is that the theory and practice are
|
|||
|
inseparable.
|
|||
|
|
|||
|
Any mention of commercial products is for purposes of
|
|||
|
explanation and illustration only. Also, the selection of
|
|||
|
cryptosystems and hash functions mentioned in this publication
|
|||
|
serve only to provide examples. Such identification does not imply
|
|||
|
recommendation or endorsement by the National Institute of
|
|||
|
Standards and Technology, nor does it imply that systems or
|
|||
|
functions identified are necessarily the best available for the
|
|||
|
purpose.
|
|||
|
|
|||
|
The focus is on issues such as criteria for systems and
|
|||
|
protocols for usage. These are presumably long-term, in contrast,
|
|||
|
to the set of existing public-key systems which is more volatile.
|
|||
|
Thus we provide information which will hopefully be of use to
|
|||
|
implementors of systems, but the frameworks we develop are
|
|||
|
versatile enough to be relevant in a variety of settings. The
|
|||
|
latter may include, for example, both electronic mail systems and
|
|||
|
electronic fund transfer systems.
|
|||
|
|
|||
|
The core of this exposition is sections 1 to 5. Sections 1 to
|
|||
|
3 cover the fundamentals of public-key cryptography and the related
|
|||
|
topics of hash functions and digital signatures. Extensive coverage
|
|||
|
of key management is also included, with a focus on certificate-
|
|||
|
based management. Section 4 gives some examples of public-key
|
|||
|
systems and hash functions. Section 5 gives some examples of actual
|
|||
|
or proposed implementations of public-key cryptography. The major
|
|||
|
example is the International Organization for Standardization (ISO)
|
|||
|
authentication framework.
|
|||
|
|
|||
|
Section 6 gives a sample proposal for a local-area network
|
|||
|
implementation of public-key cryptography. It draws heavily on the
|
|||
|
work of ISO.
|
|||
|
|
|||
|
A variety of topics are covered in the appendices, including a
|
|||
|
summary of relevant mathematics and algorithms. Also included is
|
|||
|
a brief introduction to zero-knowledge protocols, probabilistic
|
|||
|
encryption and identity-based public-key systems.
|
|||
|
|
|||
|
In the following, letters refer to appendices; e.g. lemma G.2.1
|
|||
|
refers to a lemma appearing in section 2 of appendix G.
|
|||
|
|
|||
|
The author wishes to thank Dr. Ronald L. Rivest, Dr. Gustavus
|
|||
|
Simmons, and Dr. Dennis Branstad for providing many comments and
|
|||
|
suggestions, and Dr. Burton S. Kaliski Jr. for providing
|
|||
|
information on implementations of the RSA public-key system. The
|
|||
|
paper was edited by Miles Smid.
|
|||
|
|
|||
|
This paper was supported in part by the United States Department
|
|||
|
of Computer-Aided Logistics Supports, Department of Defense. CONTENTS
|
|||
|
|
|||
|
|
|||
|
1. Cryptosystems and cryptanalysis...............................1
|
|||
|
|
|||
|
|
|||
|
1.1 Requirements for secrecy..................................2
|
|||
|
1.2 Requirements for authenticity and integrity...............4
|
|||
|
1.3 Conventional systems......................................5
|
|||
|
1.4 Example of a conventional cipher: DES.....................5
|
|||
|
1.5 Another conventional cipher: exponentiation...............6
|
|||
|
1.6 Public-key cryptosystems..................................7
|
|||
|
1.6.1 Secrecy and authenticity...........................8
|
|||
|
1.6.2 Applicability and limitations.....................10
|
|||
|
|
|||
|
|
|||
|
2. Key management...............................................12
|
|||
|
|
|||
|
|
|||
|
2.1 Secret-key management....................................12
|
|||
|
2.2 Public distribution of secret keys.......................13
|
|||
|
2.3 Management of public components in a public-key system...15
|
|||
|
2.3.1 Use of certificates...............................16
|
|||
|
2.3.2 Generation and storage of component pairs.........17
|
|||
|
2.3.3 Hardware support for key management...............18
|
|||
|
2.4 Using public-key systems for secret key distribution.....19
|
|||
|
2.4.1 A protocol for key exchange.......................20
|
|||
|
2.5 Protocols for certificate-based key management...........22
|
|||
|
2.5.1 Certificate management by a central authority.....22
|
|||
|
2.5.2 Decentralized management..........................23
|
|||
|
2.5.3 A phone-book approach to certificates.............24
|
|||
|
|
|||
|
|
|||
|
3. Digital signatures and hash functions........................25
|
|||
|
|
|||
|
|
|||
|
3.1 Public-key implementation of signatures..................27
|
|||
|
3.1.1 Signing messages..................................27
|
|||
|
3.1.2 The issue of nonrepudiation.......................29
|
|||
|
3.1.3 The issue of proof of delivery....................30
|
|||
|
3.2 Hash functions and message digests.......................31
|
|||
|
3.2.1 Usage of hash functions...........................33
|
|||
|
3.2.2 Relation to one-way functions.....................33
|
|||
|
3.2.3 Weak and strong hash functions....................34
|
|||
|
3.3 Digital signatures and certificate-based systems.........35
|
|||
|
|
|||
|
|
|||
|
4. Examples of public-key systems and hash functions............37
|
|||
|
|
|||
|
|
|||
|
4.1 The RSA public-key scheme................................39
|
|||
|
4.1.1 Choice of p and q.................................41
|
|||
|
4.1.2 Further notes on implementation...................42
|
|||
|
4.1.3 Security of RSA...................................43
|
|||
|
4.1.3.1 Restrictions on p and q..................43
|
|||
|
4.1.3.2 Notes on factoring.......................44
|
|||
|
4.1.4 Low-exponent versions of RSA......................45
|
|||
|
4.2 Other public-key systems.................................46
|
|||
|
4.2.1 Knapsack systems..................................47
|
|||
|
4.2.2 The ElGamal signature scheme......................49
|
|||
|
4.3 Examples of hash functions...............................53
|
|||
|
4.3.1 Merkle's meta-method..............................53
|
|||
|
4.3.2 Coppersmith's attack on Rabin-type functions......56
|
|||
|
4.3.3 Quadratic congruential hash functions.............57
|
|||
|
4.4 Hardware and software support............................58
|
|||
|
4.4.1 Design considerations for RSA chips...............58
|
|||
|
4.4.2 Proposed designs for RSA chips....................59
|
|||
|
|
|||
|
|
|||
|
5. Implementations of public-key cryptography...................61
|
|||
|
|
|||
|
|
|||
|
5.1 MITRENET.................................................61
|
|||
|
5.2 ISDN.....................................................62
|
|||
|
5.2.1 Keys..............................................62
|
|||
|
5.2.2 Calling...........................................63
|
|||
|
5.3 ISO Authentication Framework.............................64
|
|||
|
5.3.1 Use of certificates...............................64
|
|||
|
5.3.2 Certification paths...............................65
|
|||
|
5.3.3 Expiration and revocation of certificates.........66
|
|||
|
5.3.4 Authentication protocols..........................67
|
|||
|
5.3.5 Further notes.....................................71
|
|||
|
5.4 DARPA-Internet...........................................71
|
|||
|
|
|||
|
|
|||
|
6. A sample proposal for a LAN implementation...................73
|
|||
|
|
|||
|
|
|||
|
6.1 Integration into a network...............................73
|
|||
|
6.2 Security threats.........................................74
|
|||
|
6.3 Security services........................................74
|
|||
|
6.4 Security mechanisms......................................75
|
|||
|
6.5 Criteria for cryptosystems...............................76
|
|||
|
6.5.1 Security..........................................77
|
|||
|
6.5.2 Numerical criteria................................77
|
|||
|
6.5.3 Other criteria....................................78
|
|||
|
6.6 Criteria for hash functions..............................78
|
|||
|
6.7 Example of a LAN security framework......................78
|
|||
|
6.7.1 Key management....................................79
|
|||
|
6.7.2 Component generation and storage....................79
|
|||
|
6.7.3 Secret-key generation.............................79
|
|||
|
6.7.4 Issuance and distribution of certificates.........80
|
|||
|
6.7.5 Compromised or invalidated certificates...........80
|
|||
|
6.7.6 Authentication....................................81
|
|||
|
|
|||
|
|
|||
|
Appendix A. Mathematical and computational aspects..............83
|
|||
|
|
|||
|
|
|||
|
A.1 Computational complexity and cryptocomplexity............83
|
|||
|
A.2 Classical complexity theory..............................84
|
|||
|
A.3 Public-key systems and cryptocomplexity..................84
|
|||
|
A.4 Probabilistic algorithms.................................85
|
|||
|
A.5 Status of some relevant problems.........................86
|
|||
|
|
|||
|
Appendix B. Algorithms and architectures........................89
|
|||
|
|
|||
|
B.1 Technology...............................................89
|
|||
|
B.2 Computing modes..........................................90
|
|||
|
B.3 Some relevant algorithms and implementation..............92
|
|||
|
B.3.1 Quadratic sieve factoring algorithm................92
|
|||
|
B.3.2 Computations in finite fields......................93
|
|||
|
B.3.3 Other algorithms...................................94
|
|||
|
B.4 Application-specific architectures.......................94
|
|||
|
B.4.1 Systolic and wavefront arrays......................94
|
|||
|
B.4.2 Proposal for a quadratic sieve machine.............95
|
|||
|
B.4.3 Massively parallel machines........................95
|
|||
|
|
|||
|
|
|||
|
Appendix C. The classical theory of computation.................97
|
|||
|
|
|||
|
|
|||
|
C.1 Turing machines..........................................97
|
|||
|
C.2 Nondeterministic Turing machines.........................98
|
|||
|
C.3 Computational complexity.................................99
|
|||
|
|
|||
|
|
|||
|
Appendix D. The theory of probabilistic computing..............101
|
|||
|
|
|||
|
|
|||
|
Appendix E. Breaking knapsacks.................................103
|
|||
|
|
|||
|
|
|||
|
Appendix F. Birthday attacks...................................105
|
|||
|
|
|||
|
|
|||
|
Appendix G. Modular arithmetic and Galois fields...............107
|
|||
|
|
|||
|
|
|||
|
G.1 The Euler Phi function..................................108
|
|||
|
G.2 The Euler-Fermat Theorem................................108
|
|||
|
G.3 Galois fields...........................................110
|
|||
|
|
|||
|
|
|||
|
Appendix H. Euclid's algorithm.................................111
|
|||
|
|
|||
|
|
|||
|
Appendix I. The Chinese Remainder Theorem......................113
|
|||
|
|
|||
|
|
|||
|
Appendix J. Quadratic residues and the Jacobi symbol...........115
|
|||
|
|
|||
|
|
|||
|
J.1 Quadratic residues modulo a prime.......................115
|
|||
|
J.2 The Jacobi symbol.......................................116
|
|||
|
J.3 Square roots modulo a prime.............................117
|
|||
|
J.4 Quadratic residuosity modulo a prime....................118
|
|||
|
|
|||
|
|
|||
|
Appendix K. Primitive roots and discrete logarithms............119
|
|||
|
|
|||
|
|
|||
|
Appendix L. Primality testing..................................123
|
|||
|
|
|||
|
|
|||
|
L.1 The Solovay/Strassen test...............................124
|
|||
|
L.2 Lehman's test...........................................125
|
|||
|
L.3 The Miller/Rabin test...................................126
|
|||
|
|
|||
|
|
|||
|
Appendix M. Mathematics of RSA and other exponential systems...127
|
|||
|
|
|||
|
|
|||
|
Appendix N. Quadratic residuosity modulo a composite...........129
|
|||
|
|
|||
|
N.1 Characterizing quadratic residues.......................129
|
|||
|
N.2 The Jacobi symbol once more.............................130
|
|||
|
N.3 Quadratic residuosity and factoring.....................132
|
|||
|
N.4 Quadratic residuosity and Blum integers.................133
|
|||
|
|
|||
|
|
|||
|
Appendix O. An introduction to zero-knowledge..................137
|
|||
|
|
|||
|
|
|||
|
Appendix P. Alternatives to the Diffie/Hellman model...........143
|
|||
|
|
|||
|
|
|||
|
P.1 Probabilistic encryption................................143
|
|||
|
P.2 Identity-based schemes..................................145
|
|||
|
|
|||
|
|
|||
|
References.....................................................147 LIST OF ILLUSTRATIONS
|
|||
|
|
|||
|
|
|||
|
Figure 1. Adaptive Chosen Plaintext Attack........................3
|
|||
|
|
|||
|
Figure 2. Using Public-Key for Secrecy and Authenticity..........10
|
|||
|
|
|||
|
Figure 3. The Diffie/Hellman Key Exchange........................15
|
|||
|
|
|||
|
Figure 4. A Protocol for Real-Time Authentication................21
|
|||
|
|
|||
|
Figure 5. A Protocol for Signing with Hash Function and Secrecy..28
|
|||
|
|
|||
|
Figure 6. Using RSA for Authenticity and Secrecy.................40
|
|||
|
|
|||
|
Figure 7. The ElGamal Signature Algorithm........................51
|
|||
|
|
|||
|
Figure 8. One-Way Authentication Protocol........................69 1. Cryptosystems and cryptanalysis.
|
|||
|
|
|||
|
|
|||
|
Cryptography deals with the transformation of ordinary text
|
|||
|
(plaintext) into coded form (ciphertext) by encryption, and
|
|||
|
transformation of ciphertext into plaintext by decryption. Normally
|
|||
|
these transformations are parameterized by one or more keys. The
|
|||
|
motive for encrypting text is security for transmissions over
|
|||
|
insecure channels.
|
|||
|
|
|||
|
Three of the most important services provided by cryptosystems
|
|||
|
are secrecy, authenticity, and integrity. Secrecy refers to denial
|
|||
|
of access to information by unauthorized individuals. Authenticity
|
|||
|
refers to validating the source of a message; i.e., that it was
|
|||
|
transmitted by a properly identified sender and is not a replay of
|
|||
|
a previously transmitted message. Integrity refers to assurance
|
|||
|
that a message was not modified accidentally or deliberately in
|
|||
|
transit, by replacement, insertion or deletion. A fourth service
|
|||
|
which may be provided is nonrepudiation of origin, i.e., protection
|
|||
|
against a sender of a message later denying transmission. Variants
|
|||
|
of these services, and other services, are discussed in [ISO-87].
|
|||
|
|
|||
|
Classical cryptography deals mainly with the secrecy aspect. It
|
|||
|
also treats keys as secret. In the past 15 years two new trends
|
|||
|
have emerged:
|
|||
|
|
|||
|
|
|||
|
a. Authenticity as a consideration which rivals and sometimes
|
|||
|
exceeds secrecy in importance.
|
|||
|
|
|||
|
b. The notion that some key material need not be secret.
|
|||
|
|
|||
|
|
|||
|
The first trend has arisen in connection with applications such
|
|||
|
as electronic mail systems and electronic funds transfers. In such
|
|||
|
settings an electronic equivalent of the handwritten signature may
|
|||
|
be desirable. Also, intruders into a system often gain entry by
|
|||
|
masquerading as legitimate users; cryptography presents an
|
|||
|
alternative to password systems for access control.
|
|||
|
|
|||
|
The second trend addresses the difficulties which have
|
|||
|
traditionally accompanied the management of secret keys. This may
|
|||
|
entail the use of couriers or other costly, inefficient and not
|
|||
|
really secure methods. In contrast, if keys are public the task of
|
|||
|
key management may be substantially simplified.
|
|||
|
|
|||
|
An ideal system might solve all of these problems concurrently,
|
|||
|
i.e., using public keys; providing secrecy; and providing
|
|||
|
authenticity. Unfortunately no single technique proposed to date
|
|||
|
has met all three criteria. Conventional systems such as DES
|
|||
|
require management of secret keys; systems using public key
|
|||
|
components may provide authenticity but are inefficient for bulk
|
|||
|
encryption of data due to low bandwidths.
|
|||
|
|
|||
|
Fortunately, conventional and public-key systems are not
|
|||
|
mutually exclusive; in fact they can complement each other. Public-
|
|||
|
key systems can be used for signatures and also for the
|
|||
|
distribution of keys used in systems such as DES. Thus it is
|
|||
|
possible to construct hybrids of conventional and public-key
|
|||
|
systems which can meet all of the above goals: secrecy,
|
|||
|
authenticity and ease of key management.
|
|||
|
|
|||
|
For surveys of the preceding and related topics see, e.g.,
|
|||
|
([BRAS88],[COPP87],[DENN83],[DIFF82],[DIFF79],[KLIN79],[KONH81],
|
|||
|
[LEMP79],[MASS88],[MERK82],[POPE78],[POPE79],[SALO85],[SIMM79]).
|
|||
|
More specialized discussions of public-key cryptography are given,
|
|||
|
e.g., in ([DIFF88],[LAKS83],[MERK82b]). Mathematical aspects are
|
|||
|
covered, e.g., in ([KRAN86],[PATT87]).
|
|||
|
|
|||
|
In the following, E and D represent encryption and decryption
|
|||
|
transformations, respectively. It is always required that D(E(M))
|
|||
|
= M. It may also be the case that E(D(M)) = M; in this event E or
|
|||
|
D can be employed for encryption. Normally D is assumed to be
|
|||
|
secret, but E may be public. In addition it may be assumed that E
|
|||
|
and D are relatively easy to compute when they are known.
|
|||
|
|
|||
|
|
|||
|
1.1 Requirements for secrecy.
|
|||
|
|
|||
|
|
|||
|
Secrecy requires that a cryptanalyst (i.e., a would-be intruder
|
|||
|
into a cryptosystem) should not be able to determine the plaintext
|
|||
|
corresponding to given ciphertext, and should not be able to
|
|||
|
reconstruct D by examining ciphertext for known plaintext. This
|
|||
|
translates into two requirements for a cryptosystem to provide
|
|||
|
secrecy:
|
|||
|
|
|||
|
|
|||
|
a. A cryptanalyst should not be able to determine M from
|
|||
|
E(M); i.e., the cryptosystem should be immune to
|
|||
|
ciphertext-only attacks.
|
|||
|
|
|||
|
b. A cryptanalyst should not be able to determine D given
|
|||
|
{E(Mi)} for any sequence of plaintexts {M1,M2,...};
|
|||
|
i.e. the cryptosystem should be immune to known-plaintext
|
|||
|
attacks. This should remain true even when the
|
|||
|
cryptanalyst can choose {Mi} (chosen-plaintext attack),
|
|||
|
including the case in which the cryptanalyst can inspect
|
|||
|
{E(M1),...,E(Mj)} before specifying Mj+1 (adaptive
|
|||
|
chosen-plaintext attack).
|
|||
|
|
|||
|
|
|||
|
Adaptive chosen plaintext attack is illustrated below.
|
|||
|
|
|||
|
|
|||
|
____________________
|
|||
|
| |
|
|||
|
| i = 0 |
|
|||
|
|____________________|
|
|||
|
| ____________
|
|||
|
| | |
|
|||
|
|/___| i := i + 1 |/___
|
|||
|
|\ |____________|\ /|\
|
|||
|
| |
|
|||
|
________\|/_________ |
|
|||
|
| | |
|
|||
|
| choose M(i+1) | |
|
|||
|
|____________________| |
|
|||
|
| |
|
|||
|
| |
|
|||
|
________\|/_________ |
|
|||
|
| | |
|
|||
|
| compute E(M(i+1)) | |
|
|||
|
|____________________| |
|
|||
|
| |
|
|||
|
| |
|
|||
|
____________\|/_______________ |
|
|||
|
| | |
|
|||
|
| inspect E(M(1)),..,E(M(i+1)) | |
|
|||
|
|______________________________| |
|
|||
|
| |
|
|||
|
| |
|
|||
|
\|/ |
|
|||
|
/ \ |
|
|||
|
/ \___________________\|
|
|||
|
\ / continue /
|
|||
|
\ /
|
|||
|
|
|
|||
|
stop |
|
|||
|
\|/
|
|||
|
|
|||
|
|
|||
|
Figure 1. Adaptive Chosen Plaintext Attack
|
|||
|
|
|||
|
|
|||
|
To illustrate the difference between these two categories, we
|
|||
|
use two examples. First, suppose E(M) = M3 mod N, N = p * q, where
|
|||
|
p and q are large secret primes. Then (cf. sec. 4) it is infeasible
|
|||
|
for a cryptanalyst to determine D, even after inspecting numerous
|
|||
|
pairs of the form {M,E(M)}. However, an eavesdropper who intercepts
|
|||
|
E(M) = 8 can conclude M = 2. Thus a ciphertext-only attack may be
|
|||
|
feasible in an instance where known- or chosen-plaintext attack is
|
|||
|
not useful.
|
|||
|
|
|||
|
On the other hand, suppose E(M) = 5M mod N where N is secret.
|
|||
|
Then interception of E(M) would not reveal M or N; this would
|
|||
|
remain true even if several ciphertexts were intercepted. However,
|
|||
|
an intruder who learns that E(12) = 3 and E(16) = 4 could conclude
|
|||
|
N = 19. Thus a known- or chosen-plaintext attack may succeed where
|
|||
|
a ciphertext-only attack fails.
|
|||
|
|
|||
|
Deficiencies in (a), i.e., vulnerability to ciphertext-only
|
|||
|
attack, can frequently be corrected by slight modifications of the
|
|||
|
encoding scheme, as in the M3 mod N encoding above. Adaptive
|
|||
|
chosen-plaintext is often regarded as the strongest attack.
|
|||
|
|
|||
|
Secrecy ensures that decryption of messages is infeasible.
|
|||
|
However, the enciphering transformation E is not covered by the
|
|||
|
above requirements; it could even be public. Thus secrecy, per se,
|
|||
|
leaves open the possibility that an intruder could masquerade as
|
|||
|
a legitimate user, or could compromise the integrity of a message
|
|||
|
by altering it. That is, secrecy does not imply authenticity/
|
|||
|
integrity.
|
|||
|
|
|||
|
|
|||
|
1.2 Requirements for authenticity and integrity.
|
|||
|
|
|||
|
|
|||
|
Authenticity requires that an intruder should not be able to
|
|||
|
masquerade as a legitimate user of a system. Integrity requires
|
|||
|
that an intruder should not be able to substitute false ciphertext
|
|||
|
for legitimate ciphertext. Two minimal requirements should be met
|
|||
|
for a cryptosystem to provide these services:
|
|||
|
|
|||
|
|
|||
|
a. It should be possible for the recipient of a message to
|
|||
|
ascertain its origin.
|
|||
|
|
|||
|
b. It should be possible for the recipient of a message to
|
|||
|
verify that it has not been modified in transit.
|
|||
|
|
|||
|
|
|||
|
These requirements are independent of secrecy. For example, a
|
|||
|
message M could be encoded by using D instead of E. Then assuming
|
|||
|
D is secret, the recipient of C = D(M) is assured that this message
|
|||
|
was not generated by an intruder. However, E might be public; C
|
|||
|
could then be decoded by anyone intercepting it.
|
|||
|
|
|||
|
A related service which may be provided is nonrepudiation; i.e.,
|
|||
|
we may add a third requirement if desired:
|
|||
|
|
|||
|
|
|||
|
c. A sender should not be able to deny later that he sent a
|
|||
|
message.
|
|||
|
|
|||
|
|
|||
|
We might also wish to add:
|
|||
|
|
|||
|
|
|||
|
d. It should be possible for the recipient of a message to
|
|||
|
detect whether it is a replay of a previous transmission.
|
|||
|
|
|||
|
|
|||
|
1.3 Conventional systems.
|
|||
|
|
|||
|
|
|||
|
In a conventional cryptosystem, E and D are parameterized by a
|
|||
|
single key K, so that we have DK(EK(M)) = M. It is often the case
|
|||
|
that the algorithms for obtaining DK and EK from K are public,
|
|||
|
although both EK and DK are secret. In this event the security of
|
|||
|
a conventional system depends entirely on keeping K a secret. Then
|
|||
|
secrecy and authenticity are both provided: if two parties share
|
|||
|
a secret K, they can send messages to one another which are both
|
|||
|
private (since an eavesdropper cannot compute DK(C)) and
|
|||
|
authenticated (since a would-be masquerader cannot compute EK(M)).
|
|||
|
In some cases (e.g., transmission of a random bit string), this
|
|||
|
does not assure integrity; i.e., modification of a message en route
|
|||
|
may be undetected. Typically integrity is provided by sending a
|
|||
|
compressed form of the message (a message digest) along with the
|
|||
|
full message as a check.
|
|||
|
|
|||
|
Conventional systems are also known as one-key or symmetric
|
|||
|
systems [SIMM79].
|
|||
|
|
|||
|
|
|||
|
1.4 Example of a conventional cipher: DES.
|
|||
|
|
|||
|
|
|||
|
The most notable example of a conventional cryptosystem is DES
|
|||
|
(Data Encryption Standard). It is well-documented (e.g.
|
|||
|
[DENN83],[EHRS78],[NATI77],[NATI80],[NATI81],[SMID81],[SMID88b])
|
|||
|
and will not be discussed in detail here, except to contrast it
|
|||
|
with other ciphers. It is a block cipher, operating on 64-bit
|
|||
|
blocks using a 56-bit key. Essentially the same algorithm is used
|
|||
|
to encipher or decipher. The transformation employed can be written
|
|||
|
P-1(F(P(M))), where P is a certain permutation and F is a certain
|
|||
|
function which combines permutation and substitution. Substitution
|
|||
|
is accomplished via table lookups in so-called S-boxes.
|
|||
|
|
|||
|
The important characteristics of DES from the standpoint of this
|
|||
|
exposition are its one-key feature and the nature of the operations
|
|||
|
performed during encryption/decryption. Both permutations and table
|
|||
|
lookups are easily implemented, especially in hardware. Thus
|
|||
|
encryption rates exceeding 40 Mbit/sec have been obtained (e.g.,
|
|||
|
[BANE82],[MACM81]). This makes DES an efficient bulk encryptor,
|
|||
|
especially when implemented in hardware.
|
|||
|
|
|||
|
The security of DES is produced in classical fashion:
|
|||
|
alternation of substitutions and permutations. The function F is
|
|||
|
obtained by cascading a certain function f(x,y), where x is 32 bits
|
|||
|
and y is 48 bits. Each stage of the cascade is called a round. A
|
|||
|
sequence of 48-bit strings {Ki} is generated from the key. Let L(x)
|
|||
|
and R(x) denote the left and right halves of x, and let XOR denote
|
|||
|
exclusive-or. Then if Mi denotes the output of stage i, we have
|
|||
|
|
|||
|
|
|||
|
L(Mi) = R(Mi-1),
|
|||
|
|
|||
|
R(Mi) = L(Mi-1) XOR f(L(Mi),Ki).
|
|||
|
|
|||
|
|
|||
|
The hope is that after 16 rounds, the output will be
|
|||
|
statistically flat; i.e., all patterns in the initial data will be
|
|||
|
undetectable.
|
|||
|
|
|||
|
|
|||
|
1.5 Another conventional cipher: exponentiation.
|
|||
|
|
|||
|
|
|||
|
Pohlig and Hellman [POHL78] noted a type of cipher which
|
|||
|
deviated from the classical methods such as transposition and
|
|||
|
substitution. Their technique was conceptually much simpler. Let
|
|||
|
GCD denote greatest common divisor (app. G). Suppose p > 2 is
|
|||
|
a prime and suppose K is a key in [1,p-1) with GCD(K,p-1) = 1
|
|||
|
(i.e., K is relatively prime to p-1). If M is plaintext in [1,p-
|
|||
|
1], an encryption function E may be defined by
|
|||
|
|
|||
|
|
|||
|
E(M) = MK mod p.
|
|||
|
|
|||
|
|
|||
|
Now the condition GCD(K,p-1) = 1 implies (lem. G.1) that we can
|
|||
|
find I with I * K <20> 1 (mod p-1). Note that I is not a separate key;
|
|||
|
I is easily derived from K or vice-versa (app. H). We may set
|
|||
|
|
|||
|
|
|||
|
D(C) = CI mod p.
|
|||
|
|
|||
|
|
|||
|
It may then be shown (cor. G.2.3) that D(E(M)) = M, as required.
|
|||
|
Furthermore, E(D(C)) = C as well; i.e., E and D are inverse
|
|||
|
functions. This makes exponentiation a versatile cipher; in
|
|||
|
particular, we can encipher with D as well as E. Later we will note
|
|||
|
that this can be useful in authentication. However, Pohlig and
|
|||
|
Hellman used the above only as an example of a conventional
|
|||
|
cryptosystem. That is, since I is easily derived from K, both E and
|
|||
|
D are generated by the single, secret, shared key K. In section 4.1
|
|||
|
we will see that if p were replaced by a product of two primes,
|
|||
|
derivation of I from K would be non-trivial. This would cause the
|
|||
|
key material to be split into two portions.
|
|||
|
|
|||
|
Despite the relative simplicity of the definitions of E and D,
|
|||
|
they are not as easy to compute as their counterparts in DES. This
|
|||
|
is because exponentiation mod p is a more time-consuming operation
|
|||
|
than permutations or table lookups if p is large.
|
|||
|
|
|||
|
Security of the system in fact requires that p be large. This
|
|||
|
is because K should be nondeterminable even in the event of a
|
|||
|
known-plaintext attack. Suppose a cryptanalyst knows p, M, C, and
|
|||
|
furthermore knows that C = MK mod p for some K. He should still be
|
|||
|
unable to find K; i.e., he should not be able to compute discrete
|
|||
|
logarithms modulo p. At present there are no efficient algorithms
|
|||
|
for the latter operation: the best techniques now available take
|
|||
|
time (e.g., [ADLE79],[COPP86])
|
|||
|
|
|||
|
|
|||
|
exp(c((log p)(log log p))1/2).
|
|||
|
|
|||
|
|
|||
|
Computing modulo p is equivalent to using the Galois field
|
|||
|
GF(p); it is possible to use GF(pn) instead (app. G). There are
|
|||
|
both advantages and disadvantages to the extension. Arithmetic in
|
|||
|
GF(pn) is generally easier if n > 1, and especially so in GF(2n).
|
|||
|
On the other hand, taking discrete logarithms in GF(pn) is also
|
|||
|
easier. The case of small n is treated in [ELGA85b]. The greatest
|
|||
|
progress has been made for the case p = 2 (e.g.,
|
|||
|
[BLAK84],[COPP84]). In [COPP84] it is shown that discrete
|
|||
|
logarithms in GF(2n) can be computed in time
|
|||
|
|
|||
|
|
|||
|
exp(c * n1/3 * (log n)2/3).
|
|||
|
|
|||
|
|
|||
|
For a survey of the discrete logarithm problem see, e.g.,
|
|||
|
[ADLE86],[COPP87],[MCCU89],[ODLY84b].
|
|||
|
|
|||
|
|
|||
|
1.6 Public-key cryptosystems.
|
|||
|
|
|||
|
|
|||
|
The notion of public-key cryptography was introduced by Diffie
|
|||
|
and Hellman [DIFF76b]; for a history see [DIFF88]. Public-key
|
|||
|
systems, also called two-key or asymmetric [SIMM79], differ from
|
|||
|
conventional systems in that there is no longer a single secret key
|
|||
|
shared by a pair of users. Rather, each user has his own key
|
|||
|
material. Furthermore, the key material of each user is divided
|
|||
|
into two portions, a private component and a public component. The
|
|||
|
public component generates a public transformation E, and the
|
|||
|
private component generates a private transformation D. In analogy
|
|||
|
to the conventional case E and D might be termed encryption and
|
|||
|
decryption functions, respectively. However, this is imprecise: in
|
|||
|
a given system we may have D(E(M)) = M, E(D(M)) = M, or both.
|
|||
|
|
|||
|
A requirement is that E must be a trapdoor one-way function.
|
|||
|
One-way refers to the fact that E should be easy to compute from
|
|||
|
the public key material but hard to invert unless one possesses the
|
|||
|
corresponding D, or equivalently, the private key material
|
|||
|
generating D. The private component thus yields a "trapdoor" which
|
|||
|
makes the problem of inverting E seem difficult from the point of
|
|||
|
view of the cryptanalyst, but easy for the (sole legitimate)
|
|||
|
possessor of D. For example, a trapdoor may be the knowledge of the
|
|||
|
factorization of an integer (see sec. 4.1).
|
|||
|
|
|||
|
We remark that the trapdoor functions employed as public
|
|||
|
transformations in public-key systems are only a subclass of the
|
|||
|
class of one-way functions. The more general case will be discussed
|
|||
|
in section 3.2.2.
|
|||
|
|
|||
|
We note also that public/private dichotomy of E and D in public-
|
|||
|
key systems has no analogue in a conventional cryptosystem: in the
|
|||
|
latter, both EK and DK are parameterized by a single key K. Hence
|
|||
|
if EK is known then it may be assumed that K has been compromised,
|
|||
|
whence it may also be assumed that DK is also known, or vice-
|
|||
|
versa. For example, in DES, both E and D are computed by
|
|||
|
essentially the same public algorithm from a common key; so E and
|
|||
|
D are both known or both unknown, depending on whether the key has
|
|||
|
been compromised.
|
|||
|
|
|||
|
|
|||
|
1.6.1 Secrecy and authenticity.
|
|||
|
|
|||
|
|
|||
|
To support secrecy, the transformations of a public-key system
|
|||
|
must satisfy D(E(M)) = M. Suppose A wishes to send a secure message
|
|||
|
M to B. Then A must have access to EB, the public transformation of
|
|||
|
B (note that subscripts refer to users rather than keys in this
|
|||
|
context). Now A encrypts M via C = EB(M) and sends C to B. On
|
|||
|
receipt, B employs his private transformation DB for decryption;
|
|||
|
i.e., B computes DB(C) = DB(EB(M)) = M. If A's transmission is
|
|||
|
overheard, the intruder cannot decrypt C since DB is private. Thus
|
|||
|
secrecy is ensured. However, presumably anyone can access EB; B has
|
|||
|
no way of knowing the identity of the sender per se. Also, A's
|
|||
|
transmission could have been altered. Thus authenticity and
|
|||
|
integrity are not assured.
|
|||
|
|
|||
|
To support authentication/integrity, the transformations in a
|
|||
|
public-key system must satisfy E(D(M)) = M. Suppose A wishes to
|
|||
|
send an authenticated message M to B. That is, B is to be able to
|
|||
|
verify that the message was sent by A and was not altered. In this
|
|||
|
case A could use his private transformation DA to compute C = DA(M)
|
|||
|
and send C to B. Now B can use A's public transformation EA to find
|
|||
|
EA(C) = EA(DA(M)) = M. Assuming M is valid plaintext, B knows that
|
|||
|
C was in fact sent by A, and was not altered in transit. This
|
|||
|
follows from the one-way nature of EA: if a cryptanalyst, starting
|
|||
|
with a message M, could find C' such that EA(C') = M, this would
|
|||
|
imply that he can invert EA, a contradiction.
|
|||
|
|
|||
|
If M, or any portion of M, is a random string, then it may be
|
|||
|
difficult for B to ascertain that C is authentic and unaltered
|
|||
|
merely by examining EA(C). Actually, however, a slightly more
|
|||
|
complex procedure is generally employed: an auxiliary public
|
|||
|
function H is used to produce a digital signature S = DA(H(M))
|
|||
|
which A sends to B along with M. On receipt B can compute H(M)
|
|||
|
directly. The latter may be checked against EA(S) to ensure
|
|||
|
authenticity and integrity, since once again the ability of a
|
|||
|
cryptanalyst to find a valid S' for a given M would violate the
|
|||
|
one-way nature of EA. Actually H must also be one-way; we return to
|
|||
|
this subject in section 3.2.
|
|||
|
|
|||
|
Sending C or S above ensures authenticity, but secrecy is
|
|||
|
nonexistent. In the second scheme M was sent in the clear along
|
|||
|
with S; in the first scheme, an intruder who intercepts C = DA(M)
|
|||
|
presumably has access to EA and hence can compute M = EA(C). Thus
|
|||
|
in either case M is accessible to an eavesdropper.
|
|||
|
|
|||
|
It may be necessary to use a combination of systems to provide
|
|||
|
secrecy, authenticity and integrity. However, in some cases it is
|
|||
|
possible to employ the same public-key system for these services
|
|||
|
simultaneously. We note that for authenticity/integrity purposes,
|
|||
|
D is applied to M or H(M); for secrecy, E is applied to M. If the
|
|||
|
same public-key system is to be used in both cases, then D(E(M))
|
|||
|
= M and E(D(M)) = M must both hold; i.e., D and E are inverse
|
|||
|
functions. A requirement is that the plaintext space (i.e., the
|
|||
|
domain of E) must be the same as the ciphertext space (i.e., the
|
|||
|
domain of D).
|
|||
|
|
|||
|
Suppose that in addition to E and D being inverses for each
|
|||
|
user, for each pair of users A and B the functions EA, DA, EB, and
|
|||
|
DB all have a common domain. Then both secrecy and authenticity can
|
|||
|
be accomplished with a single transmission: A sends C = EB(DA(M))
|
|||
|
to B; then B computes EA(DB(C)) = EA(DA(M)) = M. An intruder cannot
|
|||
|
decrypt C since he lacks DB; hence secrecy is assured. If the
|
|||
|
intruder sends C' instead of C, C' cannot produce a valid M since
|
|||
|
DA is needed to produce a valid C. This assures authenticity.
|
|||
|
|
|||
|
In actuality there are no common systems versatile enough for
|
|||
|
the last usage without modification. In fact there is only one
|
|||
|
major system (RSA) which satisfies E(D(M)) = D(E(M)) = M. The lack
|
|||
|
of a common domain between two users creates a technical problem
|
|||
|
in using such a system for secrecy and authenticity. We discuss
|
|||
|
some approaches to this problem in section 4.1.
|
|||
|
|
|||
|
If the question of domains is ignored, the usage of a system
|
|||
|
satisfying E(D(M)) = D(E(M)) = M with a hash function H is
|
|||
|
illustrated below. There EA,DA,EB,DB are the public transformations
|
|||
|
of A and B, respectively.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
A: B:
|
|||
|
____________________ _________________
|
|||
|
| | _____\| |
|
|||
|
| compute H(M) | /|\ /| receive (C,S) |
|
|||
|
|____________________| | |_________________|
|
|||
|
| | |
|
|||
|
| | |
|
|||
|
________\|/_________ | _________\|/_________
|
|||
|
| | | | |
|
|||
|
| compute C = EB(M) | | | compute M' = DB(C) |
|
|||
|
|____________________| | |_____________________|
|
|||
|
| | |
|
|||
|
| | |
|
|||
|
_________\|/__________ | _________\|/_________
|
|||
|
| | | | |
|
|||
|
| compute S = DA(H(M)) | | | compute H' = EA(S) |
|
|||
|
|______________________| | |_____________________|
|
|||
|
| | |
|
|||
|
| | |
|
|||
|
________\|/_________ | _________\|/_________
|
|||
|
| | | | |
|
|||
|
| send (C,S) to B | | | verify H' = H(M') |
|
|||
|
|____________________| | |_____________________|
|
|||
|
| |
|
|||
|
| |
|
|||
|
\|/________________\|
|
|||
|
/
|
|||
|
|
|||
|
|
|||
|
Figure 2. Using Public-Key for Secrecy and Authenticity
|
|||
|
|
|||
|
|
|||
|
1.6.2 Applicability and limitations.
|
|||
|
|
|||
|
|
|||
|
The range of applicability of public-key systems is limited in
|
|||
|
practice by the relatively low bandwidths associated with public-
|
|||
|
key ciphers, compared to their conventional counterparts. It has
|
|||
|
not been proven that time or space complexity must necessarily be
|
|||
|
greater for public key systems than for conventional systems.
|
|||
|
However, the public-key systems which have withstood cryptanalytic
|
|||
|
attacks are all characterized by relatively low efficiency. For
|
|||
|
example, some are based on modular exponentiation, a relatively
|
|||
|
slow operation. Others are characterized by high data expansion
|
|||
|
(ciphertext much larger than plaintext). This inefficiency, under
|
|||
|
the conservative assumption that it is in fact inherent, seems to
|
|||
|
preclude the use of public-key systems as replacements for
|
|||
|
conventional systems utilizing fast encryption techniques such as
|
|||
|
permutations and substitutions. That is, using public-key systems
|
|||
|
for bulk data encryption is not feasible, at least for the present.
|
|||
|
|
|||
|
On the other hand, there are two major application areas for
|
|||
|
public-key cryptosystems:
|
|||
|
|
|||
|
|
|||
|
a. Distribution of secret keys.
|
|||
|
|
|||
|
b. Digital signatures.
|
|||
|
|
|||
|
|
|||
|
The first involves using public-key systems for secure and
|
|||
|
authenticated exchange of data-encrypting keys between two parties
|
|||
|
(sec. 2). Data-encrypting keys are secret shared keys connected
|
|||
|
with a conventional system used for bulk data encryption. This
|
|||
|
permits users to establish common keys for use with a system such
|
|||
|
as DES. Classically, users have had to rely on a mechanism such as
|
|||
|
a courier service or a central authority for assistance in the key
|
|||
|
exchange process. Use of a public-key system permits users to
|
|||
|
establish a common key which does not need to be generated by or
|
|||
|
revealed to any third party, providing both enhanced security and
|
|||
|
greater convenience and robustness.
|
|||
|
|
|||
|
Digital signatures are a second major application (sec. 3). They
|
|||
|
provide authentication, nonrepudiation and integrity checks. As
|
|||
|
noted earlier, in some settings authentication is a major
|
|||
|
consideration; in some cases it is desirable even when secrecy is
|
|||
|
not a consideration (e.g., [SIMM88]). We have already seen an
|
|||
|
example of a digital signature, i.e., when A sent DA(M) to B. This
|
|||
|
permitted B to conclude that A did indeed send the message. As we
|
|||
|
will note in section 3, nonrepudiation is another property
|
|||
|
desirable for digital signatures. Public key cryptosystems provide
|
|||
|
this property as well.
|
|||
|
|
|||
|
No bulk encryption is needed when public-key cryptography is
|
|||
|
used to distribute keys, since the latter are generally short.
|
|||
|
Also, digital signatures are generally applied only to outputs of
|
|||
|
hash functions (sec. 3). In both cases the data to be encrypted or
|
|||
|
decrypted is restricted in size. Thus the bandwidth limitation of
|
|||
|
public-key is not a major restriction for either application.
|
|||
|
|
|||
|
|
|||
|
2. Key management.
|
|||
|
|
|||
|
|
|||
|
Regardless of whether a conventional or public-key cryptosystem
|
|||
|
is used, it is necessary for users to obtain other users' keys. In
|
|||
|
a sense this creates a circular problem: in order to communicate
|
|||
|
securely over insecure channels, users must first exchange key
|
|||
|
information. If no alternative to the insecure channel exists, then
|
|||
|
secure exchange of key information presents essentially the same
|
|||
|
security problem as subsequent secure communication.
|
|||
|
|
|||
|
In conventional cryptosystems this circle can be broken in
|
|||
|
several ways. For example, it might be assumed that two users can
|
|||
|
communicate over a supplementary secure channel, such as a courier
|
|||
|
service. In this case it is often the case that the secure channel
|
|||
|
is costly, inconvenient, low-bandwidth and slow; furthermore, use
|
|||
|
of a courier cannot be considered truly secure. An alternative is
|
|||
|
for the two users to exchange key information via a central
|
|||
|
authority. This presumes that each user individually has
|
|||
|
established a means of communicating securely with the central
|
|||
|
authority. Use of a central authority has several disadvantages as
|
|||
|
noted below.
|
|||
|
|
|||
|
In public-key systems the key management problem is simpler
|
|||
|
because of the public nature of the key material exchanged between
|
|||
|
users, or between a user and a central authority. Also,
|
|||
|
alternatives to the insecure channel may be simpler; e.g., a
|
|||
|
physical mail system might suffice, particularly if redundant
|
|||
|
information is sent via the insecure (electronic) channel.
|
|||
|
|
|||
|
|
|||
|
2.1 Secret-key management.
|
|||
|
|
|||
|
|
|||
|
In a conventional (one-key) system, security is dependent on the
|
|||
|
secrecy of the key which is shared by two users. Thus two users who
|
|||
|
wish to communicate securely must first securely establish a common
|
|||
|
key. As noted above, one possibility is to employ a third party
|
|||
|
such as a courier; but as remarked there are various disadvantages
|
|||
|
to this implementation. The latter is the case even for a single
|
|||
|
key exchange. In practice, it may be necessary to establish a new
|
|||
|
key from time to time for security reasons. This may make use of
|
|||
|
a courier or similar scheme costly and inefficient.
|
|||
|
|
|||
|
An alternative is for the two users to obtain a common key from
|
|||
|
a central issuing authority [BRAN75]. Security is then a major
|
|||
|
consideration: a central authority having access to keys is
|
|||
|
vulnerable to penetration. Due to the concentration of trust, a
|
|||
|
single security breach would compromise the entire system. In
|
|||
|
particular, a central authority could engage in passive
|
|||
|
eavesdropping for a long period of time before the practice was
|
|||
|
discovered; even then it might be difficult to prove.
|
|||
|
|
|||
|
A second disadvantage of a central issuing authority is that it
|
|||
|
would probably need to be on-line. In large networks it might also
|
|||
|
become a bottleneck, since each pair of users needing a key must
|
|||
|
access a central node at least once. If the number of users is n
|
|||
|
then the number of pairs of users wishing to communicate could
|
|||
|
theoretically be as high as n(n-1)/2, although this would be highly
|
|||
|
unlikely in large networks. Each time a new key is needed, at least
|
|||
|
two communications involving the central authority are needed for
|
|||
|
each pair of users. Furthermore, such a system may not be robust:
|
|||
|
failure of the central authority could disrupt the key distribution
|
|||
|
system.
|
|||
|
|
|||
|
Some of the disadvantages of a central authority can be
|
|||
|
mitigated by distributing key distribution via a network of issuing
|
|||
|
authorities. One possibility is a hierarchical (tree-structured)
|
|||
|
system, with users at the leaves and key distribution centers at
|
|||
|
intermediate nodes. However, distributing key management creates
|
|||
|
a new security problem, since a multiplicity of entry points for
|
|||
|
intruders is created. Furthermore, such a modification might be
|
|||
|
inefficient unless pairs of users communicating frequently were
|
|||
|
associated to a common subtree; otherwise the root of the tree
|
|||
|
would be a bottleneck as before.
|
|||
|
|
|||
|
Another alternative is a key translation center which requires
|
|||
|
only one key-encrypting key exchange through a certification
|
|||
|
authority.
|
|||
|
|
|||
|
Some of these disadvantages can also be mitigated by a public-
|
|||
|
key approach to key distribution.
|
|||
|
|
|||
|
|
|||
|
2.2 Public distribution of secret keys.
|
|||
|
|
|||
|
|
|||
|
It was noted by Diffie and Hellman [DIFF76b] and Merkle [MERK78]
|
|||
|
that users can publicly exchange secret keys. This is not related
|
|||
|
a priori to public-key cryptography; however, a public-key system
|
|||
|
can be used to implement public distribution of secret keys (often
|
|||
|
referred to as public key distribution). The underlying public-
|
|||
|
key system must support secrecy, for use in key encryption.
|
|||
|
|
|||
|
The notion of public distribution of secret keys was originated
|
|||
|
in 1974 by Merkle, who proposed a "puzzle" system to implement it
|
|||
|
[MERK78]. However, even before this work was published it was
|
|||
|
superseded by a public-key scheme supporting public key
|
|||
|
distribution [DIFF76b]. This has come to be known as the
|
|||
|
Diffie/Hellman exponential key exchange. To begin with, users A and
|
|||
|
B are assumed to have agreed upon a common prime p and a common
|
|||
|
primitive root g modulo p (app. K). Then (lem. K.2) each number in
|
|||
|
[1,p) can be expressed as gx mod p for some x. Both p and g may be
|
|||
|
public.
|
|||
|
|
|||
|
To establish a common secret key, A chooses a random x(A) in
|
|||
|
[0,p-1] and B chooses a random x(B) in [0,p-1]; these are kept
|
|||
|
secret. Then A computes
|
|||
|
|
|||
|
|
|||
|
y(A) = gx(A) mod p
|
|||
|
|
|||
|
|
|||
|
while B computes
|
|||
|
|
|||
|
|
|||
|
y(B) = gx(B) mod p.
|
|||
|
|
|||
|
|
|||
|
These need not be secret. Finally A sends y(A) to B and B sends
|
|||
|
y(B) to A. Now A knows x(A) and y(B) and can compute
|
|||
|
|
|||
|
|
|||
|
K = y(B)x(A) mod p = gx(B)x(A).
|
|||
|
|
|||
|
|
|||
|
Similarly, B knows x(B) and y(A) and can compute
|
|||
|
|
|||
|
|
|||
|
K = y(A)x(B) mod p = gx(A)x(B).
|
|||
|
|
|||
|
|
|||
|
The Diffie/Hellman algorithm is illustrated below.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
A: B:
|
|||
|
_______________ _______________
|
|||
|
| | | |
|
|||
|
| choose xA | | choose xB |
|
|||
|
|_______________| |_______________|
|
|||
|
| |
|
|||
|
| |
|
|||
|
________\|/_________ ________\|/_________
|
|||
|
| | | |
|
|||
|
| compute yA = g**xA | | compute yB = g**xB |
|
|||
|
|____________________| |____________________|
|
|||
|
| |
|
|||
|
| |
|
|||
|
_______\|/________ ________\|/_________
|
|||
|
| | | |
|
|||
|
| send yA to B |------------->| receive yA from A |
|
|||
|
|__________________| |____________________|
|
|||
|
| |
|
|||
|
| |
|
|||
|
________\|/________ ________\|/_________
|
|||
|
| | | |
|
|||
|
| receive yB from B |<-------------| send yB to A |
|
|||
|
|___________________| |____________________|
|
|||
|
| |
|
|||
|
| |
|
|||
|
________\|/_________ ________\|/_________
|
|||
|
| | | |
|
|||
|
| compute K = yB**xA | | compute K = yA**xB |
|
|||
|
|____________________| |____________________|
|
|||
|
|
|||
|
|
|||
|
Figure 3. The Diffie/Hellman Key Exchange
|
|||
|
|
|||
|
|
|||
|
This establishes K as a secret common quantity which can be used
|
|||
|
in some agreed-upon fashion to generate a secret key. The secrecy
|
|||
|
of this scheme depends, as in section 1.5, on the difficulty of
|
|||
|
computing discrete logarithms. That is, knowing p, g, y and the
|
|||
|
fact that y = gx mod p for some x does not yield x. Thus, if an
|
|||
|
intruder knows p and g and intercepts y(A) or y(B) or both, he
|
|||
|
cannot find x(A) or x(B) and hence cannot compute K.
|
|||
|
|
|||
|
A disadvantage of this scheme is lack of support for
|
|||
|
authenticity. If an intruder C intercepts y(B), sends y(C) = gx(C)
|
|||
|
mod p to B and B thinks he is receiving y(A), B will inadvertently
|
|||
|
establish a secret key with C. That is, the underlying public-key
|
|||
|
cryptosystem supports secrecy but not authentication. Thus it may
|
|||
|
be desirable to augment a secrecy-providing system with one which
|
|||
|
provides authentication. Examples of the latter will be given
|
|||
|
later.
|
|||
|
|
|||
|
2.3 Management of public components in a public-key system.
|
|||
|
|
|||
|
|
|||
|
Prior to using a public-key cryptosystem for establishing secret
|
|||
|
keys, signing messages etc., users A and B must exchange their
|
|||
|
public transformations (EA and EB in sec. 1.6), or equivalently
|
|||
|
their public components. The latter may be regarded as a key
|
|||
|
management problem. It is a simpler problem than establishment of
|
|||
|
secret keys, since public components do not require secrecy in
|
|||
|
storage or transit. Public components can, e.g., be managed by an
|
|||
|
on-line or off-line directory service; they can also be exchanged
|
|||
|
directly by users. However, authenticity is an issue as in the
|
|||
|
previous section. If A thinks that EC is really EB then A might
|
|||
|
encrypt using EC and inadvertently allow C to decrypt using DC. A
|
|||
|
second problem is integrity: any error in transmission of a public
|
|||
|
component will render it useless. Hence some form of error
|
|||
|
detection is desirable.
|
|||
|
|
|||
|
Regardless of the scheme chosen for public component
|
|||
|
distribution, at some point a central authority is likely to be
|
|||
|
involved, as in conventional systems. However, it may not be
|
|||
|
necessary for the central authority to be on-line; exchange of
|
|||
|
public components between users need not involve the central
|
|||
|
authority. An example of how this can be implemented is given in
|
|||
|
section 2.5. We also note there that the implications of compromise
|
|||
|
of the central authority are not as severe as in the conventional
|
|||
|
case.
|
|||
|
|
|||
|
Validity is an additional consideration: a user's public
|
|||
|
component may be invalidated because of compromise of the
|
|||
|
corresponding private component, or for some other reason such as
|
|||
|
expiration. This creates a stale-data problem in the event that
|
|||
|
public components are cached or accessed through a directory.
|
|||
|
Similar problems have been encountered in management of multi-
|
|||
|
cache systems and distributed databases, and various solutions have
|
|||
|
been suggested. For example, users could be notified immediately
|
|||
|
of key compromises or invalidations. This may be impractical, in
|
|||
|
which case either users should be informed within a given time
|
|||
|
period of changes needed for cached information on public
|
|||
|
components, or users should periodically check with a central
|
|||
|
authority to update validity information.
|
|||
|
|
|||
|
|
|||
|
2.3.1 Use of certificates.
|
|||
|
|
|||
|
|
|||
|
A technique to gain a partial solution to both authenticity and
|
|||
|
integrity in distribution of public components is use of
|
|||
|
certificates [KOHN78]. A certificate-based system assumes a central
|
|||
|
issuing authority CA as in the secret-key case. Again it must be
|
|||
|
assumed that each user can communicate securely with the CA. This
|
|||
|
is relatively simple in the present instance: it merely requires
|
|||
|
that each user possess ECA, the public transformation of the CA.
|
|||
|
Then each user A may register EA with the CA. Since EA is public,
|
|||
|
this might be done via the postal service, an insecure electronic
|
|||
|
channel, a combination of these, etc.
|
|||
|
|
|||
|
Normally A will follow some form of authentication procedure in
|
|||
|
registering with the CA. Alternatively, registration can be handled
|
|||
|
by a tree-structured system: the CA issues certificates to local
|
|||
|
representatives (e.g., of employing organizations), who then act
|
|||
|
as intermediaries in the process of registering users at lower
|
|||
|
levels of the hierarchy. An example of such a system is given in
|
|||
|
section 5.4.
|
|||
|
|
|||
|
In any case, in return A receives a certificate signed by the
|
|||
|
CA (see sec. 3 for a more thorough discussion of signatures) and
|
|||
|
containing EA. That is, the CA constructs a message M containing EA,
|
|||
|
identification information for A, a validity period, etc. Then the
|
|||
|
CA computes CERTA = DCA(M) which becomes A's certificate. The latter
|
|||
|
is then a public document which both contains EA and authenticates
|
|||
|
it, since the certificate is signed by the CA. Certificates can be
|
|||
|
distributed by the CA or by users, or used in a hierarchical system
|
|||
|
which we return to later. The inclusion of the validity period is
|
|||
|
a generalization of timestamping. The latter was not treated in
|
|||
|
[KOHN78], but Denning [DENN81] notes the importance of timestamping
|
|||
|
in guarding against the use of compromised keys.
|
|||
|
|
|||
|
In general, the problem of stale data is not wholly solved by
|
|||
|
timestamping: a certificate may be invalidated before its
|
|||
|
expiration date, because of compromise or administrative reasons.
|
|||
|
Hence if certificates are cached by users (as opposed to being re-
|
|||
|
distributed by the CA each time they are used), the CA must
|
|||
|
periodically issue lists of invalidated certificates. Popek and
|
|||
|
Kline [POPE79] have noted that certificates are analogous to
|
|||
|
capabilities in operating systems. Management of certificates
|
|||
|
creates analogous problems, such as selective revocation of
|
|||
|
capabilities. The public nature of certificates, however, a priori
|
|||
|
precludes an analogue of a useful feature of a capability system:
|
|||
|
users cannot be restricted to communicating with a subset of other
|
|||
|
users. If a selective capability feature is desired it must be
|
|||
|
implemented through a controlled distribution of certificates,
|
|||
|
which would be difficult and contrary to the spirit of public-key.
|
|||
|
|
|||
|
|
|||
|
2.3.2 Generation and storage of component pairs.
|
|||
|
|
|||
|
|
|||
|
Generation of public/private component pairs is an important
|
|||
|
consideration. If this service is offered by a central facility,
|
|||
|
it may result in certain advantages; e.g., keys might be longer or
|
|||
|
chosen more carefully. However, this introduces the same problem
|
|||
|
noted in section 2.1: a central authority holding users' private
|
|||
|
components would be vulnerable to penetration. Also, the central
|
|||
|
facility would have to be trusted not to abuse its holdings by
|
|||
|
monitoring communications between users. Both problems are
|
|||
|
circumvented if users generate and store their own private/public
|
|||
|
components.
|
|||
|
|
|||
|
|
|||
|
2.3.3 Hardware support for key management.
|
|||
|
|
|||
|
|
|||
|
If users store their own components, a management problem is
|
|||
|
created. One possibility is software storage, e.g., in a file with
|
|||
|
read protection. If greater security is desired, a second option
|
|||
|
is hardware keys ([DENN79],[FLYN78],[RIVE78]).
|
|||
|
|
|||
|
In the classical version of this scheme, each public/private key
|
|||
|
pair is stored on a pair of ROM chips. The public key is revealed
|
|||
|
to the owner of the keys. However, the private key need not be
|
|||
|
known to any user, including the owner.
|
|||
|
|
|||
|
There are two advantages to this mode of storage, namely the
|
|||
|
fact that neither the user nor a central authority need know the
|
|||
|
private component. We have previously noted the advantage of not
|
|||
|
having users reveal private keys to a central authority. Also, as
|
|||
|
noted in [FLYN78], it may also be desirable to protect keys from
|
|||
|
disloyal employees. Entering keys from a keyboard rather than from
|
|||
|
ROM may be insecure; moreover, the large size of public keys makes
|
|||
|
this impractical. However, there is also an obvious disadvantage
|
|||
|
to the ROM mode of hardware key storage, namely the fact that the
|
|||
|
party which loads a private key to ROM could retain a copy. An
|
|||
|
alternative, but still classical, scheme is for the user to be
|
|||
|
provided with a means of writing to a memory chip and then sealing
|
|||
|
it from further writing.
|
|||
|
|
|||
|
A more modern and more secure hardware adjunct is a smart token,
|
|||
|
smart card or other device which contains both memory and a
|
|||
|
microprocessor. Such a device can both generate and store user
|
|||
|
keys. Ideally, it should be implemented via a single chip which
|
|||
|
stores both cryptographic algorithms and data.
|
|||
|
|
|||
|
In the classical case, encryption and decryption are handled by
|
|||
|
separate units in a hardware device acting as an interface between
|
|||
|
a user's computer and the network. As noted in [DENN79], this
|
|||
|
creates a security risk: an intruder may rig the device.
|
|||
|
|
|||
|
If a token or smart card is used, it is possible (at least in
|
|||
|
theory; the technology is still evolving at the time of this
|
|||
|
writing) to generate and store keys on the same device which
|
|||
|
executes encryption and decryption algorithms. Again, security is
|
|||
|
optimal if all of these functions are combined onto one or a
|
|||
|
minimal number of chips. Use of such auxiliary devices mitigates
|
|||
|
some of the problems encountered in the classical case. However,
|
|||
|
a token or smart card may be stolen, permitting the thief to
|
|||
|
masquerade as the user. Passwords (PINs) or biometrics used to
|
|||
|
control access to devices can substantially lessen this threat.
|
|||
|
|
|||
|
Capabilities such as signature generation should become feasible
|
|||
|
on devices such as smart cards in the near future. This will
|
|||
|
provide an excellent solution to the problem of using private
|
|||
|
components without exposing them.
|
|||
|
|
|||
|
|
|||
|
2.4 Using public-key systems for secret key distribution.
|
|||
|
|
|||
|
|
|||
|
As noted earlier, one of the major applications of public-key
|
|||
|
cryptosystems is in regard to public distribution of secret keys.
|
|||
|
Thus, a public-key system can be used in conjunction with a
|
|||
|
conventional system such as DES. We have already seen an example
|
|||
|
of a public-key cryptosystem implementing public key distribution
|
|||
|
in section 2.2. Both secrecy and authentication can be provided
|
|||
|
simultaneously in the distribution process via public-key systems.
|
|||
|
This may be achieved using a single public-key system if its
|
|||
|
encryption and decryption functions are inverses, or via a hybrid
|
|||
|
of two public key systems providing secrecy and authentication
|
|||
|
separately.
|
|||
|
|
|||
|
The essence of this usage is very simple: a secret key is merely
|
|||
|
a particular form of message. Assuming that a system has been
|
|||
|
established for distribution of public components of users as
|
|||
|
discussed in the previous section, users can then establish secret
|
|||
|
keys at will by employing the public system for encryption and
|
|||
|
signing of secret keys. Thus the latter can be exchanged or changed
|
|||
|
without difficulty. This is in contradistinction to a system in
|
|||
|
which secret keys must be established via couriers or a central
|
|||
|
authority.
|
|||
|
|
|||
|
The use of public-key cryptography thus reduces the problem of
|
|||
|
secret key distribution to the problem of binding user identities
|
|||
|
and user public keys. The latter is a simpler problem in that no
|
|||
|
communication of secret information is necessary. That is, users
|
|||
|
can generate their own private/public key pairs and need not expose
|
|||
|
their private keys to anyone, including themselves. However, it is
|
|||
|
critical that user public keys be properly authenticated. This is
|
|||
|
a nontrivial consideration in large networks.
|
|||
|
|
|||
|
Since only integrity and authenticity are considerations, users
|
|||
|
may be able to register their public components without use of a
|
|||
|
secure channel. In a large network this might require a distributed
|
|||
|
system of certifying authorities, arranged in hierarchical fashion.
|
|||
|
The feasibility of such an approach requires transitivity of trust.
|
|||
|
For example, a central certifying authority could certify a second
|
|||
|
level of certifying agents who in turn certify user public
|
|||
|
components. Other levels could be added as well. Thus a user is
|
|||
|
certified via an authentication path. Such a path need not require
|
|||
|
use of insecure channels if the nodes in the path can communicate
|
|||
|
securely. For example, a user might register with a local
|
|||
|
certifying authority in person. The local authority might be
|
|||
|
affiliated with an organization and may be able to use the user's
|
|||
|
organization ID to certify the user's public key. If the local
|
|||
|
authority can communicate securely with the central authority, the
|
|||
|
user's public key may then be forwarded to the central authority
|
|||
|
for distribution.
|
|||
|
|
|||
|
Assuming that user public components can be certified and
|
|||
|
distributed, two users may use each other's public components to
|
|||
|
establish common keys for use in message encryption, again without
|
|||
|
resort to a secure channel.
|
|||
|
|
|||
|
|
|||
|
2.4.1 A protocol for key exchange.
|
|||
|
|
|||
|
|
|||
|
Suppose A and B wish to establish a shared secret key. Suppose
|
|||
|
further that they have obtained each other's public components.
|
|||
|
Some possible modes for binding user public keys to user identities
|
|||
|
and distributing certified user public keys are discussed in
|
|||
|
sections 5.3.1 - 5.3.2 and 5.4.6. In any case, A may now generate
|
|||
|
a secret key K. For example, this may be a key-encrypting key to
|
|||
|
be used to exchange session keys and possibly initialization
|
|||
|
vectors if, e.g., DES is used in cipher feedback mode or cipher
|
|||
|
block-chaining mode [NATI80]. Then A might form an expanded message
|
|||
|
which contains K and other data, which could include an
|
|||
|
identification for A, a timestamp, a sequence number, a random
|
|||
|
number, etc. This added material is needed for A to authenticate
|
|||
|
himself to B in real-time, and thus prevent replays. For example,
|
|||
|
Needham and Schroeder [NEED78] suggest a three-way handshake
|
|||
|
protocol:
|
|||
|
|
|||
|
First of all A may send to B the message C = EB(RA,IDA), where EB
|
|||
|
is B's public transformation, IDA is the identification of A, and
|
|||
|
RA is a random number. Now B can decrypt C and obtain IDA. Now B
|
|||
|
generates a random number RB and sends C' = EA(RA,RB) to A. Upon
|
|||
|
decryption of C', A can verify in real time that B has received RA,
|
|||
|
since only B could decrypt C. Finally A sends C" = EB(RB) to B; when
|
|||
|
B decrypts C" he can verify in real time that A has received RB,
|
|||
|
since only A could decrypt C'. Thus A and B are authenticated to
|
|||
|
each other in real time; i.e., each knows that the other is really
|
|||
|
there.
|
|||
|
|
|||
|
Now A sends EB(DA(K)) to B, who can decrypt to obtain K. This
|
|||
|
ensures both secrecy and authenticity in exchange of K.
|
|||
|
|
|||
|
The authentication stage of the preceding protocol is
|
|||
|
illustrated below.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
A: B:
|
|||
|
__________________ ____________________
|
|||
|
| | ______\| |
|
|||
|
| choose RA | /|\ /| receive M from A |
|
|||
|
|__________________| | |____________________|
|
|||
|
| | |
|
|||
|
| | |
|
|||
|
___________\|/__________ | ___________\|/___________
|
|||
|
| | | |
|
|||
|
|
|
|||
|
| compute M = EB(RA,IA) | | | compute (RA,IA) = EA(M)
|
|||
|
|
|
|||
|
|________________________| | |_________________________|
|
|||
|
| | |
|
|||
|
| | |
|
|||
|
_________\|/_________ | _______\|/_______
|
|||
|
| | | | |
|
|||
|
| send M to B |______\| | choose RB |
|
|||
|
|_____________________| / |_________________|
|
|||
|
| |
|
|||
|
| |
|
|||
|
________\|/________ ___________\|/__________
|
|||
|
| | | |
|
|||
|
| receive M' from B |/_______ | compute M' = EA(RA,RB) |
|
|||
|
|___________________|\ /|\ |________________________|
|
|||
|
| | |
|
|||
|
| | |
|
|||
|
___________\|/____________ | ________\|/________
|
|||
|
| | | | |
|
|||
|
| compute (RA,RB) = DA(M') | |/______| send M' to A |
|
|||
|
|__________________________| \ |___________________|
|
|||
|
| |
|
|||
|
| |
|
|||
|
_______\|/______ ________\|/_________
|
|||
|
| | _____\| |
|
|||
|
| verify RA | /|\ /| receive M" from A |
|
|||
|
|________________| | |____________________|
|
|||
|
| | |
|
|||
|
| | |
|
|||
|
_________\|/_________ | _________\|/__________
|
|||
|
| | | | |
|
|||
|
| compute M" = EB(RB) | | | compute RB = DB(M") |
|
|||
|
|_____________________| | |______________________|
|
|||
|
| | |
|
|||
|
| | |
|
|||
|
_______\|/________ | ______\|/______
|
|||
|
| | | | |
|
|||
|
| send M" to B |________\| | verify RB |
|
|||
|
|__________________| / |_______________|
|
|||
|
|
|||
|
|
|||
|
Figure 4. A Protocol for Real-Time Authentication
|
|||
|
|
|||
|
|
|||
|
2.5 Protocols for certificate-based key management.
|
|||
|
|
|||
|
|
|||
|
There are a number of different approaches to public-key
|
|||
|
component management and the application to secret key distribution
|
|||
|
(e.g., [KLIN79],[NEED78]). For simplicity we assume a certificate-
|
|||
|
based system. We also assume that a system has been established for
|
|||
|
a central authority to create certificates.
|
|||
|
|
|||
|
|
|||
|
2.5.1 Certificate management by a central authority.
|
|||
|
|
|||
|
|
|||
|
In a certificate-based public-key system, one possibility is to
|
|||
|
have the central issuing authority manage certificate distribution.
|
|||
|
Suppose the authority CA has created certificates CERTA and CERTB
|
|||
|
for A and B, respectively. These contain EA and EB (or equivalently,
|
|||
|
the public components of A and B) as noted in section 2.3.1.
|
|||
|
|
|||
|
We may assume that A and B have cached CERTA and CERTB,
|
|||
|
respectively. If A has exchanged certificates with B previously,
|
|||
|
A and B may have each other's certificates cached. If not, then
|
|||
|
there are two ways in which A could obtain B's certificate. The
|
|||
|
simplest is for A to request B's certificate directly from B; this
|
|||
|
is explored in the next section. The advantage of this simple
|
|||
|
approach is that on-line access to a central authority is avoided.
|
|||
|
|
|||
|
On the other hand, if A requests B's certificate directly from
|
|||
|
B, or obtains it from a directory listing, security and integrity
|
|||
|
considerations arise. For example, the certificate A obtains may
|
|||
|
have been recently invalidated.
|
|||
|
|
|||
|
Thus A may wish to access B's certificate through the CA,
|
|||
|
assuming that the latter is on-line. In this event A requests CERTA
|
|||
|
and CERTB from S. We recall that each CERT has the form DS(M) where
|
|||
|
M contains an E. Thus when A receives the requested certificates,
|
|||
|
he can validate CERTA by computing ES(CERTA) and recovering EA. This
|
|||
|
validates the source of the certificates, thus validating CERTB as
|
|||
|
well. Hence A may retrieve a duly authenticated EB from CERTB. The
|
|||
|
disadvantage is the requirement of an on-line central node; the
|
|||
|
advantage is that A is assured of the instantaneous validity of the
|
|||
|
certificate. Later we will note that this has implications for
|
|||
|
nonrepudiation.
|
|||
|
|
|||
|
Caching of certificates implies that authentication involving
|
|||
|
the CA will not be done regularly. Thus the above procedure will
|
|||
|
only be necessary when two users first communicate, or when
|
|||
|
components are compromised or certificates invalidated. As long as
|
|||
|
the public components involved are valid, secret keys can be
|
|||
|
exchanged at will, although a handshake protocol may still be used
|
|||
|
to ensure real-time authenticity and integrity.
|
|||
|
|
|||
|
An advantage of this mode of key management is that the entire
|
|||
|
process is conducted over insecure channels with excellent
|
|||
|
security. A second advantage is that distribution of certificates
|
|||
|
by a central authority assures that certificates are valid at time
|
|||
|
of receipt. A prerequisite for the proper functioning of such a key
|
|||
|
management system is the existence of a system for binding user
|
|||
|
public keys and identities. Such a system requires distributed
|
|||
|
trust.
|
|||
|
|
|||
|
A disadvantage of this mode of management is that as in section
|
|||
|
2.1, the central authority may be a bottleneck. The severity is
|
|||
|
mitigated by the fact that a secure channel is not needed, but the
|
|||
|
essential problem is similar.
|
|||
|
|
|||
|
A more significant disadvantage arises from the concentration
|
|||
|
of trust in one entity [KLIN79]. The security of the central
|
|||
|
authority might be compromised, e.g., by penetration. The fact that
|
|||
|
the central authority does not generally access users' private
|
|||
|
components means that existing messages are not compromised, as
|
|||
|
might be the case in a secret-key system [DIFF82]. However, if an
|
|||
|
intruder accesses the central authority's private component, the
|
|||
|
intruder could forge certificates. Some scenarios for intrusions
|
|||
|
of this sort, explorations of consequences, and means for
|
|||
|
minimizing damage are explored in [DENN83b] and [DIFF88].
|
|||
|
|
|||
|
Merkle [MERK82b] has suggested a tree-structured system as a
|
|||
|
means of coping with the compromise of a central authority.
|
|||
|
However, this scheme is not practical for large networks since the
|
|||
|
tree must be restructured each time the user population changes.
|
|||
|
|
|||
|
|
|||
|
2.5.2 Decentralized management.
|
|||
|
|
|||
|
|
|||
|
Users may be responsible for managing their own certificates.
|
|||
|
In this event the protocol is much simpler. When A wishes to
|
|||
|
initiate communication (e.g., exchange of a secret key) with B, he
|
|||
|
sends a message to B containing A's certificate, A's
|
|||
|
identification, and other information such as a date, random number
|
|||
|
etc. as described in the protocol in the previous section. This
|
|||
|
message also requests B's certificate. Upon completion of the
|
|||
|
certificate exchange, employing some protocol such as the handshake
|
|||
|
above, A and B will possess each other's authenticated
|
|||
|
certificates. A can validate the certificate CB by computing ES(CB)
|
|||
|
as usual. Then EB may be retrieved. The certificate must contain
|
|||
|
information properly identifying B to A, so that an intruder cannot
|
|||
|
masquerade as B. The certificate must also have a validity period.
|
|||
|
In turn B may proceed similarly.
|
|||
|
|
|||
|
The central authority must periodically issue lists of
|
|||
|
certificates which have become invalid before their expiration
|
|||
|
dates due to key compromise or administrative reasons. It is likely
|
|||
|
that in a large system this would be done, e.g., on a monthly
|
|||
|
basis. Hence a user receiving a certificate from another user would
|
|||
|
not have complete assurance of its validity, even though it is
|
|||
|
signed by S. Thus this system trades higher efficiency for some
|
|||
|
security loss, compared to the previous scheme.
|
|||
|
|
|||
|
For greater assurance of validity, a user could access a
|
|||
|
centrally-managed list of invalid certificates; presumably these
|
|||
|
would be very current. This would require on-line access to a
|
|||
|
central facility, which would create the same type of bottleneck
|
|||
|
we have noted previously. However, the accesses would be very
|
|||
|
quick, since presumably only a certificate sequence number would
|
|||
|
be transmitted.
|
|||
|
|
|||
|
Yet another on-line possibility would be for the central
|
|||
|
authority to enforce coherence by a global search of cached
|
|||
|
certificates each time a certificate is invalidated. Again there
|
|||
|
is a trade-off of validity assurance and efficiency.
|
|||
|
|
|||
|
|
|||
|
2.5.3 A phone-book approach to certificates.
|
|||
|
|
|||
|
|
|||
|
Some of the features of the previous schemes could be combined
|
|||
|
in a phone-book approach, using an electronic equivalent such as
|
|||
|
a floppy disk containing certificates. This would optimize ease of
|
|||
|
use since a user could communicate securely with another by
|
|||
|
accessing the latter's certificate very rapidly. However, again the
|
|||
|
central authority would have to issue "hot lists". Periodic
|
|||
|
distribution of the compilations of certificates would be a
|
|||
|
separate management process.
|
|||
|
|
|||
|
|
|||
|
Security of such a scheme is clearly in question [KLIN79].
|
|||
|
Phone-book entries might contain errors, or entries could be
|
|||
|
altered.
|
|||
|
|
|||
|
|
|||
|
3. Digital signatures and hash functions.
|
|||
|
|
|||
|
|
|||
|
Digital signatures were introduced by Diffie and Hellman
|
|||
|
[DIFF76b]; for surveys see, e.g., [AKL-83],[POPE79],[RABI78]. A
|
|||
|
digital signature is the electronic analogue of a handwritten
|
|||
|
signature. A common feature is that they must provide the
|
|||
|
following:
|
|||
|
|
|||
|
|
|||
|
a. A receiver must be able to validate the sender's
|
|||
|
signature.
|
|||
|
|
|||
|
b. A signature must not be forgeable.
|
|||
|
|
|||
|
c. The sender of a signed message must not be able to
|
|||
|
repudiate it later.
|
|||
|
|
|||
|
|
|||
|
We have already seen an example of the usage of digital
|
|||
|
signatures, namely when a central authority signs certificates. In
|
|||
|
this section we are concerned with the signing of arbitrary
|
|||
|
messages.
|
|||
|
|
|||
|
A major difference between handwritten and digital signatures
|
|||
|
is that a digital signature cannot be a constant; it must be a
|
|||
|
function of the document which it signs. If this were not the case
|
|||
|
then a signature, due to its electronic nature, could be attached
|
|||
|
to any document. Furthermore, a signature must be a function of the
|
|||
|
entire document; changing even a single bit should produce a
|
|||
|
different signature. Thus a signed message cannot be altered.
|
|||
|
|
|||
|
There are two major variants of implementation:
|
|||
|
|
|||
|
|
|||
|
a. true signatures.
|
|||
|
|
|||
|
b. arbitrated signatures.
|
|||
|
|
|||
|
|
|||
|
In a true signature system, signed messages are forwarded
|
|||
|
directly from signer to recipient. In an arbitrated system, a
|
|||
|
witness (human or automated) validates a signature and transmits
|
|||
|
the message on behalf of the sender. The use of an arbitrator may
|
|||
|
be helpful in event of key compromise as noted below.
|
|||
|
|
|||
|
The notion of authentication by some form of signature can be
|
|||
|
traced back as far as 1952, as noted by Diffie [DIFF88].
|
|||
|
Cryptography was used by the Air Force to identify friendly
|
|||
|
aircraft through a challenge/response system. The protocols
|
|||
|
utilized influenced the development of public-key cryptography by
|
|||
|
Diffie and Hellman [DIFF76b].
|
|||
|
|
|||
|
As we note below, hash functions are useful auxiliaries in this
|
|||
|
context, i.e., in validating the identity of a sender. They can
|
|||
|
also serve as cryptographic checksums (i.e., error-detecting
|
|||
|
codes), thereby validating the contents of a message. Use of
|
|||
|
signatures and hash functions can thus provide authentication and
|
|||
|
verification of message integrity at the same time.
|
|||
|
|
|||
|
Numerous digital signature schemes have been proposed. As noted
|
|||
|
in [DAVI83], a major disadvantage of signature schemes in
|
|||
|
conventional systems is that they are generally one-time schemes.
|
|||
|
A signature is generated randomly for a specific message, typically
|
|||
|
using a large amount of key material, and is not re-usable.
|
|||
|
Furthermore, later resolution of disputes over signed documents
|
|||
|
requires written agreements and substantial bookkeeping on the part
|
|||
|
of the sender and receiver, making it more difficult for a third
|
|||
|
party to adjudicate. A conventional scheme was noted in [DIFF76b]
|
|||
|
(the Lamport/Diffie One-Time Signature) and is refined in [MERK82].
|
|||
|
Some other conventional schemes are DES-based.
|
|||
|
|
|||
|
Public-key schemes supporting authentication permit generation
|
|||
|
of signatures algorithmically from the same key repeatedly,
|
|||
|
although the actual signatures are of course different. That is,
|
|||
|
in a public-key scheme, signatures are a function of the message
|
|||
|
and a long-term key. Hence key material can be re-used many times
|
|||
|
before replacement. This obviates the necessity of special written
|
|||
|
agreements between individual senders and receivers. It also makes
|
|||
|
it easy for a third party to resolve disputes (e.g., involving
|
|||
|
repudiation) later, and simplifies storage and bookkeeping. As we
|
|||
|
note below, the bandwidth limitation of public-key systems is
|
|||
|
minimized by the use of hash functions as auxiliaries.
|
|||
|
|
|||
|
In passing we remark that Goldwasser, Micali and Rivest [GOLD88]
|
|||
|
have proposed a nondeterministic public-key signature scheme which
|
|||
|
incorporates an aspect of conventional schemes: a message does not
|
|||
|
have a unique signature. This scheme is intended to deflect
|
|||
|
adaptive chosen-text attacks, in which an attacker is permitted to
|
|||
|
use a signer as an oracle. In such an attack, the attacker
|
|||
|
specifies a sequence of messages to be signed, and is able to study
|
|||
|
all previous signatures before requesting the next. In the GMR
|
|||
|
scheme, it can be proved that an attacker can gain no information
|
|||
|
by studying any number of signatures no matter how they are
|
|||
|
generated.
|
|||
|
|
|||
|
However, this security gain is offset to some extent by data
|
|||
|
expansion (high ratio of signature to message size) and a negative
|
|||
|
effect on nonrepudiation. As in the case of the one-time schemes
|
|||
|
discussed earlier, the signatures generated in nondeterministic
|
|||
|
public-key schemes tend to be large in comparison to signatures
|
|||
|
produced by deterministic public-key schemes (i.e., those which
|
|||
|
produce a unique signature for a given message). Adjudication of
|
|||
|
disputes is made difficult by increased bookkeeping and the
|
|||
|
necessity of storing large databases of messages and their
|
|||
|
signatures.
|
|||
|
|
|||
|
In the following we discuss only deterministic public-key
|
|||
|
signature schemes, in which a message has a unique signature.
|
|||
|
|
|||
|
|
|||
|
3.1 Public-key implementation of signatures.
|
|||
|
|
|||
|
|
|||
|
We have noted previously that, like secret-key systems, public-
|
|||
|
key systems can be used for authentication. There are several
|
|||
|
distinctive features of a public-key implementation of signatures,
|
|||
|
including:
|
|||
|
|
|||
|
|
|||
|
a. The possibility of incorporating both secrecy and
|
|||
|
authenticity simultaneously, assuming that the system
|
|||
|
supports both services.
|
|||
|
|
|||
|
b. The re-use of key material in generating signatures
|
|||
|
algorithmically.
|
|||
|
|
|||
|
c. Nonrepudiation of sending is essentially a built-in
|
|||
|
service.
|
|||
|
|
|||
|
|
|||
|
These features make public-key implementation of signatures very
|
|||
|
efficient and versatile.
|
|||
|
|
|||
|
|
|||
|
3.1.1 Signing messages.
|
|||
|
|
|||
|
|
|||
|
There are several possible protocols for signing in public-key
|
|||
|
cryptography, depending on the services desired. In the simplest
|
|||
|
case, A simply signs a document M by sending S = DA(M) to B.
|
|||
|
|
|||
|
If a hash function H is used, A computes S = DA(H(M)) and sends
|
|||
|
both M and S to B. B validates A's signature S by computing H(M)
|
|||
|
= EA(S). We also noted earlier that because EA is a trapdoor one-
|
|||
|
way function, it should not be possible for an intruder to find S'
|
|||
|
such that H(M) = EA(S') for a given message M. Thus A's signature
|
|||
|
cannot be forged. Also, if A attempts to repudiate the M sent to
|
|||
|
B above, B may present M and S to a judge. The judge can access EA
|
|||
|
and hence can verify H(M) = EA(S); assuming the trapdoor DA is
|
|||
|
indeed secret, only A could have sent S. Thus a priori we have
|
|||
|
nonrepudiation (but see below).
|
|||
|
|
|||
|
For both authenticity and secrecy, A could send
|
|||
|
|
|||
|
|
|||
|
M' = EB(M,DA(H(M)))
|
|||
|
|
|||
|
|
|||
|
to B; B computes
|
|||
|
|
|||
|
|
|||
|
(M,DA(H(M))) = DB(M')
|
|||
|
|
|||
|
|
|||
|
and then verifies that
|
|||
|
|
|||
|
|
|||
|
H(M) = EA(DA(H(M))).
|
|||
|
|
|||
|
|
|||
|
The last protocol is illustrated below.
|
|||
|
|
|||
|
|
|||
|
A: B:
|
|||
|
____________________ ___________________
|
|||
|
| | ____\| |
|
|||
|
| compute H = H(M) | /|\ /| receive M' from A |
|
|||
|
|____________________| | |___________________|
|
|||
|
| | |
|
|||
|
| | |
|
|||
|
________\|/_________ | __________\|/___________
|
|||
|
| | | | |
|
|||
|
| compute S = DA(H) | | | compute (M,S) = DB(M') |
|
|||
|
|____________________| | |________________________|
|
|||
|
| | |
|
|||
|
| | |
|
|||
|
_________\|/__________ | _________\|/_________
|
|||
|
| | | | |
|
|||
|
| compute M' = EB(M,S) | | | compute H' = EA(S) |
|
|||
|
|______________________| | |_____________________|
|
|||
|
| | |
|
|||
|
| | |
|
|||
|
________\|/_________ | _________\|/_________
|
|||
|
| | | | |
|
|||
|
| send M' to B | | | verify H' = H(M) |
|
|||
|
|____________________| | |_____________________|
|
|||
|
| |
|
|||
|
| |
|
|||
|
\|/________________\|
|
|||
|
/
|
|||
|
|
|||
|
Figure 5. A Protocol for Signing with Hash Function and Secrecy
|
|||
|
|
|||
|
|
|||
|
For nonrepudiation in the last case, B retains DB(M') =
|
|||
|
(M,DA(H(M))). A judge can apply EA to DA(H(M)) and compare to H(M).
|
|||
|
This again assumes common domains for the E's and D's; in section
|
|||
|
4.1 we will note an example of how this point may be treated in
|
|||
|
practice. In passing we remark that the preceding schemes satisfy
|
|||
|
another desirable property: in the adjudication process, they do
|
|||
|
not compromise security by exposing private components to a judge.
|
|||
|
|
|||
|
|
|||
|
3.1.2 The issue of nonrepudiation.
|
|||
|
|
|||
|
|
|||
|
Nonrepudiation, i.e., preventing senders from denying they have
|
|||
|
sent messages, is contingent upon users keeping their private
|
|||
|
components secret (e.g., [NEED78],[POPE79]). In the above, if DA
|
|||
|
should be compromised, then A might be able to repudiate messages
|
|||
|
sent even before the compromise. On the other hand, as in the case
|
|||
|
of lost or stolen credit cards, A may still be held liable for
|
|||
|
messages signed before the compromise was reported to a central
|
|||
|
authority. This is an administrative issue, and ultimately a matter
|
|||
|
for litigation; hence it is beyond the scope of cryptography per
|
|||
|
se. However, some partial solutions have been proposed which can
|
|||
|
be incorporated into protocols. Most of these involve use of some
|
|||
|
form of arbitrator, as noted in [DEMI83].
|
|||
|
For example, in [POPE79], notary public machines are employed
|
|||
|
as arbitrators. A general protocol for usage of an arbitrator A
|
|||
|
when U is sending a message M to R is given in [AKL-83]:
|
|||
|
|
|||
|
|
|||
|
a. U computes S1 = ER(DU(M)).
|
|||
|
|
|||
|
b. U computes a header m = identifying information.
|
|||
|
|
|||
|
c. U computes S2 = DU(m,S1).
|
|||
|
|
|||
|
d. U sends m and S2 to A.
|
|||
|
|
|||
|
e. A applies EU to S2 and checks the identifying information
|
|||
|
in m, thereby verifying the origin of M.
|
|||
|
|
|||
|
f. A computes M' = (m,S1,timestamp).
|
|||
|
|
|||
|
g. A computes S' = DA(M').
|
|||
|
|
|||
|
h. A sends S' to R.
|
|||
|
|
|||
|
|
|||
|
As noted above, a copy of S' may also be sent to U.
|
|||
|
|
|||
|
As noted in [POPE78], this type of scheme violates a desirable
|
|||
|
criterion for network protocols, namely point-to-point
|
|||
|
communication. It also requires trusted software, which is
|
|||
|
undesirable.
|
|||
|
|
|||
|
In [BOOT81] the use of a central authority is suggested for this
|
|||
|
purpose. In this scheme, the receiver of a message sends a copy to
|
|||
|
the central authority. The latter can attest to the instantaneous
|
|||
|
validity of the sender's signature; i.e., that it has not been
|
|||
|
reported that the sender's private component has been compromised
|
|||
|
at the time of sending. The value of such testimony is mitigated
|
|||
|
by the necessity of users rapidly reporting key compromise to the
|
|||
|
central authority. Also, the central authority becomes a
|
|||
|
bottleneck.
|
|||
|
|
|||
|
Another partial solution involves timestamps ([DENN81],
|
|||
|
[MERK82b]). This again may involve a network of automated
|
|||
|
arbitrators, but very simple in nature, since they need merely
|
|||
|
timestamp messages. In contrast to the notary publics above,
|
|||
|
however, in [MERK82b] it is suggested that receivers obtain
|
|||
|
timestamps. If a receiver needs to be sure of the validity of a
|
|||
|
signature, he may check the validity of the sender's private
|
|||
|
component by checking with a central authority. As long as the
|
|||
|
received message is timestamped before the validity check, the
|
|||
|
receiver is assured of nonrepudiation. To be legally cohesive,
|
|||
|
however, this system requires the sender to be responsible for
|
|||
|
signing until a compromise of his private component is reported to
|
|||
|
the central authority. In analogy to lost credit cards, this may
|
|||
|
not be a desirable system. Also, it requires an on-line central
|
|||
|
authority and real-time validity checks and timestamps, which may
|
|||
|
again create bottlenecks. Furthermore, such schemes require a
|
|||
|
network-wide clock and are vulnerable to forgery of timestamps, as
|
|||
|
noted in [BOOT81].
|
|||
|
|
|||
|
If users are permitted to change their components, a central
|
|||
|
authority should retain past components for use in disputes which
|
|||
|
may arise later. Neither compromise nor change of components of a
|
|||
|
user should cause catastrophic problems in practice, since credit
|
|||
|
card systems have established precedents for protocols, both
|
|||
|
administrative and legal. For example, as noted above, conventions
|
|||
|
have been established for treatment of cases of lost or stolen
|
|||
|
credit cards; presumably analogous procedures could be established
|
|||
|
for component compromise.
|
|||
|
|
|||
|
|
|||
|
3.1.3 The issue of proof of delivery.
|
|||
|
|
|||
|
|
|||
|
The literature on public-key protocols concentrates on the
|
|||
|
issues of validity of signatures and the effects of key compromise
|
|||
|
on nonrepudiation. However, DeMillo and Merritt [DEMI83] note that
|
|||
|
the inverse of a signature, namely protection against the recipient
|
|||
|
of a message denying receipt, may also be a desired feature of a
|
|||
|
system. It is mentioned as an optional security service in [ISO-
|
|||
|
87].
|
|||
|
|
|||
|
Both nonrepudiation and proof of delivery must be implemented
|
|||
|
via adjudicable protocols, i.e., protocols which can be verified
|
|||
|
later by a third party. In [DEMI83] it is noted that nonarbitrated
|
|||
|
adjudicable reception protocols are difficult to design. A simple
|
|||
|
handshaking protocol might proceed as follows:
|
|||
|
|
|||
|
|
|||
|
a. A computes X = EB(DA(M)).
|
|||
|
|
|||
|
b. A sends X to B.
|
|||
|
|
|||
|
c. B computes M = EA(DB(X)).
|
|||
|
|
|||
|
d. B computes Y = EA(DB(M)).
|
|||
|
|
|||
|
e. B acknowledges receipt of M by sending Y to A.
|
|||
|
|
|||
|
|
|||
|
If this protocol is standard procedure then A can assume
|
|||
|
nonreception unless he receives acknowledgement from B. However,
|
|||
|
to serve as an adjudicable proof-of-reception protocol, B is
|
|||
|
required to acknowledge anything A sends. Then an intruder C could
|
|||
|
proceed as follows:
|
|||
|
|
|||
|
|
|||
|
a. C intercepts Y = EA(DB(M)).
|
|||
|
|
|||
|
b. C sends Y to A.
|
|||
|
|
|||
|
c. A thinks that this is a legitimate message from C,
|
|||
|
|
|||
|
unrelated to his communication with B. Following protocol:
|
|||
|
|
|||
|
c.1. A computes M' = EC(DA(Y)).
|
|||
|
|
|||
|
c.2. A computes Z = EC(DA(M')).
|
|||
|
|
|||
|
c.3. A acknowledges receipt of M' by sending Z to C.
|
|||
|
|
|||
|
d. C computes EB(DC(EA(DC(Z)))) = EB(DC(M')) = EB(DA(Y)) = M.
|
|||
|
|
|||
|
|
|||
|
This of course occurs because of step c, in which A is required
|
|||
|
by protocol to acknowledge M' = gibberish. This shows that such an
|
|||
|
automatic protocol may be undesirable. On the other hand, selective
|
|||
|
acknowledgement might have an adverse effect on adjudicability.
|
|||
|
|
|||
|
|
|||
|
3.2 Hash functions and message digests.
|
|||
|
|
|||
|
|
|||
|
We noted that public-key systems generally encrypt more slowly
|
|||
|
than conventional ciphers such as DES. Other digital signature
|
|||
|
schemes are also relatively slow in general. Furthermore, some
|
|||
|
schemes produce signatures comparable in size to, and in some cases
|
|||
|
larger than, the messages they sign. This results in data expansion
|
|||
|
and effectively lower bandwidth of transmission. Thus it is usually
|
|||
|
not desirable to apply a digital signature directly to a long
|
|||
|
message. On the other hand, we remarked that the entire message
|
|||
|
must be signed. This is seemingly contradictory, but a heuristic
|
|||
|
solution can be obtained by using a hash function as an
|
|||
|
intermediary.
|
|||
|
|
|||
|
A hash function H accepts a variable-size message M as input and
|
|||
|
outputs a fixed-size representation H(M) of M, sometimes called a
|
|||
|
message digest [DAVI80]. In general H(M) will be much smaller than
|
|||
|
M; e.g., H(M) might be 64 or 128 bits, whereas M might be a
|
|||
|
megabyte or more. A digital signature may be applied to H(M) in
|
|||
|
relatively quick fashion. That is, H(M) is signed rather than M.
|
|||
|
Both M and the signed H(M) may be encapsulated in another message
|
|||
|
which may then be encrypted for secrecy. The receiver may validate
|
|||
|
the signature on H(M) and then apply the public function H directly
|
|||
|
to M and check to see that it coincides with the forwarded signed
|
|||
|
version of H(M). This validates both the authenticity and integrity
|
|||
|
of M simultaneously. If H(M) were unsigned only integrity would be
|
|||
|
assured.
|
|||
|
|
|||
|
A hash function can also serve to detect modification of a
|
|||
|
message, independent of any connection with signatures. That is,
|
|||
|
it can serve as a cryptographic checksum (also known as an MDC =
|
|||
|
manipulation detection code or MAC = message authentication code).
|
|||
|
This may be useful in a case where secrecy and authentication are
|
|||
|
unimportant but accuracy is paramount. For example, if a key is
|
|||
|
sent in unencrypted form, even if the key is only a few hundred
|
|||
|
bits it might be useful to transmit a checksum along with it.
|
|||
|
Another instance where this case arises is when secrecy is provided
|
|||
|
by a system such as DES which does not provide a signature
|
|||
|
capability. An important distinction is that a hash function such
|
|||
|
as a MAC used in connection with a conventional system is typically
|
|||
|
parameterized by a secret shared key, although the latter may be
|
|||
|
distinct from the session key used in transmitting the message and
|
|||
|
its MAC. In contrast, hash functions used in connection with
|
|||
|
public-key systems should be public and hence keyless.
|
|||
|
|
|||
|
Earlier we referred to the use of hash functions as a
|
|||
|
"heuristic" solution to the problem of signing long messages. This
|
|||
|
refers to the fact that the signature for a message should be
|
|||
|
unique, but it is theoretically possible that two distinct messages
|
|||
|
could be compressed into the same message digest (a collision). The
|
|||
|
security of hash functions thus requires collision avoidance.
|
|||
|
Collisions cannot be avoided entirely, since in general the number
|
|||
|
of possible messages will exceed the number of possible outputs of
|
|||
|
the hash function. However, the probability of collisions must be
|
|||
|
low. If a function has a reasonably random output, the probability
|
|||
|
of collisions is determined by the output size.
|
|||
|
|
|||
|
A hash function must meet at least the following minimal
|
|||
|
requirement to serve the authentication process properly: it must
|
|||
|
not be computationally feasible to find a message which hashes to
|
|||
|
the same digest as a given message. Thus, altering a message will
|
|||
|
change the message digest. This is important to avoid forgery.
|
|||
|
|
|||
|
In many settings this minimal requirement is regarded as too
|
|||
|
weak. Instead, the requirement is added that it should not be
|
|||
|
possible to find any two strings which hash to the same value. We
|
|||
|
return to the distinction between these two criteria in section
|
|||
|
3.2.3.
|
|||
|
|
|||
|
|
|||
|
3.2.1 Usage of hash functions.
|
|||
|
|
|||
|
|
|||
|
In a public-key system augmented by a hash function H, A might
|
|||
|
send a message M to B as follows: for simplicity ignore secrecy
|
|||
|
considerations. Then A sends M and S = DA(H(M)) to B. The latter
|
|||
|
uses EA to retrieve H(M) from S, then computes H(M) directly and
|
|||
|
compares the two values for authentication. For nonrepudiation, B
|
|||
|
retains M, H(M) and S. If A attempts to repudiate M, a judge can
|
|||
|
use the three items to resolve the dispute as before: he computes
|
|||
|
H(M) = EA(S) and recomputes H(M) from M. If B could find M' with
|
|||
|
H(M') = H(M), B could claim A sent M'. A judge receiving M', H(M)
|
|||
|
and S would reach a false conclusion.
|
|||
|
|
|||
|
|
|||
|
3.2.2 Relation to one-way functions.
|
|||
|
|
|||
|
|
|||
|
Merkle [MERK82] defines a hash function F to be a transformation
|
|||
|
with the following properties:
|
|||
|
|
|||
|
|
|||
|
a. F can be applied to an argument of any size.
|
|||
|
|
|||
|
b. F produces a fixed-size output.
|
|||
|
|
|||
|
c. F(x) is relatively easy to compute for any given x.
|
|||
|
|
|||
|
d. For any given y it is computationally infeasible to find
|
|||
|
x with F(x) = y.
|
|||
|
|
|||
|
e. For any fixed x it is computationally infeasible to find
|
|||
|
x' <20> x with F(x') = F(x).
|
|||
|
|
|||
|
|
|||
|
The most important properties are (d) and (e). In particular,
|
|||
|
(e) guarantees that an alternative message hashing to the same
|
|||
|
value as a given message cannot be found. This prevents forgery and
|
|||
|
also permits F to function as a cryptographic checksum for
|
|||
|
integrity. Actually (e) can be strengthened as we note momentarily.
|
|||
|
|
|||
|
Property (d) states that F is a one-way function (e.g.,
|
|||
|
[DIFF76b]). One-way functions are used in various other contexts
|
|||
|
as well. For example, we noted earlier that the security of public-
|
|||
|
key systems depends on the fact that the public transformations are
|
|||
|
trapdoor one-way functions. Trapdoors permit decoding by
|
|||
|
recipients. In contrast, hash functions are one-way functions which
|
|||
|
do not have trapdoors.
|
|||
|
|
|||
|
The concept of (non-trapdoor) one-way functions originated in
|
|||
|
connection with log-in procedures ([WILK68] p. 91): Needham noted
|
|||
|
that if passwords were stored encrypted under a one-way function,
|
|||
|
a list of encrypted passwords would be of no use to an intruder
|
|||
|
since the original passwords could not be recovered. When a user
|
|||
|
logged in, the string entered would be encrypted and compared to
|
|||
|
the stored version for authenticity. Essentially the same system
|
|||
|
was rediscovered later in [EVAN74].
|
|||
|
|
|||
|
Usage of one-way functions to produce message digests or encrypt
|
|||
|
passwords is very different from use of trapdoor one-way functions
|
|||
|
to generate encryption functions {EA} in a public-key cryptosystem.
|
|||
|
In the latter, (d) above becomes a dichotomy: it is computationally
|
|||
|
infeasible for anyone except A to find M from C = EA(M); but it is
|
|||
|
easy for A, the unique holder of the trapdoor DA, to compute M =
|
|||
|
DA(C).
|
|||
|
|
|||
|
An example of functions which are not one-way are the private
|
|||
|
transformations in public-key systems: anyone can solve S = D(M)
|
|||
|
for M; i.e., M = E(S). This shows that signature schemes are not
|
|||
|
one-way functions; i.e., they do not satisfy (d) above. On the
|
|||
|
other hand, a deterministic signature function S satisfies (e)
|
|||
|
above; i.e., messages have unique signatures. For example, if a
|
|||
|
signature is generated via S = D(M) where D is a decryption
|
|||
|
function of a public-key system, then D(M) = D(M') implies E(D(M))
|
|||
|
= M = E(D(M')) = M', so (e) is trivially satisfied.
|
|||
|
|
|||
|
Merkle's requirements above are that a hash function must be
|
|||
|
both one-way (d) and effectively collisionless (e). In order to
|
|||
|
satisfy (a) and (b) concurrently, collisions must exist; (e)
|
|||
|
requires that a cryptanalyst should not be able to find them. This
|
|||
|
notion is amenable to further refinement.
|
|||
|
|
|||
|
|
|||
|
3.2.3 Weak and strong hash functions.
|
|||
|
|
|||
|
|
|||
|
The security of hash functions can be refined further: we may
|
|||
|
distinguish between weak and strong hash functions. A function
|
|||
|
satisfying (a) - (e) of the previous section may be termed a weak
|
|||
|
hash function. Property (e) characterizes weak hash functions; it
|
|||
|
states that a cryptanalyst cannot find a second message producing
|
|||
|
the same message digest as a fixed message. On the other hand, H
|
|||
|
may be termed a strong hash function if (a) - (d) still hold, but
|
|||
|
(e) is modified as follows: it is computationally infeasible to
|
|||
|
find any {x1,x2} with H(x1) = H(x2).
|
|||
|
|
|||
|
Strong and weak functions may often be obtained from the same
|
|||
|
class of functions. Strong functions are then characterized by
|
|||
|
larger message digests, which reduce the probability of collisions.
|
|||
|
Strong functions are thus more secure, but the longer message
|
|||
|
digests are likely to increase time needed to hash.
|
|||
|
|
|||
|
Although the two definitions above are superficially similar,
|
|||
|
computationally they are quite different. For example, suppose H
|
|||
|
is a hash function with an 80-bit output. Suppose a cryptanalyst
|
|||
|
starts with a fixed message M and wishes to find a second message
|
|||
|
M' with H(M) = H(M'). Assuming that the 280 outputs of H are totally
|
|||
|
random, any candidate M' has a probability of only 2-80 of meeting
|
|||
|
the required condition. More generally, if the cryptanalyst tries
|
|||
|
k candidates, the probability that at least one candidate satisfies
|
|||
|
H(M) = H(M') is 1-(1-2-80)k which is about 2-80k by the binomial
|
|||
|
theorem if the latter is small. For example, the cryptanalyst will
|
|||
|
probably have to compute H for about k = 274 = 1022 values of M' to
|
|||
|
have even one chance in a million of finding one M' which collides
|
|||
|
with M. Thus H is secure in the weak sense.
|
|||
|
|
|||
|
Suppose for the same H the cryptanalyst merely seeks any values
|
|||
|
{M1,M2} with H(M1) = H(M2). By example F.1, if he examines H(M) for
|
|||
|
at least 1.17 * 240 < 2 * 1012 random values of M, the probability
|
|||
|
of at least one collision exceeds 1/2. A supercomputer could
|
|||
|
probably find M1 and M2 with H(M1) = H(M2) in at most a few days.
|
|||
|
Thus H is not secure in the strong sense.
|
|||
|
|
|||
|
The latter attack is called a birthday attack (app. F). It
|
|||
|
should be noted that finding a collision H(x) = H(y) gives the
|
|||
|
cryptanalyst no valuable information if x and y are random bit
|
|||
|
strings. For a purpose such as forgery an adversary may need to
|
|||
|
generate a large number (e.g. 1012 above) of variations of a message
|
|||
|
to find two which collide. Inclusion of timestamps or sequence
|
|||
|
numbers in messages, according to a fixed format, may make it
|
|||
|
computationally infeasible to find a collision of use to an
|
|||
|
adversary.
|
|||
|
|
|||
|
|
|||
|
3.3 Digital signatures and certificate-based systems.
|
|||
|
|
|||
|
|
|||
|
We previously noted that digital signatures can be employed for
|
|||
|
authentication in the process of distributing public components in
|
|||
|
public-key systems. In particular, if the system is certificate-
|
|||
|
based, the central issuing authority can sign certificates
|
|||
|
containing public components.
|
|||
|
|
|||
|
The notion of a central authority can be extended to a
|
|||
|
hierarchical (tree) structure. The central authority serves as the
|
|||
|
root of the tree; leaves represent users. Intermediate nodes may
|
|||
|
also be users. Typically the intermediate nodes will be arranged
|
|||
|
in several levels representing, e.g., organizations and
|
|||
|
organizational units. Each node of the tree is responsible for
|
|||
|
authenticating its children. Thus an authentication path is created
|
|||
|
for each node, ending at the root. For example, the central
|
|||
|
authority may certify an organization; the organization may certify
|
|||
|
a unit; the unit may certify an individual user. Certification may
|
|||
|
be accomplished by having a parent node sign a certificate for the
|
|||
|
child node. To validate another user's certificate, a user may
|
|||
|
request the entire authentication path.
|
|||
|
|
|||
|
It is also possible for the tree to be replaced by a forest. For
|
|||
|
example, in a multinational system there may be a different tree
|
|||
|
for each country. In this event the roots must certify each other.
|
|||
|
An authentication path may then pass through two or more roots.
|
|||
|
|
|||
|
More generally, an authentication structure can be an arbitrary
|
|||
|
directed graph, with a directed edge from A to B if A certifies B.
|
|||
|
Then authentication paths may be constructed by conjoining directed
|
|||
|
paths from two users to a common trusted node; an example of this
|
|||
|
more complex structure is given in section 5.3.
|
|||
|
|
|||
|
|
|||
|
4. Examples of public-key systems and hash functions.
|
|||
|
|
|||
|
|
|||
|
Numerous public-key systems have been proposed. These may be
|
|||
|
divided into several categories:
|
|||
|
|
|||
|
|
|||
|
a. Systems which have been broken.
|
|||
|
|
|||
|
b. Systems which are considered secure.
|
|||
|
|
|||
|
b.1. Systems which are of questionable practicality.
|
|||
|
|
|||
|
b.2. Systems which are practical.
|
|||
|
|
|||
|
b.2.1. Systems suitable for key distribution only.
|
|||
|
|
|||
|
b.2.2. Systems suitable for digital signatures only.
|
|||
|
|
|||
|
b.2.3. Systems suitable for key distribution and
|
|||
|
digital signatures.
|
|||
|
|
|||
|
|
|||
|
From the standpoint of sheer numbers, most systems have proven
|
|||
|
to be insecure. This is unfortunate, since some of the techniques
|
|||
|
producing insecure systems have relatively high bandwidths, where
|
|||
|
bandwidth refers to rates of encryption/decryption. Knapsack
|
|||
|
ciphers are an example (sec. 4.2.1, app. E)) of high-bandwidth but
|
|||
|
generally insecure systems. Of the systems which have not been
|
|||
|
broken, many are regarded as impractical for reasons such as large
|
|||
|
key sizes or large data expansion (ciphertext much larger than
|
|||
|
plaintext).
|
|||
|
|
|||
|
Only a relative handful of systems are widely-regarded as secure
|
|||
|
and practical. In particular, a cryptosystem is usually regarded
|
|||
|
as secure if breaking it is essentially equivalent to solving a
|
|||
|
long-standing mathematical problem which has defied all attempts
|
|||
|
at solution.
|
|||
|
|
|||
|
Of the well-known systems which are generally regarded as secure
|
|||
|
and practical, some are limited to digital signatures and hence
|
|||
|
unsuitable for public key distribution (e.g. sec. 4.2.2). On the
|
|||
|
other hand, in instances such as the Diffie/Hellman exponential
|
|||
|
exchange scheme (sec. 2.2), public key distribution is supported
|
|||
|
but authentication is not. Such systems may need augmentation by
|
|||
|
a system which supports signatures. The only well-known system
|
|||
|
discovered to date which is secure, practical and suitable for both
|
|||
|
secrecy and authentication is described in section 4.1.
|
|||
|
|
|||
|
Category (b.2.3) above could in theory be further subdivided
|
|||
|
into systems with relatively low and high bandwidths, but there are
|
|||
|
no well-known examples with high bandwidths. There does not exist
|
|||
|
a secure, practical system suitable for key distribution and
|
|||
|
digital signatures, and with high enough bandwidth to support bulk
|
|||
|
data encryption. Prospects for creating radically new systems seem
|
|||
|
dim; in fact, as noted in [DIFF88], most of the extant systems are
|
|||
|
based on a small number of hard mathematical problems:
|
|||
|
|
|||
|
|
|||
|
a. discrete exponentiation.
|
|||
|
|
|||
|
b. knapsack problems.
|
|||
|
|
|||
|
c. factoring.
|
|||
|
|
|||
|
|
|||
|
According to Diffie, discrete exponentiation was suggested by
|
|||
|
J. Gill, and the use of the knapsack problem by Diffie. A
|
|||
|
suggestion to use factoring was apparently made by Knuth to Diffie
|
|||
|
during the early years of public-key cryptography, but factoring
|
|||
|
was not incorporated into a cryptosystem until several years later
|
|||
|
(sec. 4.1).
|
|||
|
|
|||
|
The knapsack problem is noted briefly in section 4.2.1. The
|
|||
|
other two mathematical problems above are easy to state (though
|
|||
|
also hard to solve):
|
|||
|
|
|||
|
|
|||
|
a. If p is a given prime and g and M are given integers, find
|
|||
|
x such that gx <20> M (mod p).
|
|||
|
|
|||
|
b. If N is a product of two secret primes:
|
|||
|
|
|||
|
1. factor N.
|
|||
|
|
|||
|
2. Given integers M and C, find d such that Md <20> C (mod
|
|||
|
N).
|
|||
|
|
|||
|
3. Given integers e and C, find M such that Me <20> C (mod
|
|||
|
N).
|
|||
|
|
|||
|
4. Given an integer x, decide whether there exists an
|
|||
|
integer y such that x <20> y2 (mod N).
|
|||
|
|
|||
|
|
|||
|
Gill's suggestion was based on (a), i.e., on the difficulty of
|
|||
|
computing discrete logarithms modulo a prime. This has generated
|
|||
|
systems (e.g. sec. 2.2) suitable for key distribution, and others
|
|||
|
suitable for signatures (e.g. sec. 4.2.2).
|
|||
|
|
|||
|
Exploitation of the difficulty of factoring has proven to be the
|
|||
|
most versatile approach to design of public-key systems. Factoring
|
|||
|
is widely-regarded as very difficult. If a modulus has unknown
|
|||
|
factorization, various problems in modular arithmetic become
|
|||
|
difficult. For example, discrete logarithm ((b.2) above) is
|
|||
|
difficult, as is taking roots (b.3) and deciding quadratic
|
|||
|
residuosity (b.4). These problems have generated the most widely-
|
|||
|
known public-key system (sec. 4.1) and various others. We remark
|
|||
|
in passing that the probabilistic scheme mentioned in section 3 and
|
|||
|
appendix P are based on (b.4); more generally, quadratic
|
|||
|
residuosity forms the basis of many zero-knowledge schemes.
|
|||
|
|
|||
|
Diffie's knapsack suggestion is one of many attempts to utilize
|
|||
|
NP-complete problems for cryptosystems. Such attempts have met with
|
|||
|
very limited success. We return to this topic and further
|
|||
|
discussion of the above problems later. In the meantime we discuss
|
|||
|
a few of the most well-known public-key systems, along with some
|
|||
|
hash functions.
|
|||
|
|
|||
|
|
|||
|
4.1 The RSA public-key scheme.
|
|||
|
|
|||
|
|
|||
|
Rivest, Shamir and Adleman [RIVE78] obtained the best-known and
|
|||
|
most versatile public-key cryptosystem. It supports both secrecy
|
|||
|
and authentication, and hence can provide complete and self-
|
|||
|
contained support for public key distribution and signatures.
|
|||
|
|
|||
|
A user chooses primes p and q and computes n = p * q and m = (p-
|
|||
|
1)(q-1). He then chooses e to be an integer in [1,m-1] with
|
|||
|
GCD(e,m) = 1. He finds the multiplicative inverse of e, modulo m;
|
|||
|
i.e. he finds (app. H) d in [1,m-1] with e * d <20> 1 (mod m). Now n
|
|||
|
and e are public; d, p, q and m are secret. That is, for a user A,
|
|||
|
nA and eA constitute the public component, and dA, pA, qA the private
|
|||
|
component.
|
|||
|
|
|||
|
After a user has computed p,q,e,d, the private transformation
|
|||
|
D and public transformation E are defined by (see app. M):
|
|||
|
|
|||
|
|
|||
|
E(M) = Me mod n,
|
|||
|
|
|||
|
D(C) = Cd mod n.
|
|||
|
|
|||
|
|
|||
|
In the above, M and C are in [0,n-1]. As in section 1.5 we have
|
|||
|
D(E(M)) = M and E(D(C)) = C; i.e. D and E are inverses. Since d is
|
|||
|
private, so is D; and since e and n are public, so is E. This
|
|||
|
constitutes a cryptosystem which can be used for both secrecy and
|
|||
|
authentication. That is, for secrecy, A sends EB(M) to B as usual;
|
|||
|
for authentication, A sends DA(M) as usual. For both secrecy and
|
|||
|
authentication, suppose first that message digests are not
|
|||
|
employed. Assuming nA <20> nB, A computes
|
|||
|
|
|||
|
|
|||
|
C = EB(DA(M))
|
|||
|
|
|||
|
and sends C to B. Then B recovers M as usual by
|
|||
|
|
|||
|
|
|||
|
M = EA(DB(EB(DA(M)))).
|
|||
|
|
|||
|
|
|||
|
This process is illustrated below:
|
|||
|
|
|||
|
|
|||
|
A: B:
|
|||
|
___________________________ __________________
|
|||
|
| | | |
|
|||
|
| compute M' = M**eA mod nA | |----->| receive C from A |
|
|||
|
|___________________________| | |__________________|
|
|||
|
| | |
|
|||
|
| | |
|
|||
|
_____________\|/___________ | ____________\|/____________
|
|||
|
| | | |
|
|||
|
|
|
|||
|
| compute C = M'**dB mod nB | | | compute M' = C**eB mod nB
|
|||
|
|
|
|||
|
|___________________________| | |___________________________|
|
|||
|
| | |
|
|||
|
| | |
|
|||
|
__________\|/__________ | ____________\|/____________
|
|||
|
| | | |
|
|||
|
|
|
|||
|
| send C to B | | | compute M = M'**dA mod nA
|
|||
|
| |_______________________| |
|
|||
|
|___________________________|
|
|||
|
| |
|
|||
|
| |
|
|||
|
\|/_____________\|
|
|||
|
/
|
|||
|
|
|||
|
Figure 6. Using RSA for Authenticity and Secrecy
|
|||
|
|
|||
|
|
|||
|
As noted in section 3.1.1, for nonrepudiation B may retain
|
|||
|
DA(M).
|
|||
|
|
|||
|
This implementation only works because the range of DA is a
|
|||
|
subset of the domain of EB; i.e. [0,nA-1] is a subset of [0,nB-1].
|
|||
|
In the event that nA <20> nB, Kohnfelder [KOHN78b] notes that A can
|
|||
|
instead transmit
|
|||
|
|
|||
|
|
|||
|
C' = DA(EB(M)).
|
|||
|
|
|||
|
|
|||
|
Then B can recover M as
|
|||
|
|
|||
|
|
|||
|
M = DB(EA(DA(EB(M)))).
|
|||
|
|
|||
|
|
|||
|
This works since the range of EB is a subset of the domain of DA.
|
|||
|
For adjudication of possible disputes, B must retain C' and M. Then
|
|||
|
to prove that A sent M, the judge can compute EA(C') and EB(M) and
|
|||
|
test for equality.
|
|||
|
|
|||
|
However, in [DAVI83] and [DENN83b] it is noted that there is a
|
|||
|
disadvantage to this solution: A signs EB(M) rather than M. In
|
|||
|
section 3.1.1 the judge was able to apply EA to the stored quantity
|
|||
|
DA(M) and M is obtained. In Kohnfelder's protocol both C' and M
|
|||
|
must be stored, doubling the storage requirement.
|
|||
|
|
|||
|
The use of message digests eliminates the preceding problem.
|
|||
|
Suppose H is a hash function. Then to send M to B, A can create a
|
|||
|
new message M' containing M and DA(H(M)) and send C = EB(M') to B.
|
|||
|
This gives both secrecy and authentication; also, C may be retained
|
|||
|
for nonrepudiation. Moreover, M and DA(H(M)) are reblocked in
|
|||
|
forming M', so that no problem arises from the sizes of nA and nb.
|
|||
|
|
|||
|
|
|||
|
4.1.1 Choice of p and q.
|
|||
|
|
|||
|
|
|||
|
To use the RSA system, a user must first choose primes p and q.
|
|||
|
As noted in section 4.1.3, p and q should at least 75 to 80 decimal
|
|||
|
digits; for the sake of discussion we assume p and q to be on the
|
|||
|
order of about 100 digits. The user begins by choosing a random odd
|
|||
|
b of around 100 digits; b is a candidate for p. Now b is acceptable
|
|||
|
only if b is prime. There are two approaches to this problem. The
|
|||
|
deterministic approach decides with certainty whether b is prime
|
|||
|
(see below). An alternative is to use the probabilistic approach
|
|||
|
as implemented, e.g., by Solovay and Strassen [SOLO77]: randomly
|
|||
|
choose a set of about 100 numbers in [1,b-1]. For each number a in
|
|||
|
the set, test to see if GCD(a,b) = 1, where GCD = greatest common
|
|||
|
divisor. If this condition holds, compute the Jacobi symbol (a/b)
|
|||
|
(app. J). Both GCDs and Jacobi symbols are easy to compute via
|
|||
|
well-known algorithms (app. H,J). Now check to see if
|
|||
|
|
|||
|
|
|||
|
(a/b) <20> a(b-1)/2 (mod b).
|
|||
|
|
|||
|
|
|||
|
If b is not prime, this check will fail with probability at
|
|||
|
least 1/2 (app. L). Thus, if 100 random a's are tested and all pass
|
|||
|
the above test, the probability of b not being prime is about 1 in
|
|||
|
2100. Hence it is possible to test in polynomial time whether b is
|
|||
|
probably a prime. The probability of b being prime is about 1 in
|
|||
|
115; hence repeated applications of the preceding algorithm will
|
|||
|
probably quickly yield b which is probably a prime. This can be
|
|||
|
taken to be p; a second application of the algorithm will yield q.
|
|||
|
|
|||
|
The Solovay/Strassen algorithm is discussed further in appendix
|
|||
|
L, which also mentions alternative algorithms of Lehman [LEHM82]
|
|||
|
and Miller and Rabin ([MILL76],[RABI80]).
|
|||
|
|
|||
|
The advantage of such probabilistic algorithms is that the
|
|||
|
algorithms run in polynomial time. They do not guarantee a correct
|
|||
|
answer, but the possibility of error is negligible as noted above.
|
|||
|
If absolute certainty were required, deterministic algorithms for
|
|||
|
primality testing could be used ([ADLE83],[COHE87],[COHE84]). These
|
|||
|
guarantee primality, but have runtimes of the form
|
|||
|
|
|||
|
|
|||
|
exp(c(log log n)(log log log n)).
|
|||
|
|
|||
|
|
|||
|
If a sufficient amount of computing power is available,
|
|||
|
primality of 100-digit numbers can usually be established
|
|||
|
deterministically in minutes. However, the code needed is
|
|||
|
complicated; moreover, most users will not have access to high-
|
|||
|
performance computers. The probabilistic algorithms have acceptable
|
|||
|
run times even on small computers, particularly if hardware support
|
|||
|
is available.
|
|||
|
|
|||
|
|
|||
|
4.1.2 Further notes on implementation.
|
|||
|
|
|||
|
|
|||
|
Once p and q have been chosen, e is chosen to be relatively
|
|||
|
prime to m = (p-1)(q-1); i.e. GCD(e,m) = 1. For example, e can be
|
|||
|
chosen to be a random small prime > 2. If e is relatively small,
|
|||
|
E(M) can be computed relatively rapidly; i.e. only a small number
|
|||
|
of modular multiplications are needed. The condition GCD(e,m) = 1
|
|||
|
presents no problem; in fact the probability that two random
|
|||
|
numbers are relatively prime is about 3/5 ([KNUT81] p. 324). Now
|
|||
|
d can be found in polynomial time; however, d may be large. Hence
|
|||
|
a version of the Chinese Remainder Theorem is employed for
|
|||
|
decryption (app. M).
|
|||
|
|
|||
|
There are some restrictions on p and q in addition to the size
|
|||
|
specification mentioned above. Some of these are noted in section
|
|||
|
4.1.3.1. Also, the time and space requirements of RSA are
|
|||
|
considerably larger than, e.g., DES. Storage for each of p, q, and
|
|||
|
d will require at least 300 bits; n is about 600 bits. Only e can
|
|||
|
be chosen to be small.
|
|||
|
|
|||
|
Exponentiation mod n is a relatively slow operation for large
|
|||
|
n, especially in software. Efficient algorithms for computing
|
|||
|
products mod n have been given, e.g., in [BLAK83], [BRIC82],
|
|||
|
[MONT85] and [QUIS82]. In particular, [BRIC82] shows how
|
|||
|
multiplication mod n can be done in m+7 clock pulses if n is m
|
|||
|
bits. In [MONT85] it is shown how modular multiplication can avoid
|
|||
|
division.
|
|||
|
|
|||
|
At the present time RSA decryption (encryption is slower) with
|
|||
|
a 508-bit modulus has been performed at about 225 Kbits/sec in
|
|||
|
hardware [SHAN90]. Decryption with a 512-bit modulus has been
|
|||
|
effected at about 11 Kbits/sec in software [DUSS90].
|
|||
|
|
|||
|
|
|||
|
4.1.3 Security of RSA.
|
|||
|
|
|||
|
|
|||
|
The security of the private components in the RSA cryptosystem
|
|||
|
depends on the difficulty of factoring large integers. No efficient
|
|||
|
algorithms are known for this problem. Consequently, knowing n =
|
|||
|
p * q does not yield p and q. Thus it is computationally infeasible
|
|||
|
to find (p-1)(q-1) = m, and hence the relation e * d <20> 1 (mod m)
|
|||
|
is useless for determining d from e.
|
|||
|
|
|||
|
The difficulty of computing discrete logarithms (cf. sec. 1.5)
|
|||
|
deflects known-plaintext attacks. Suppose an intruder knows M, C
|
|||
|
and M = D(C) for some plaintext/ciphertext pair {M,C}. To find d
|
|||
|
he must solve M = Cd mod n; i.e., he must find a discrete
|
|||
|
logarithm.
|
|||
|
|
|||
|
Ciphertext-only attacks are equivalent to taking roots modulo
|
|||
|
a composite number with unknown factorization, i.e. solving C = Me
|
|||
|
mod n for M. This is probably about as difficult as discrete
|
|||
|
logarithms, even in the case of square roots (e.g., [ADLE86]). In
|
|||
|
fact (lem. N.3.2; cf. [KNUT81] p. 389, [RABI79]), taking square
|
|||
|
roots modulo such n is, loosely speaking, as hard as factoring n.
|
|||
|
|
|||
|
It should be noted that the security of RSA is not provably
|
|||
|
equivalent to the difficulty of factoring or the other problems
|
|||
|
mentioned here. Also, security of RSA or other public-key systems
|
|||
|
does not preclude breaking specific protocols for their use; see
|
|||
|
e.g. [MOOR88] or [DOLE81]. An example of a protocol failure is
|
|||
|
given in [MOOR88]: suppose two users use a common modulus n and
|
|||
|
encryption exponents e and e' with GCD(e,e') = 1. If the same
|
|||
|
message M is sent to both, then let C = Me mod n and C' = Me' mod n.
|
|||
|
If both C and C' are intercepted, an intruder can find (app. H) r
|
|||
|
and s with r * e + s * e' = 1; now M = Cr * C's mod n.
|
|||
|
|
|||
|
|
|||
|
4.1.3.1 Restrictions on p and q.
|
|||
|
|
|||
|
|
|||
|
There are two major restrictions on p and q in order to foil
|
|||
|
attempts at factoring n = p * q:
|
|||
|
|
|||
|
|
|||
|
a. p and q should be about the same length.
|
|||
|
|
|||
|
b. p and q should be at least 75 digits in length.
|
|||
|
|
|||
|
|
|||
|
Present factoring methods will be foiled by such a choice. For
|
|||
|
longer-term security, p and q should be, e.g., around 100 digits.
|
|||
|
Condition (a) is needed against the elliptic curve method (see
|
|||
|
below).
|
|||
|
|
|||
|
An attempt to predict the period of time for which a given
|
|||
|
modulus length will remain secure is necessarily guesswork.
|
|||
|
Intelligent guesses are the best that can be hoped for by
|
|||
|
implementors; these are connected with the status of progress in
|
|||
|
factoring, which is highly dynamic.
|
|||
|
|
|||
|
|
|||
|
4.1.3.2 Notes on factoring.
|
|||
|
|
|||
|
|
|||
|
Choosing n to be about 200 digits will foil any present attempt
|
|||
|
at factoring n. The most powerful general-purpose factoring
|
|||
|
algorithm is Pomerance's quadratic sieve [POME84] and its
|
|||
|
variations. Using a parallel version of the quadratic sieve, Caron
|
|||
|
and Silverman [CARO87] factored 90-digit integers in several weeks
|
|||
|
on a network of several dozen Sun-3's. Recently, 106-digit integers
|
|||
|
have been factored on a larger network [LENS89], using the multiple
|
|||
|
polynomial variant of the quadratic sieve. Recent announcements of
|
|||
|
work in progress indicate that integers of around 116 digits may
|
|||
|
be factored shortly, using the same network used in the 106-digit
|
|||
|
case and another variant of the quadratic sieve.
|
|||
|
|
|||
|
Pomerance, Smith and Tuler [POME88] discuss a prototype of a
|
|||
|
special pipelined architecture, optimized for the quadratic sieve,
|
|||
|
which they claim is extensible to a machine which might factor 125-
|
|||
|
digit integers in a year. However, this presents no threat to 200-
|
|||
|
digit moduli, since all of the best general-purpose factoring
|
|||
|
algorithms known, including the quadratic sieve, run in time
|
|||
|
roughly
|
|||
|
|
|||
|
|
|||
|
exp(((log n)(log log n))1/2).
|
|||
|
|
|||
|
|
|||
|
The fastest present computers only execute on the order of 1010
|
|||
|
operations per second, at a cost of $10 million or more. Even if
|
|||
|
a future computer reached 1012 operations per second (and presumably
|
|||
|
a cost exceeding $100 million) it would take on the order of 1000
|
|||
|
years to factor a 200-digit number using existing algorithms.
|
|||
|
|
|||
|
The strongest results on factoring obtained to date have
|
|||
|
utilized networks of computers. The power of such networks is more
|
|||
|
difficult to extrapolate than for supercomputers, since they are
|
|||
|
expandable and the power of personal computers and workstations has
|
|||
|
been rising at a higher rate than at the supercomputer level. In
|
|||
|
theory it would be preferable to know that a cryptosystem would be
|
|||
|
immune to an attack by an assemblage of every computer in the
|
|||
|
universe. It seems difficult to estimate the total amount of
|
|||
|
computing power this would bring to bear; furthermore, the question
|
|||
|
in practice is what fraction of this total amount can be
|
|||
|
realistically allotted to a given factoring problem (cf. app. B).
|
|||
|
|
|||
|
It follows that implementors may have a high level of confidence
|
|||
|
in 200-digit moduli at the present. An interesting issue at the
|
|||
|
time of this writing is whether a modulus with a length between 150
|
|||
|
and 200 digits will provide security for a given length of time.
|
|||
|
It seems certain that 154-digit (i.e., 512-bit) integers will be
|
|||
|
factored eventually, but the question is when. If the preceding
|
|||
|
runtime estimate is used, the conclusion is that 154 digits is
|
|||
|
likely to be secure until the late 1990s, barring major algorithmic
|
|||
|
advances (cf. app. B). RSA moduli of around 512 bits are generally
|
|||
|
preferable to 200 digits (around 660 bits) from a hardware-
|
|||
|
implementation standpoint.
|
|||
|
|
|||
|
A potential qualifier to the preceding analysis is that the
|
|||
|
above runtime estimate is generic; in particular it assumes that
|
|||
|
runtime is essentially independent of the integer being factored.
|
|||
|
However, there are algorithms which have the above as their worst-
|
|||
|
case time. For example, the Schnorr/Lenstra algorithm [SCHN84]
|
|||
|
factors n by using quadratic forms with discriminant -n. The
|
|||
|
equivalence classes of such forms form a group (the class group)
|
|||
|
whose order is denoted by h(-n). The algorithm factors n quickly
|
|||
|
if h(-n) is free of large prime divisors. The algorithm is Monte
|
|||
|
Carlo in the sense that the n's which will be factored quickly are
|
|||
|
evidently fairly random. No algorithms are known to generate class
|
|||
|
numbers with large prime divisors, although interestingly RSA comes
|
|||
|
close: class numbers h(-n) of discriminants n with one or two prime
|
|||
|
factors have a higher probability of having large prime factors
|
|||
|
than the class numbers of discriminants with only small prime
|
|||
|
factors.
|
|||
|
|
|||
|
The net result is that, e.g., perhaps one in 1000 n's will
|
|||
|
factor 1000 times more quickly than average. If this method were
|
|||
|
practicable it would argue for the 200-digit modulus in RSA.
|
|||
|
However, the Monte Carlo phenomenon has not produced noticeably
|
|||
|
lower factoring times in practice as yet.
|
|||
|
|
|||
|
Some other factoring methods are applicable to numbers which do
|
|||
|
not have the form required for an RSA modulus. For example, the
|
|||
|
elliptic curve method [LENS87] is oriented to integers whose
|
|||
|
second-largest prime factor is considerably smaller than the
|
|||
|
largest prime factor. This motivates the condition that an RSA
|
|||
|
modulus should have factors roughly equal in size. A recent
|
|||
|
algorithm, the number field sieve [LENS90], applies to integers of
|
|||
|
the form rd + s or rd - s where r and s are small. Again this will
|
|||
|
not affect properly-chosen RSA moduli.
|
|||
|
|
|||
|
|
|||
|
4.1.4 Low-exponent versions of RSA.
|
|||
|
|
|||
|
|
|||
|
A priori the encryption exponent e in the RSA scheme is
|
|||
|
arbitrary. However, it need not be random. It has been suggested
|
|||
|
that e be chosen to have a common value by all users of an RSA-
|
|||
|
based system. Using e = 2 is not feasible per se, since 2 is not
|
|||
|
relatively prime to p-1 or q-1. However, extensions of this type
|
|||
|
have been made. These are of some theoretical interest, since Rabin
|
|||
|
[RABI79] and Williams [WILL80] have noted modifications of RSA with
|
|||
|
exponent 2 for which successful ciphertext-only attacks are
|
|||
|
essentially as difficult as factoring the modulus (app. N).
|
|||
|
|
|||
|
The exponent 3 can be used directly with RSA. It has the
|
|||
|
advantage of greatly simplifying the encryption (but not the
|
|||
|
decryption) process. In fact Knuth [KNUT81], Rivest [RIVE84] and
|
|||
|
others recommend its usage. However, 3 and other very low exponents
|
|||
|
suffer from some flaws. The case e = 3 is an illustration. For one
|
|||
|
thing, as Knuth notes, users must make certain that each block M
|
|||
|
to be encrypted satisfies M3 >> n. This is because C = M3 mod n
|
|||
|
becomes simply C = M3 if M3 < n; in this event finding M reduces to
|
|||
|
the trivial problem of taking ordinary cube roots of integers. Thus
|
|||
|
the use of e = 3 causes the domain of E to be a subset of [0,n)
|
|||
|
rather than the whole interval as would be preferable.
|
|||
|
|
|||
|
A related but more subtle flaw has also been noted if, e.g., e
|
|||
|
= 3 [HAST88]. Suppose A sends the same message M to each of {Bi},
|
|||
|
i = 1,2,3. Suppose Bi uses modulus ni, and M < ni for each i (this
|
|||
|
will be true, e.g., if the sender uses a modulus smaller than each
|
|||
|
of the {ni}). Assuming that each of {n1,n2,n3} is generated as a
|
|||
|
product of two random primes, the probability of duplicates among
|
|||
|
the 6 primes used is near zero. Hence it may be safely assumed that
|
|||
|
the {ni} are pairwise relatively prime. Let Ci = M3 mod ni. Suppose
|
|||
|
all 3 {Ci} are intercepted. Using the Chinese Remainder Theorem
|
|||
|
(app. I), the intruder can find x in [0,n'), n' = n1 * n2 * n3, with
|
|||
|
x <20> Ci (mod ni), i = 1,2,3. Thus x <20> M3 (mod n'). But M3 < n', so M3
|
|||
|
= x, so M = x1/3 (ordinary cube root). Hence the plaintext M can be
|
|||
|
easily recovered from the three ciphertexts. Thus the use of e =
|
|||
|
3 or other small exponents makes RSA vulnerable to ciphertext-only
|
|||
|
attacks. The sender may attempt to modify M for each recipient to
|
|||
|
deflect this attack, but Hastad shows that more generally, a low
|
|||
|
exponent is vulnerable to linear dependencies in portions of
|
|||
|
messages.
|
|||
|
|
|||
|
|
|||
|
4.2 Other public-key systems.
|
|||
|
|
|||
|
|
|||
|
Several public-key systems other than RSA have been proposed.
|
|||
|
These are briefly surveyed here. As noted earlier, most of these
|
|||
|
are either insecure, of questionable practicality, or limited to
|
|||
|
one of signatures/secrecy but not both. In some cases their
|
|||
|
security and/or practicality has not been established. None of
|
|||
|
these systems rivals RSA if a combination of versatility, security
|
|||
|
and practicality is the criterion. However, this does not preclude
|
|||
|
the use of the secure systems for specific applications such as
|
|||
|
digital signatures.
|
|||
|
|
|||
|
|
|||
|
4.2.1 Knapsack systems.
|
|||
|
|
|||
|
|
|||
|
These were proposed by Merkle and Hellman [MERK78b]. However,
|
|||
|
the essence is the use of NP-complete problems (e.g.,
|
|||
|
[GARE79],[HORO78]) which had been suggested for use in designing
|
|||
|
public-key systems in [DIFF76b]. The Merkle/Hellman approach was
|
|||
|
to employ a superincreasing sequence {ai}, i.e., a sequence of
|
|||
|
positive integers for which
|
|||
|
|
|||
|
|
|||
|
ai > ai-1 + ... + a1.
|
|||
|
|
|||
|
|
|||
|
The associated knapsack problem [HORO78] is to find nonnegative
|
|||
|
integers {Mi} such that for a given Y,
|
|||
|
|
|||
|
|
|||
|
Y = a1 * M1 + ... + an * Mn.
|
|||
|
|
|||
|
|
|||
|
The above is an instance of integer programming. In the present
|
|||
|
context the {Mi} are binary; thus the above reduces to sum-of-
|
|||
|
subsets. Solving the above is easy for superincreasing {ai}; in
|
|||
|
fact the solution is unique. However, even deciding existence of
|
|||
|
a solution of sum-of-subsets, or more generally integer
|
|||
|
programming, is NP-complete ([GARE79], pp. 223, 245). Now for any
|
|||
|
w and u satisfying
|
|||
|
|
|||
|
|
|||
|
u > a1 + ... + an,
|
|||
|
|
|||
|
GCD(u,w) = 1,
|
|||
|
|
|||
|
|
|||
|
a disguised knapsack problem may be produced from {ai} by defining
|
|||
|
|
|||
|
|
|||
|
bi = w * ai mod u.
|
|||
|
|
|||
|
|
|||
|
Then the associated knapsack problem
|
|||
|
|
|||
|
|
|||
|
C = b1 * M1 + ... + bn * Mn
|
|||
|
|
|||
|
|
|||
|
appears to a cryptanalyst to be hard since the {bi} appear random.
|
|||
|
In actuality, it is easily solved using the connection with the
|
|||
|
{ai}: since GCD(w,u) = 1, there exists W (app. H) such that
|
|||
|
|
|||
|
|
|||
|
w * W <20> 1 (mod u).
|
|||
|
|
|||
|
|
|||
|
Then
|
|||
|
|
|||
|
|
|||
|
W * C <20> a1 * M1 + ... + an * Mn (mod u).
|
|||
|
|
|||
|
|
|||
|
Since 0 <20> Mi <20> 1,
|
|||
|
|
|||
|
|
|||
|
0 <20> a1 * M1 + ... + an * Mn < u,
|
|||
|
|
|||
|
|
|||
|
from which
|
|||
|
|
|||
|
|
|||
|
W * C = a1 * M1 + ... + an * Mn.
|
|||
|
|
|||
|
|
|||
|
As noted above, the latter knapsack problem has an easily-found
|
|||
|
unique solution, from which C may be retrieved. This is called a
|
|||
|
trapdoor; it permits a legitimate user to easily solve what appears
|
|||
|
to be a hard problem. The above modular disguise can be iterated;
|
|||
|
i.e., new w' and u' chosen and the {bi} disguised, etc.
|
|||
|
|
|||
|
The trapdoor knapsack yields a public-key system: if the binary
|
|||
|
representation of plaintext M is Mn...M1, let
|
|||
|
|
|||
|
|
|||
|
E(M) = b1 * M1 + ... + bn * Mn.
|
|||
|
|
|||
|
|
|||
|
If C = E(M) then decrypting C is equivalent to solving what
|
|||
|
appears to be a general knapsack problem, although decryption is
|
|||
|
easy using the trapdoor. The public component is {bi} and the
|
|||
|
private component is u, w and {ai} (see [MERK78b] for details).
|
|||
|
|
|||
|
The advantage is that the arithmetic is much quicker than in
|
|||
|
RSA: about 200 additions are needed, as opposed to about 500
|
|||
|
squarings and 150 multiplications in RSA. In fact knapsacks may
|
|||
|
rival DES in speed [HENR81]. Unfortunately the above knapsack and
|
|||
|
most variations on the above have been broken (Appendix E).
|
|||
|
|
|||
|
It should also be noted that even if a knapsack approach proves
|
|||
|
to be secure and practical, such schemes are generally limited to
|
|||
|
support for either secrecy or authentication but not both. In
|
|||
|
contrast to RSA, the encryption and decryption functions are not
|
|||
|
inverses, although D(E(M)) = M. A trivial example suffices to show
|
|||
|
this: suppose
|
|||
|
|
|||
|
|
|||
|
E(M) = 2M1 + 3M2.
|
|||
|
|
|||
|
|
|||
|
To be invertible a function must be both injective and
|
|||
|
surjective. However, E is not surjective (onto). For example there
|
|||
|
is no M such that E(M) = 1; hence D(1) is undefined. Thus we could
|
|||
|
not employ D for signatures as in RSA, since, e.g., 1 could not be
|
|||
|
signed by computing D(1).
|
|||
|
|
|||
|
|
|||
|
4.2.2 The ElGamal signature scheme.
|
|||
|
|
|||
|
|
|||
|
A signature scheme derived from a modification of exponentiation
|
|||
|
ciphers was proposed by ElGamal [ELGA85].
|
|||
|
|
|||
|
First of all a prime p and a base a which is a primitive root
|
|||
|
modulo p (app. K) are public. Now suppose A wishes to send a signed
|
|||
|
message to B. The private component of A consists of two portions,
|
|||
|
one fixed and the other message-dependent. The fixed portion is a
|
|||
|
random x(A) from [1,p-2]. The public component of A also has fixed
|
|||
|
and message-dependent components. The fixed portion is
|
|||
|
|
|||
|
|
|||
|
y(A) = ax(A) mod p.
|
|||
|
|
|||
|
|
|||
|
Now for a given message M in [0,p-1], A chooses a secret k in
|
|||
|
[0,p-1] with GCD(k,p-1) = 1. Thus k is the message-dependent
|
|||
|
portion of A's private component. Also, A finds (app. H) I with
|
|||
|
|
|||
|
|
|||
|
k * I <20> 1 (mod (p-1)).
|
|||
|
|
|||
|
|
|||
|
The message-dependent portion of A's public component consists
|
|||
|
of r and s, where
|
|||
|
|
|||
|
|
|||
|
r = ak mod p,
|
|||
|
|
|||
|
s <20> I * (M - r * x(A)) (mod (p-1)).
|
|||
|
|
|||
|
|
|||
|
Now A sends M, r and s to B. For authentication B computes
|
|||
|
|
|||
|
|
|||
|
C = aM mod p,
|
|||
|
|
|||
|
C' = y(A)r * rs mod p.
|
|||
|
|
|||
|
|
|||
|
We note that
|
|||
|
|
|||
|
|
|||
|
M <20> r * x(A) + k * s (mod (p-1)).
|
|||
|
|
|||
|
|
|||
|
Hence if M is authentic and valid,
|
|||
|
|
|||
|
|
|||
|
C = (ax(a))r * (ak)s mod p = C'.
|
|||
|
|
|||
|
|
|||
|
The ElGamal algorithm is illustrated below.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
A: B:
|
|||
|
____________________ _________________
|
|||
|
| | _____\| |
|
|||
|
| choose k | /|\ /| receive (M,r,s) |
|
|||
|
|____________________| | |_________________|
|
|||
|
| | |
|
|||
|
| | |
|
|||
|
_________\|/__________ | __________\|/___________
|
|||
|
| | | | |
|
|||
|
| find I*k <20> 1 mod p-1 | | | compute C = a**M mod p |
|
|||
|
|______________________| | |________________________|
|
|||
|
| | |
|
|||
|
| | |
|
|||
|
__________\|/___________ | _________\|/_________
|
|||
|
| | | | |
|
|||
|
| compute r = a**k mod p | | | compute C' = yA**r |
|
|||
|
|________________________| | | * r**s mod p |
|
|||
|
| | |_____________________|
|
|||
|
| | |
|
|||
|
| | |
|
|||
|
__________\|/___________ | |
|
|||
|
| | | |
|
|||
|
| compute s = I*(M-r*xA) | | |
|
|||
|
| mod p-1 | | |
|
|||
|
|________________________| | |
|
|||
|
| | |
|
|||
|
| | |
|
|||
|
________\|/_________ | _________\|/_________
|
|||
|
| | | | |
|
|||
|
| send (M,r,s) to B | | | verify C' = C |
|
|||
|
|____________________| | |_____________________|
|
|||
|
| |
|
|||
|
| |
|
|||
|
\|/________________\|
|
|||
|
/
|
|||
|
|
|||
|
Figure 7. The ElGamal Signature Algorithm
|
|||
|
|
|||
|
|
|||
|
A different k must be chosen for each M; using any k twice
|
|||
|
determines x(A) uniquely. The security of the method then depends
|
|||
|
mainly on the difficulty of computing discrete logarithms in GF(p):
|
|||
|
suppose an intruder intercepts M, r and s; a and p are public. Let
|
|||
|
d = ar mod p and u * rs <20> 1 (mod p). Then the intruder knows
|
|||
|
|
|||
|
|
|||
|
aM <20> y(A)r * rs (mod p).
|
|||
|
|
|||
|
|
|||
|
Hence
|
|||
|
|
|||
|
|
|||
|
u * aM <20> y(A)r (mod p).
|
|||
|
|
|||
|
|
|||
|
Thus
|
|||
|
|
|||
|
|
|||
|
dx(A) <20> (ax(A))r <20> y(A)r (mod p).
|
|||
|
|
|||
|
|
|||
|
Finally
|
|||
|
|
|||
|
|
|||
|
dx(A) <20> u * aM (mod p).
|
|||
|
|
|||
|
|
|||
|
Finding x(A), which permits the intruder to masquerade as A, is
|
|||
|
thus equivalent to the above discrete logarithm problem. It is easy
|
|||
|
to solve this problem if p-1 has only small factors [POHL78], hence
|
|||
|
p-1 should have a large prime factor as in RSA. An alternative
|
|||
|
approach is to seek k and m satisfying
|
|||
|
|
|||
|
|
|||
|
M = r * x(A) + s * k + (p-1) * m,
|
|||
|
|
|||
|
|
|||
|
but this is underdetermined, so that there are an exponential
|
|||
|
number of possible solutions to check. A third approach at
|
|||
|
cryptanalysis seeks r and s satisfying
|
|||
|
|
|||
|
|
|||
|
aM <20> y(A)r * rs (mod p).
|
|||
|
|
|||
|
|
|||
|
This is presumably easier than discrete logarithm since r and
|
|||
|
s can both be varied, but it is not clear how much easier.
|
|||
|
|
|||
|
In comparing this scheme to RSA, we note that both employ
|
|||
|
exponentiation, so that their speeds of encryption/decryption
|
|||
|
should be comparable. Generating keys in the two methods is
|
|||
|
similar; finding appropriate primes is the main step in either.
|
|||
|
Security of ElGamal is more difficult to assess. The major attack
|
|||
|
against RSA, i.e., factorization, is a problem which has been
|
|||
|
studied for centuries. It is safe to say that far less time has
|
|||
|
been invested in attempts to cryptanalyze the ElGamal scheme.
|
|||
|
|
|||
|
Cryptanalytically, the last attack (varying r and s
|
|||
|
simultaneously) may have a complexity substantially lower than
|
|||
|
factoring or discrete logarithm; hence security of ElGamal is at
|
|||
|
best no better than RSA, and possibly much inferior, with respect
|
|||
|
to secrecy of components (it must be emphasized that this is a
|
|||
|
conservative characterization; it could also turn out that no
|
|||
|
substantial advantage is gained by varying r and s simultaneously).
|
|||
|
The use of message-dependent portions of components is a plus and
|
|||
|
minus: it increases bookkeeping, and makes it more difficult for
|
|||
|
a third party to adjudicate a dispute. On the other hand it may
|
|||
|
produce greater security against certain types of attacks. In fact
|
|||
|
the k above could be chosen differently for different blocks of one
|
|||
|
message.
|
|||
|
|
|||
|
In passing we note that, like knapsacks, this scheme goes in one
|
|||
|
direction only: we have in effect
|
|||
|
|
|||
|
|
|||
|
M = E(r,s) = (x(A) * r + k * s) mod (p-1).
|
|||
|
|
|||
|
|
|||
|
This maps the ordered pair (r,s) to a unique M. The condition
|
|||
|
GCD(k,p-1) = 1 guarantees that an (r,s) can always be found; i.e.,
|
|||
|
E is surjective. But it is not injective (one-to-one): e.g., if p
|
|||
|
= 7, k = 5, x(A) = 5, then E(1,2) = E(2,1) = 3. Thus text M cannot
|
|||
|
be represented uniquely by a pair (r,s), which would lead to
|
|||
|
ambiguity in an attempt to use this scheme in two directions.
|
|||
|
|
|||
|
Also, ElGamal notes that extension to GF(pn) (app. G) is
|
|||
|
feasible. However, it is not clear that extensions to finite fields
|
|||
|
are desirable (cf. sec. 1.5); gains in efficiency may be offset by
|
|||
|
lower security for comparable key sizes.
|
|||
|
|
|||
|
|
|||
|
4.3 Examples of hash functions.
|
|||
|
|
|||
|
|
|||
|
To be useful in conjunction with public-key systems, a hash
|
|||
|
function should ideally be keyless. This is in contradistinction
|
|||
|
to message authentication codes used in connection with secret-
|
|||
|
key systems. Several hash functions have been proposed for use in
|
|||
|
public-key settings. A few are mentioned here, but it seems to be
|
|||
|
difficult to produce secure, keyless, efficient hash functions.
|
|||
|
Thus we include some examples of functions which have keys, are
|
|||
|
insecure, or both.
|
|||
|
|
|||
|
|
|||
|
4.3.1 Merkle's meta-method.
|
|||
|
|
|||
|
|
|||
|
Merkle ([MERK82],[MERK89]) has proposed a general technique for
|
|||
|
obtaining hash functions and digital signatures from existing
|
|||
|
conventional cryptosystems such as DES. Although secret-key systems
|
|||
|
are used as adjuncts, the resulting hash functions are keyless;
|
|||
|
keys needed for DES are generated from the message to be hashed.
|
|||
|
The hash functions are pre-certified in the sense that their
|
|||
|
security can often be proven to be the same as that of the
|
|||
|
underlying conventional function.
|
|||
|
|
|||
|
Merkle assumes that encryption in a system such as DES defines
|
|||
|
a function EK, where K is a key, which produces a random output.
|
|||
|
This is technically impossible, and in fact DES is not a random
|
|||
|
function since it is a permutation. Nonetheless, small deviations
|
|||
|
from randomness may be tolerable. Another requirement is that for
|
|||
|
a given key/plaintext (or ciphertext) pair, the ciphertext (or
|
|||
|
plaintext) returned will not vary with time. Normally a
|
|||
|
cryptosystem would meet this criterion.
|
|||
|
|
|||
|
Assume that a function EK(M) is available which satisfies these
|
|||
|
requirements. In deference to the potential use of DES to define
|
|||
|
E, assume K is 56 bits, M is 64 bits, and EK(M) is 64 bits. Since
|
|||
|
E may be assumed to be an encryption function, it may be assumed
|
|||
|
that there exists a decryption function with EK(DK(C)) = C. This is
|
|||
|
undesirable in producing one-way hash functions. This problem may
|
|||
|
be mitigated as follows: given a 120-bit input x, write x =
|
|||
|
CAT(K,M) where CAT denotes concatenation, K is the first 56 bits
|
|||
|
of x, and M is the last 64 bits. Let
|
|||
|
|
|||
|
|
|||
|
f(x) = EK(M) XOR M,
|
|||
|
|
|||
|
|
|||
|
where XOR is exclusive-or. Then f hashes 120 bits to 64 bits.
|
|||
|
Furthermore, Merkle claims that f produces a random output even if
|
|||
|
x is chosen non-randomly. A strong one-way hash function, as
|
|||
|
defined in section 3.2.3, meets this criterion. Thus f might be
|
|||
|
termed a fixed-size strong one-way hash function, with "fixed-
|
|||
|
size" referring to the fact that f does not accept arbitrary
|
|||
|
inputs.
|
|||
|
|
|||
|
There are various ways in which f can be extended to a one-way
|
|||
|
hash function accepting arbitrary inputs (see [MERK89]).
|
|||
|
Furthermore, it is desirable to have a function which outputs more
|
|||
|
than 64 bits, to deflect "birthday" or "square root" attacks (app.
|
|||
|
F), which are based on the statistical phenomenon that the
|
|||
|
probability of collisions produced when hashing becomes significant
|
|||
|
when the number of items hashed is around the square root of the
|
|||
|
total number of hash function values.
|
|||
|
|
|||
|
In section 3.2.3 we noted how such attacks affect the security
|
|||
|
of hash functions. For example, a 64-bit output (i.e., 264 hash
|
|||
|
values) would be vulnerable to an attack using only 232 = 4 billion
|
|||
|
messages. On the other hand, a 112-bit output would require
|
|||
|
exhaustive search of on the order of 256 values, producing a
|
|||
|
security level comparable to DES. Merkle discusses several
|
|||
|
constructions for producing an output exceeding 64 bits from f.
|
|||
|
Only the simplest construction will be discussed here. Given an
|
|||
|
input x of 119 bits, let
|
|||
|
|
|||
|
|
|||
|
CAT(f(CAT("0",x)),f(CAT("1",x))) = CAT(y,z),
|
|||
|
|
|||
|
|
|||
|
where y is 112 bits. Then define F0(x) = y. In the above, " "
|
|||
|
denotes constant bit string. We note that F0 hashes 119 bits to 112
|
|||
|
bits. This is not very efficient, but the 112-bit output will deter
|
|||
|
a birthday attack. The latter would require 256 = 7*1016 messages,
|
|||
|
which is computationally infeasible; more precisely, adequate
|
|||
|
computing power to effect a birthday attack would also break DES,
|
|||
|
thereby obliterating DES-based hash functions.
|
|||
|
|
|||
|
This produces F0 which is also a fixed-size strong one-way hash
|
|||
|
function. Finally F0 is extended to a one-way hash function F
|
|||
|
accepting inputs of arbitrary size by cascading copies of F0. Given
|
|||
|
an input x, suppose
|
|||
|
|
|||
|
|
|||
|
x = CAT(x1,...,xn),
|
|||
|
|
|||
|
|
|||
|
where n is arbitrary and each xi is 7 bits (pad x with a few zeroes
|
|||
|
if need be). Let
|
|||
|
|
|||
|
|
|||
|
R0 = 0,
|
|||
|
|
|||
|
Ri = F0(CAT(Ri-1,xi)) (1 <20> i <20> n),
|
|||
|
|
|||
|
|
|||
|
where in the first equation the right side is a string of 112
|
|||
|
zeroes. Let F(x) = Rn.
|
|||
|
|
|||
|
Now Merkle claims that F is as secure as F0. That is, if x <20> x'
|
|||
|
can be found with F(x') = F(x), then F0 can also be broken. The
|
|||
|
proof is inductive: if n = 1 we have F(x) = F0(CAT(0,x)). If F(x)
|
|||
|
= F(x') and x <20> x' let z = CAT(0,x) and z' = CAT(0,x'); then F0(z)
|
|||
|
= F0(z') and z <20> z', so that F0 is broken. Now suppose the claim is
|
|||
|
true for n. Suppose
|
|||
|
|
|||
|
|
|||
|
zi = CAT(x1,...,xi) (1 <20> i <20> n+1),
|
|||
|
|
|||
|
x = zn+1,
|
|||
|
|
|||
|
zi' = CAT(x1',...,xi') (1 <20> i <20> n+1),
|
|||
|
|
|||
|
x ' = zn+1',
|
|||
|
|
|||
|
Ri = F0(CAT(Ri-1,xi)) (1 <20> i <20> n+1),
|
|||
|
|
|||
|
Ri' = F0(CAT(Ri-1',xi')) (1 <20> i <20> n+1),
|
|||
|
|
|||
|
|
|||
|
where each xi and xi' is 7 bits. Suppose x <20> x' but F(x) = F(x'),
|
|||
|
i.e., Rn+1 = Rn+1'. Let y = CAT(Rn,xn+1) and y' = CAT(Rn',xn+1'). Then
|
|||
|
F0(y) = F0(y'). If xn+1 <20> xn+1' then y <20> y' and F0 is broken. Suppose
|
|||
|
xn+1 = xn+1'. Then Rn = Rn'; but zn <20> zn' since x <20> x'. Now we observe
|
|||
|
that by definition Ri = F(zi) and Ri' = F(zi'). Hence F(zn) = F(zn').
|
|||
|
By the induction hypothesis, F0 can be broken, completing the
|
|||
|
proof.
|
|||
|
|
|||
|
A disadvantage of this F is that it hashes 7 bits per stage of
|
|||
|
the cascade, and each stage involves two DES calculations. Thus 3.5
|
|||
|
bits are hashed per DES calculation. Merkle gives other
|
|||
|
constructions which are more complicated but hash up to 17 bits per
|
|||
|
application of DES.
|
|||
|
|
|||
|
|
|||
|
4.3.2 Coppersmith's attack on Rabin-type functions.
|
|||
|
|
|||
|
|
|||
|
The Merkle meta-method is an attempt to use a conventional
|
|||
|
system as a generator for hash functions. This type of approach has
|
|||
|
its origin in some predecessors which have been broken by
|
|||
|
combinations of birthday attacks and meet-in-the-middle attacks as
|
|||
|
formulated by Coppersmith [COPP85].
|
|||
|
|
|||
|
An early attempt to construct a hash function in support of
|
|||
|
signature schemes was given by Rabin [RABI78]. Let H0 be random
|
|||
|
(Rabin uses 0) and suppose a message M is divided into fixed-size
|
|||
|
blocks M1,...,Mn. Suppose E(K,N) represents encryption of block N
|
|||
|
with key K using a conventional system such as DES. For i = 1,..,n
|
|||
|
let
|
|||
|
|
|||
|
|
|||
|
Hi = E(Mi,Hi-1).
|
|||
|
|
|||
|
|
|||
|
Then a hash value is given by (H0,Hn). Coppersmith's attack
|
|||
|
assumes that an opponent knows H0 and Hn. He then constructs a bogus
|
|||
|
message whose hash value is also (H0,Hn). Assume blocksize is 64
|
|||
|
bits. The opponent begins by specifying M1,...,Mn-2 using H0. He then
|
|||
|
generates 232 trial values X. For each X he computes a trial Hn-1 of
|
|||
|
the form
|
|||
|
|
|||
|
|
|||
|
H(n-1,X) = E(X,Hn-2).
|
|||
|
|
|||
|
|
|||
|
He sorts these 232 values and stores them. Now he generates 232
|
|||
|
trial values Y. For each Y he computes a trial Hn-1 of the form
|
|||
|
|
|||
|
|
|||
|
H'(n-1,Y) = D(Y,Hn),
|
|||
|
|
|||
|
|
|||
|
where D is the decryption function corresponding to E. We note that
|
|||
|
H(n-1,X) is the value that Hn-1 would have if Mn-1 = X, and H'(n-
|
|||
|
1,Y) is the value Hn-1 would have if Mn = Y. Each time the opponent
|
|||
|
tries a Y he searches through the sorted H-list (about 32
|
|||
|
operations per search) and tries to find an X and Y with H(n-1,X)
|
|||
|
= H'(n-1,Y). By the birthday phenomenon (app. F), the probability
|
|||
|
of finding X and Y is at least 1/2. If X and Y are found, the
|
|||
|
opponent has obtained a bogus message with the proscribed hash
|
|||
|
value; furthermore this takes at most about 233 encryptions, 232
|
|||
|
storage and 64 * 232 comparison operations. This effectively breaks
|
|||
|
the scheme. Actually Coppersmith's attack was directed against a
|
|||
|
refinement by Davies and Price [DAVI80]; Rabin's original scheme
|
|||
|
had been broken earlier.
|
|||
|
|
|||
|
|
|||
|
4.3.3 Quadratic congruential hash functions.
|
|||
|
|
|||
|
|
|||
|
Another attempt to create hash functions, differing from both
|
|||
|
Merkle- and Rabin-type constructions, was made by Jueneman
|
|||
|
[JUEN82]. Unlike the Merkle meta-method this uses no external
|
|||
|
system as an adjunct. It is not keyless; an initialization vector
|
|||
|
is used. This limits the scope of usage; in particular, such a
|
|||
|
function is useless for signature-only schemes. Nonetheless,
|
|||
|
quadratic congruential constructions are simple and efficient, and
|
|||
|
hence would be useful in some contexts if secure. Unfortunately it
|
|||
|
seems as though Coppersmith's attack applies to these as well.
|
|||
|
|
|||
|
Jueneman uses the same partition into fixed-size blocks as
|
|||
|
above, and again begins by choosing H0 = 0. However, he also
|
|||
|
chooses a secret seed M0 which is changed every message and
|
|||
|
transmitted as a prefix to the message. Thus Assuming 32-bit
|
|||
|
blocks (to use the Mersenne prime 231-1), for i = 0,...,n he
|
|||
|
computes
|
|||
|
|
|||
|
|
|||
|
Hi+1 = (Hi + Mi)2 mod (231-1).
|
|||
|
|
|||
|
|
|||
|
Then the hash value is Hn. Coppersmith broke this first scheme.
|
|||
|
A revised scheme was proposed in [JUEN86]. The text is split into
|
|||
|
128-bit blocks, which are further divided into 4 words. Recent
|
|||
|
results suggest that this scheme may be insecure also. This is
|
|||
|
especially unfortunate in light of the fact that a hash function
|
|||
|
given in Annex D of X.509 [CCIT87] is defined similarly, via
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Hi+1 = Mi + Hi2 mod n.
|
|||
|
|
|||
|
|
|||
|
Recent work calls this into question as well.
|
|||
|
|
|||
|
|
|||
|
4.4 Hardware and software support.
|
|||
|
|
|||
|
|
|||
|
As noted earlier, RSA and similar exponentiation-based
|
|||
|
algorithms suffer from relatively low bandwidths. At a minimum this
|
|||
|
implies that supporting software needs to be carefully designed;
|
|||
|
hardware support is probably a necessity in many settings. As noted
|
|||
|
by Sedlak [SEDL87], bandwidths of less than 64 kbps (kilobits per
|
|||
|
second) will degrade performance in many networks. Furthermore,
|
|||
|
arithmetic modulo numbers of an adequate number of bits (at least
|
|||
|
512) should be supported. Essentially the requirement is a chip (or
|
|||
|
chip set) that can quickly compute quantities such as a mod b, ai
|
|||
|
mod b, and perhaps multiplicative inverses or greatest common
|
|||
|
divisors. As Sedlak notes further, a single chip is preferable for
|
|||
|
security reasons. Since off-chip communication is slower than on-
|
|||
|
chip, single-chip implementations should also yield higher
|
|||
|
bandwidths.
|
|||
|
|
|||
|
|
|||
|
4.4.1 Design considerations for RSA chips.
|
|||
|
|
|||
|
|
|||
|
Some general tradeoffs in such design schemes are discussed by
|
|||
|
Rivest [RIVE84]. He classifies architectures as serial (S),
|
|||
|
serial/parallel (S/P), or parallel/parallel (P/P). He then notes
|
|||
|
the following time and hardware costs:
|
|||
|
|
|||
|
|
|||
|
a. Multiplying two k-bit numbers modulo a k-bit number:
|
|||
|
|
|||
|
1. O(k2) time and O(1) gates on an S.
|
|||
|
|
|||
|
2. O(k) time and O(k) gates on an S/P.
|
|||
|
|
|||
|
3. O(log k) time and O(k2) gates on a P/P.
|
|||
|
|
|||
|
b. Exponentiating a k-bit number modulo a k-bit number:
|
|||
|
|
|||
|
1. O(k3) time and O(1) gates on an S.
|
|||
|
|
|||
|
2. O(k2) time and O(k) gates on an S/P.
|
|||
|
|
|||
|
3. O(k log k) time and O(k2) gates on a P/P.
|
|||
|
|
|||
|
c. Key generation, k-bit primes:
|
|||
|
|
|||
|
1. O(k4) time and O(1) gates on an S.
|
|||
|
|
|||
|
2. O(k3) time and O(k) gates on an S/P.
|
|||
|
|
|||
|
3. O(k2 log k) time and O(k2) gates on a P/P.
|
|||
|
|
|||
|
|
|||
|
This is a somewhat oversimplified version of [RIVE84] presented
|
|||
|
only for comparison purposes. Also, there are two basic assumptions
|
|||
|
used above: exponentiation is an inherently sequential process; and
|
|||
|
the 100 or so primality tests used in key generation are done
|
|||
|
sequentially. The first assumption seems intrinsic. However, the
|
|||
|
second is pragmatic: the tests all use the same hardware, and
|
|||
|
replicating the latter 100-fold for parallel execution would be
|
|||
|
highly cost-ineffective. Rivest uses the above to give some sample
|
|||
|
timings:
|
|||
|
|
|||
|
|
|||
|
a. Decryption rate, 200-digit modulus:
|
|||
|
|
|||
|
1. 0.005 kbps on an S.
|
|||
|
|
|||
|
2. 1.3 kbps on an S/P.
|
|||
|
|
|||
|
3. 95 kbps on a P/P.
|
|||
|
|
|||
|
b. Key generation, 100-digit primes:
|
|||
|
|
|||
|
1. 1,200,000 ms = 20 minutes on an S.
|
|||
|
|
|||
|
2. 5,000 ms = 5 seconds on an S/P.
|
|||
|
|
|||
|
3. 70 ms on a P/P.
|
|||
|
|
|||
|
|
|||
|
It may be seen that reasonably high bandwidths can be achieved,
|
|||
|
but the time/cost tradeoff is significant.
|
|||
|
|
|||
|
|
|||
|
4.4.2 Proposed designs for RSA chips.
|
|||
|
|
|||
|
|
|||
|
Various authors have proposed designs for chips supporting RSA.
|
|||
|
Of course such chips could also support other exponential-based
|
|||
|
algorithms.
|
|||
|
|
|||
|
Orton et. al. [ORTO86] discuss an implementation of RSA in 2 um
|
|||
|
CMOS which should encrypt at 40 kbps for 512-bit moduli.
|
|||
|
|
|||
|
Sedlak [SEDL87] discusses a highly-optimized chip which makes
|
|||
|
substantial usage of lookahead. Thus the number of cycles required
|
|||
|
for exponentiation is not fixed; analysis of expected time is
|
|||
|
performed using a probabilistic finite state machine (see app. D).
|
|||
|
Support is provided not only for RSA but also for the ISO hash
|
|||
|
function (see above). Sedlak claims a deciphering rate of nearly
|
|||
|
200 kbps is achievable for 780-bit moduli using a single 160,000-
|
|||
|
transistor chip with dual ciphering units, in 1.5 um CMOS. He also
|
|||
|
claims a key generation time of 2 seconds. A 5,000-transistor, 5
|
|||
|
um CMOS prototype has been realized.
|
|||
|
|
|||
|
In [BRIC89] it is noted that chips capable of up to 450 kbps are
|
|||
|
being designed.
|
|||
|
|
|||
|
|
|||
|
5. Implementations of public-key cryptography.
|
|||
|
|
|||
|
|
|||
|
We examine here some existing implementations of public-key
|
|||
|
cryptography, some implementations which are in progress, and some
|
|||
|
which have been proposed.
|
|||
|
|
|||
|
|
|||
|
5.1 MITRENET.
|
|||
|
|
|||
|
|
|||
|
One of the earliest implementations of public-key cryptography
|
|||
|
was in the MEMO (MITRE Encrypted Mail Office) system, a secure
|
|||
|
electronic mail system for MITRENET ([SCHA82],[SCHA80]). MITRENET
|
|||
|
is a broadband cable system with a bandwidth of 1 mbps. It uses a
|
|||
|
carrier sense protocol (e.g., [TANE81]); i.e., each station can
|
|||
|
sense transmissions of all other stations. In fact the protocol
|
|||
|
requires all parties to monitor all communication, in effect
|
|||
|
requiring passive eavesdropping. A priori this provides no secrecy,
|
|||
|
authentication or integrity services. Furthermore it employs
|
|||
|
distributed switching, creating a potential for active intrusion.
|
|||
|
This is a good setting for a privacy enhancement testbed.
|
|||
|
|
|||
|
The MEMO system is a hybrid public/private cryptosystem. DES is
|
|||
|
used for data encryption. The Diffie/Hellman exponential key
|
|||
|
exchange of section 2.2 is used for establishment of secret keys.
|
|||
|
To implement Diffie/Hellman, use of GF(2n), with 2n - 1 a prime
|
|||
|
(called a Mersenne prime), was chosen for efficiency of
|
|||
|
implementation via linear feedback shift registers. Unfortunately
|
|||
|
the MEMO implementors used n = 127; the work of Adleman [ADLE79]
|
|||
|
rendered this choice insecure even before the system was
|
|||
|
implemented. This is noted by Schanning; in fact the use of n = 521
|
|||
|
is recommended in [SCHA82], suggesting that the MEMO system was
|
|||
|
intended mainly for experimental purposes.
|
|||
|
|
|||
|
In the MEMO system, a Public Key Distribution Center is a
|
|||
|
separate network node containing public components in EPROM.
|
|||
|
Private components can be generated by users or by the system.
|
|||
|
|
|||
|
Each user workstation establishes secure communication with the
|
|||
|
Public Key Distribution Center. A session begins with the user
|
|||
|
requesting the file of public keys from the PKDC. The request is
|
|||
|
honored if it passes an identification test involving the user's
|
|||
|
private component. The file of public keys is then downloaded to
|
|||
|
the user's workstation, encrypted with DES to ensure integrity.
|
|||
|
|
|||
|
When the user sends a message to another user, the workstation
|
|||
|
generates a random document key. The latter is used to DES-encrypt
|
|||
|
the message. The public key of the recipient is used to generate
|
|||
|
a key-encrypting key which is used to DES-encrypt the document key.
|
|||
|
|
|||
|
There is no provision for lost keys. Some provision is made for
|
|||
|
detecting modifications to messages, using checksums. However, the
|
|||
|
use of Diffie/Hellman alone does not permit authentication to be
|
|||
|
introduced.
|
|||
|
|
|||
|
|
|||
|
5.2 ISDN.
|
|||
|
|
|||
|
|
|||
|
In [DIFF87] a testbed secure Integrated Services Digital Network
|
|||
|
terminal developed at Bell-Northern Research is described. It can
|
|||
|
carry voice or data at 64 kbps. Public-key cryptography is used for
|
|||
|
both key exchange and authentication. Reference to the
|
|||
|
Diffie/Hellman exponential key exchange is made. Evidently it is
|
|||
|
used in conjunction with DES. The article also alludes to
|
|||
|
signatures, but implementation is unclear.
|
|||
|
|
|||
|
As noted in [DIFF88], the use of public-key in conjunction with
|
|||
|
DES provides good security. In particular, the exponential key
|
|||
|
exchange permits a session key unique to each call. Thus if long-
|
|||
|
term keys are compromised, recordings of calls made prior to
|
|||
|
compromise cannot be decoded. In conventional systems the
|
|||
|
compromise of a long-term key may compromise communications made
|
|||
|
previously with derived keys.
|
|||
|
|
|||
|
Public key computations in the terminal are implemented via a
|
|||
|
DSP (digital signal processing) chip, while an off-the-shelf
|
|||
|
integrated circuit implements DES, which is used for data
|
|||
|
encryption. Key management involves keys installed in phones,
|
|||
|
carried by users, and exchanged electronically.
|
|||
|
|
|||
|
Each BNR terminal incorporates a Northern Telecom M3000
|
|||
|
Touchphone.
|
|||
|
|
|||
|
|
|||
|
5.2.1 Keys.
|
|||
|
|
|||
|
|
|||
|
A public/private component pair is embedded in the phone; this
|
|||
|
pair is called the intrinsic key. The private component is
|
|||
|
contained in a tamper-resistant compartment of the phone. The
|
|||
|
public component serves as the name of the phone. These cannot be
|
|||
|
altered.
|
|||
|
|
|||
|
A second long-term public key stored in the phone is the owner
|
|||
|
key. This is used to authenticate commands from the owner. It can
|
|||
|
be changed by a command signed with the current owner key, thus
|
|||
|
permitting transfer to a new owner.
|
|||
|
|
|||
|
A third long-term public key in the phone is the network key.
|
|||
|
This identifies the network with which the phone is associated. It
|
|||
|
validates commands signed with the private component of the
|
|||
|
network's key management facility. It can authenticate calls from
|
|||
|
network users. It can be changed by a command signed by the owner
|
|||
|
key.
|
|||
|
|
|||
|
A short-term component pair stored in the phone is the working
|
|||
|
pair. These are embodied in a certificate signed by the key
|
|||
|
management facility. During the setup process for a call, phones
|
|||
|
exchange certificates. The network key is used to authenticate
|
|||
|
certificates. This permits station-to-station calls.
|
|||
|
|
|||
|
Further information is needed for authenticated person-to-
|
|||
|
person calls. This information is contained on a hardware "ignition
|
|||
|
key" which must be inserted into the phone. This key contains the
|
|||
|
user's private component encrypted under a secret password known
|
|||
|
only to the user. It also contains a certificate signed by the KMF
|
|||
|
which contains the user's public component and identifying
|
|||
|
information. The latter is encrypted as well. Decryption of the
|
|||
|
information on the ignition key is effected via a password typed
|
|||
|
on the telephone touchpad.
|
|||
|
|
|||
|
Further certificates authorizing users to use particular phones
|
|||
|
are acquired by the phone from the key management facility; these
|
|||
|
are cached and replaced in FIFO fashion.
|
|||
|
|
|||
|
|
|||
|
5.2.2 Calling.
|
|||
|
|
|||
|
|
|||
|
A person-to-person call begins as follows: the caller inserts
|
|||
|
his ignition key and dials the number. The phone interrogates the
|
|||
|
ignition key to check the caller's identity. The phone then checks
|
|||
|
its cache for an authorization certificate for the caller. If not
|
|||
|
found it is acquired by the phone from the KMF. The phone then
|
|||
|
dials the number of the other phone.
|
|||
|
|
|||
|
The two phones then set-up. This begins with an exponential key
|
|||
|
exchange. The calling phone then transmits its certificate and user
|
|||
|
authorization. The receiving phone authenticates the signatures on
|
|||
|
both of the latter using the network key. The receiving phone then
|
|||
|
employs challenges. It demands real-time responses to time-
|
|||
|
dependent messages; the responses must be signed. This ensures that
|
|||
|
certificates are not played back from a previous conversation. One
|
|||
|
response is signed by the calling phone; another with the user's
|
|||
|
ignition key. A further level of security may be obtained via the
|
|||
|
ISDN D channel, which makes calling party identification available
|
|||
|
from the network without interrupting the primary call.
|
|||
|
|
|||
|
Now the called phone sends its certificates and responds to
|
|||
|
challenges as above. If the called party is home he inserts his
|
|||
|
ignition key. If the called phone does not have authorization for
|
|||
|
the called party to use the phone, it must obtain a certificate.
|
|||
|
Again this can be accomplished via the D channel without
|
|||
|
interrupting the call. The called party then undergoes challenge
|
|||
|
and response. Finally the conversation ensues.
|
|||
|
|
|||
|
|
|||
|
5.3 ISO Authentication Framework.
|
|||
|
|
|||
|
|
|||
|
Public-key cryptography has been recommended for use in
|
|||
|
connection with the ISO authentication framework, X.509 [CCIT87].
|
|||
|
This is based on the Directory, a collection of services and
|
|||
|
databases which provide an authentication service. Authentication
|
|||
|
refers to verification of the identity of a communicating party.
|
|||
|
Strong authentication uses cryptography. The credentials of a
|
|||
|
communicating party may be obtained from the Directory.
|
|||
|
|
|||
|
No specific cryptosystem or hash function is endorsed in support
|
|||
|
of strong authentication; however, it is specified in [CCIT87] that
|
|||
|
a cryptosystem should be usable for both secrecy and authenticity.
|
|||
|
That is, the encryption and decryption transformations should be
|
|||
|
inverses, as is the case with RSA. Multiple cryptosystems and hash
|
|||
|
functions may be used in the system.
|
|||
|
|
|||
|
A user must possess a distinguished name. Naming Authorities are
|
|||
|
responsible for assigning unique names. The crux of the
|
|||
|
authentication framework is the binding of user names and public
|
|||
|
components. Assuming for the moment that such binding has occurred,
|
|||
|
subsequent authentication in the ISO framework consists of locating
|
|||
|
a chain of trusted points within the Directory. Such a chain exists
|
|||
|
if there is a common point of trust between two authenticating
|
|||
|
parties.
|
|||
|
|
|||
|
|
|||
|
5.3.1 Use of certificates.
|
|||
|
|
|||
|
|
|||
|
The X.509 public-component management system is certificate-
|
|||
|
based. Binding of a user's name and public component occurs when
|
|||
|
a Certification Authority issues a certificate to a user. The
|
|||
|
certificate contains the user's public component and distinguished
|
|||
|
name, and the certificate's validity period. It is generated off-
|
|||
|
line and signed by the CA using the CA's private component.
|
|||
|
Normally a user would generate his own public/private component
|
|||
|
pair and transmit the public component to the CA for inclusion in
|
|||
|
the certificate. At the user's request the CA may also generate the
|
|||
|
user's public/private component pair.
|
|||
|
|
|||
|
The CA vouches for the binding of the user's name and public
|
|||
|
component. The CA must not issue multiple certificates with one
|
|||
|
name. Also, a CA must keep his private component secret; compromise
|
|||
|
would affect not only the CA but also the integrity of
|
|||
|
communications involving users certified by the CA.
|
|||
|
|
|||
|
Obtaining a certificate from a CA requires a secure
|
|||
|
communication between the user and CA. In particular, the integrity
|
|||
|
of the user's public component must be assured. This communication
|
|||
|
can be on-line, off-line, or both for redundancy.
|
|||
|
|
|||
|
The user receives a copy of the certificate obtained from the
|
|||
|
CA. This can be cached; e.g., a component pair could be stored on
|
|||
|
a smart card along with the user's certificate and the CA's
|
|||
|
certificate. Additionally, certificates are entered in the
|
|||
|
Directory. The user may place a copy of the certificate in the
|
|||
|
Directory, or the CA may be authorized to do this. A user's
|
|||
|
Directory entry may contain multiple certificates. A CA's entry in
|
|||
|
the DIT contains the certificates issued for it by other CAs, as
|
|||
|
well as certificates it issues for other nodes.
|
|||
|
|
|||
|
Semi-formally a certificate may be defined as follows:
|
|||
|
|
|||
|
|
|||
|
certificate ::=
|
|||
|
{
|
|||
|
signature algorithm identifier;
|
|||
|
issuer name;
|
|||
|
validity period;
|
|||
|
subject name;
|
|||
|
subject information
|
|||
|
}
|
|||
|
|
|||
|
validity period ::=
|
|||
|
{
|
|||
|
start date;
|
|||
|
finish date
|
|||
|
}
|
|||
|
|
|||
|
subject information ::=
|
|||
|
{
|
|||
|
subject public key;
|
|||
|
public key algorithm identifier
|
|||
|
}
|
|||
|
|
|||
|
|
|||
|
This format permits usage of different algorithms. For a more
|
|||
|
formal description of relevant formats using ASN.1 see annexes G
|
|||
|
and H of [CCIT87].
|
|||
|
|
|||
|
|
|||
|
5.3.2 Certification paths.
|
|||
|
|
|||
|
|
|||
|
An associated data structure is the Directory Information Tree
|
|||
|
(DIT). Certification Authorities are otherwise undistinguished
|
|||
|
users who are nodes in the DIT. A user may have certificates issued
|
|||
|
by several CAs. Thus the authentication structure, despite the use
|
|||
|
of the term DIT, is not tree-structured. Instead it may be modeled
|
|||
|
as a directed graph.
|
|||
|
|
|||
|
A certification path consists of certificates of nodes in the
|
|||
|
DIT. The public component of the first node is used to initiate a
|
|||
|
domino-type process which ultimately unlocks the whole path,
|
|||
|
leading to recovery of the public component of the final node. The
|
|||
|
simplest path is of the form (A,B), where A is a CA for B. Then a
|
|||
|
knowledge of the public component of A permits recovery of the
|
|||
|
public component of B from the certificate issued by A for B, since
|
|||
|
the latter is signed using the private transformation of A. This
|
|||
|
is readily extended by recursion: in a certification path A1,...,An,
|
|||
|
knowing the public component of Ai permits recovery of the public
|
|||
|
component of Ai+1 from the certificate for Ai+1 issued by Ai.
|
|||
|
|
|||
|
For a user A to obtain B's certificate involves finding a common
|
|||
|
trusted point, i.e., a node which has certification paths to the
|
|||
|
two users individually. Joining these two paths produces a
|
|||
|
certification path between A and B. The paths, if they exist, may
|
|||
|
be obtained from the Directory.
|
|||
|
|
|||
|
Although there is no restriction placed on the structure of the
|
|||
|
authentication graph, an important special case is when it is tree-
|
|||
|
structured. In this event the CAs are arranged hierarchically;
|
|||
|
hence each node (except the root) has a unique CA (its parent in
|
|||
|
the tree). Then each CA stores the certificate obtained from its
|
|||
|
superior CA, as well as various certificates issued by it. The
|
|||
|
common trusted point for a pair of users is the root of the DIT.
|
|||
|
A user A may cache the certificates of nodes along the path from
|
|||
|
A to the root. The other half of the path to another user B is
|
|||
|
obtained by conjoining the path from the root to B.
|
|||
|
|
|||
|
More generally, a user A who communicates frequently with users
|
|||
|
certified by a particular CA could store paths to and from that CA
|
|||
|
(these may be different in the non-hierarchical case). Then to
|
|||
|
communicate with a given user B certified by that CA, A need only
|
|||
|
consult the directory entry for the CA and obtain the certificate
|
|||
|
of B.
|
|||
|
|
|||
|
A related concept is cross-certification: if two CAs C1 and C2
|
|||
|
have certified users who communicate frequently, C1 and C2 may
|
|||
|
certify each other. Then the certificate issued by C1 for C2 can be
|
|||
|
stored in the directory entry of C1 and vice-versa. We note that in
|
|||
|
a hierarchical system, a priori a directory entry for a node
|
|||
|
contains only the certificate of a node's superior and the reverse
|
|||
|
certificate; if cross-certification is permitted then entries
|
|||
|
contain an indefinite number of certificates.
|
|||
|
|
|||
|
A user may cache certificates of other users. A CA may add
|
|||
|
another's certificate to its directory entry.
|
|||
|
|
|||
|
|
|||
|
5.3.3 Expiration and revocation of certificates.
|
|||
|
|
|||
|
When a certificate expires it should be removed from the
|
|||
|
Directory. Expired certificates should be retained by the issuing
|
|||
|
CAs for a period of time in support of the nonrepudiation service.
|
|||
|
|
|||
|
Revocation of certificates may occur because of component
|
|||
|
compromise involving either the user or the issuing CA. Revocation
|
|||
|
may also be necessary for administrative reasons, e.g., when a CA
|
|||
|
is no longer authorized to certify a user. A CA keeps a time-
|
|||
|
stamped list of revoked certificates which the CA had issued, and
|
|||
|
a list of revoked certificates issued by other CAs certified by the
|
|||
|
first CA. Entries for CAs in the Directory should contain
|
|||
|
revocation lists for users and CAs.
|
|||
|
|
|||
|
|
|||
|
5.3.4 Authentication protocols.
|
|||
|
|
|||
|
|
|||
|
Suppose A wishes to engage in communication with an
|
|||
|
authenticated B. Suppose further that A has obtained a
|
|||
|
certification path from A to B, e.g., by accessing the Directory,
|
|||
|
and has utilized the path to obtain B's public component. Then A
|
|||
|
may initiate one-, two-, or three-way authentication protocols.
|
|||
|
|
|||
|
One-way authentication involves a single communication from A to
|
|||
|
B. It establishes the identities of A and B and the integrity of
|
|||
|
any communicated information. It also deflects replay in
|
|||
|
communication of authentication information.
|
|||
|
|
|||
|
Two-way authentication adds a reply from B. It establishes that
|
|||
|
the reply was sent by B and that information in the reply had
|
|||
|
integrity and was not replayed. It also establishes secrecy of the
|
|||
|
two communications. Both one-way and two-way authentication use
|
|||
|
timestamps. Three-way authentication adds a further message from
|
|||
|
A to B, and obviates the necessity of timestamps.
|
|||
|
|
|||
|
Let
|
|||
|
|
|||
|
|
|||
|
IA = identity of A,
|
|||
|
|
|||
|
IB = identity of B,
|
|||
|
|
|||
|
DA = private transformation of A,
|
|||
|
|
|||
|
EA = public transformation of A,
|
|||
|
|
|||
|
DB = private transformation of B,
|
|||
|
|
|||
|
EB = public transformation of B,
|
|||
|
|
|||
|
TA = timestamp by A,
|
|||
|
|
|||
|
TB = timestamp by B,
|
|||
|
|
|||
|
RA = random number generated by A,
|
|||
|
|
|||
|
RB = random number generated by B,
|
|||
|
|
|||
|
CA = certification path from A to B.
|
|||
|
|
|||
|
|
|||
|
Identities refer to the distinguished names of A and B. A
|
|||
|
timestamp included in a message M includes an expiration date for
|
|||
|
M. Optionally, it also may include the time of generation of M.
|
|||
|
Random numbers may be supplemented with sequence numbers; they
|
|||
|
should not be repeated within the expiration period indicated by
|
|||
|
a timestamp in the same communication.
|
|||
|
|
|||
|
The one-way protocol is as follows:
|
|||
|
|
|||
|
|
|||
|
a. A:
|
|||
|
|
|||
|
1. generates an RA.
|
|||
|
|
|||
|
2. constructs message M = (TA,RA,IB,<data>) where <data> is
|
|||
|
arbitrary. The latter may include data encrypted under
|
|||
|
EB for secrecy, e.g., when A is sending a data-
|
|||
|
encrypting key to B.
|
|||
|
|
|||
|
3. sends (CA,DA(M)) to B.
|
|||
|
|
|||
|
b. B:
|
|||
|
|
|||
|
1. decrypts CA and obtains EA. Also checks certificate
|
|||
|
expiration dates.
|
|||
|
|
|||
|
2. uses EA to decrypt DA(M), verifying both A's signature
|
|||
|
and the integrity of the signed information.
|
|||
|
|
|||
|
3. checks the IB contained in M for accuracy.
|
|||
|
|
|||
|
4. checks the TA in M for currency.
|
|||
|
|
|||
|
5. optionally, checks the RA in M for replay.
|
|||
|
|
|||
|
|
|||
|
The one-way protocol is illustrated below, with CA denoting CA,
|
|||
|
RA denoting RA, etc.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
A: B:
|
|||
|
____________________ _________________
|
|||
|
| | _____\| |
|
|||
|
| generate RA | /|\ /| receive (CA,M') |
|
|||
|
|____________________| | |_________________|
|
|||
|
| | |
|
|||
|
| | |
|
|||
|
________\|/_________ | _________\|/_________
|
|||
|
| | | | |
|
|||
|
| obtain TA,IB | | | recover EA from CA |
|
|||
|
|____________________| | |_____________________|
|
|||
|
| | |
|
|||
|
| | |
|
|||
|
_________\|/__________ | _________\|/_________
|
|||
|
| | | | |
|
|||
|
| compute M' = | | | compute (TA,RA,IB) |
|
|||
|
| DA(TA,RA,IB) | | | = EA(M') |
|
|||
|
|______________________| | |_____________________|
|
|||
|
| | |
|
|||
|
| | |
|
|||
|
________\|/________ | _________\|/_________
|
|||
|
| | | | |
|
|||
|
| send (CA,M') to B | | | verify TA,RA,IB |
|
|||
|
|___________________| | |_____________________|
|
|||
|
| |
|
|||
|
| |
|
|||
|
\|/________________\|
|
|||
|
/
|
|||
|
|
|||
|
Figure 8. One-Way Authentication Protocol
|
|||
|
|
|||
|
|
|||
|
The two-way protocol is:
|
|||
|
|
|||
|
|
|||
|
a. as above.
|
|||
|
|
|||
|
b. as above.
|
|||
|
|
|||
|
c. B:
|
|||
|
|
|||
|
1. generates an RB.
|
|||
|
|
|||
|
2. constructs M' = (TB,RB,IA,RA,<data>) where RA was
|
|||
|
obtained previously and <data> may include data
|
|||
|
encrypted using EA.
|
|||
|
|
|||
|
3. sends DB(M') to A.
|
|||
|
|
|||
|
d. A:
|
|||
|
|
|||
|
1. decrypts DB(M'), verifying B's signature and the
|
|||
|
integrity of the enclosed information.
|
|||
|
|
|||
|
2. checks the IA contained in M' for accuracy.
|
|||
|
|
|||
|
3. checks the TB in M' for currency.
|
|||
|
|
|||
|
4. optionally checks RB for replay.
|
|||
|
|
|||
|
|
|||
|
The three-way protocol is:
|
|||
|
|
|||
|
|
|||
|
a. A:
|
|||
|
|
|||
|
1. generates an RA.
|
|||
|
|
|||
|
2. constructs M = (TA,RA,IB,<data>). Unlike the previous
|
|||
|
cases, TA may be zero.
|
|||
|
|
|||
|
3. sends (CA,DA(M)) to B.
|
|||
|
|
|||
|
b. B:
|
|||
|
|
|||
|
1. decrypts CA and obtains EA. Also checks certificate
|
|||
|
expiration dates.
|
|||
|
|
|||
|
2. uses EA to decrypt DA(M), verifying both A's signature
|
|||
|
and the integrity of the signed information.
|
|||
|
|
|||
|
3. checks the IB contained in M for accuracy.
|
|||
|
|
|||
|
4. optionally, checks the RA in M for replay.
|
|||
|
|
|||
|
5. generates an RB.
|
|||
|
|
|||
|
6. constructs M' = (TB,RB,IA,RA,<data>) where RA was
|
|||
|
obtained previously; TB may be zero.
|
|||
|
|
|||
|
7. sends DB(M') to A.
|
|||
|
|
|||
|
c. A:
|
|||
|
|
|||
|
1. decrypts DB(M'), verifying B's signature and the
|
|||
|
integrity of the enclosed information.
|
|||
|
|
|||
|
2. checks the IA contained in M' for accuracy.
|
|||
|
|
|||
|
3. optionally checks RB for replay.
|
|||
|
|
|||
|
4. checks the received version of RA against the version
|
|||
|
sent to B.
|
|||
|
|
|||
|
5. sends DA(RB) to B.
|
|||
|
|
|||
|
d. B:
|
|||
|
|
|||
|
1. decrypts DA(RB), verifying the signature and data
|
|||
|
integrity.
|
|||
|
|
|||
|
2. checks the RB received against the value sent to A.
|
|||
|
|
|||
|
|
|||
|
Remarks: it has been noted that there are some potential
|
|||
|
problems with these protocols. For example, in the three-way
|
|||
|
version, it would be better to have A send DA(RB,IB) to B rather
|
|||
|
than just DA(RB). This would prevent a third party from intercepting
|
|||
|
random numbers and using them to subvert the protocol.
|
|||
|
|
|||
|
Also, authentication tokens may be of the form M = (TA,RA,IB,RB,
|
|||
|
EB(encdata)). Then encrypted data is signed, which may cause
|
|||
|
problems. For example, suppose C intercepts DA(M) on its way to B.
|
|||
|
Then C may decrypt M and construct (TC,RC,IB,RB,EB(encdata)). In a
|
|||
|
communication between B and C, B may think that EB(encdata) was
|
|||
|
generated by C and inadvertently reveal encdata to C. In
|
|||
|
particular, encdata may have included a data-encrypting key to be
|
|||
|
used by A and B. A solution to this problem is to let M =
|
|||
|
(TA,RA,IB,RB,encdata), M' = (TA,RA,IB,RB,EB(encdata)), and M" =
|
|||
|
(M',DA(M)), then send M".
|
|||
|
|
|||
|
|
|||
|
5.3.5 Further notes.
|
|||
|
|
|||
|
|
|||
|
Authentication uses a hash function. Signed information includes
|
|||
|
identifications of the hash function used to produce the message
|
|||
|
digest and the decryption function used to generate the digital
|
|||
|
signature. Timestamps and random numbers are included in messages
|
|||
|
to prevent replays and forgery.
|
|||
|
|
|||
|
Annex C of [CCIT87] mentions RSA as an example of a public-key
|
|||
|
system. A recommendation of a 512-bit modulus is made. It is also
|
|||
|
recommended that a common public exponent of e = 216 + 1 be used
|
|||
|
(the fourth Fermat number). In particular it is noted that a
|
|||
|
smaller e would be vulnerable to ciphertext-only attacks.
|
|||
|
|
|||
|
Other annexes specify a strong hash function as defined in
|
|||
|
section 4, and the ASN.1 syntax for the authentication framework.
|
|||
|
Algorithm identifiers are included in ASN.
|
|||
|
|
|||
|
|
|||
|
5.4 DARPA-Internet.
|
|||
|
|
|||
|
|
|||
|
The Privacy and Security Research Group is in the process of
|
|||
|
developing a proposal for privacy-enhanced electronic mail for the
|
|||
|
DARPA-Internet community. Since this is work in progress we give
|
|||
|
only a very brief description here. Details on the current state
|
|||
|
of this project (at the time of this writing) may be found in
|
|||
|
[IAB-90],[LINN89].
|
|||
|
|
|||
|
Public-key cryptography has been recommended for distribution
|
|||
|
of secret keys and in support of digital signatures. DES will be
|
|||
|
used for encryption of messages and can be used for Message
|
|||
|
Integrity Check (MIC) computations. RSA has been recommended for
|
|||
|
key distribution and digital signatures. The hash functions
|
|||
|
currently supported are MD2 and MD4 [RIVE90]. Fields are included
|
|||
|
in messages to identify cryptographic algorithms and hash
|
|||
|
functions. It is specified that all implementations should support
|
|||
|
RSA and DES.
|
|||
|
|
|||
|
Much of the authentication framework is based on a subset of
|
|||
|
X.509. In particular, the recommended public component management
|
|||
|
system is certificate-based.
|
|||
|
|
|||
|
|
|||
|
6. A sample proposal for a LAN implementation.
|
|||
|
|
|||
|
|
|||
|
We present here a sample proposal for the implementation of
|
|||
|
privacy enhancement in a packet-switched local area network, using
|
|||
|
public-key cryptography for key management and authentication. The
|
|||
|
main purpose is to explore the relevant decision-making process.
|
|||
|
In particular, some services will be needed in some settings but
|
|||
|
not others, and hence a monolithic structure incorporating all
|
|||
|
conceivable services would be inappropriate. One approach to the
|
|||
|
design of a generic structure is layered, with a kernel consisting
|
|||
|
of the most basic services and outer layers added as desired. This
|
|||
|
is the paradigm we adopt here. The sample proposal presented here
|
|||
|
is not unique, and is intended for illustration purposes only.
|
|||
|
|
|||
|
A hybrid of public-key cryptography and conventional
|
|||
|
cryptography presents advantages. The former is used for signatures
|
|||
|
and for distribution of secret keys used in the latter; the latter
|
|||
|
is used for bulk data encryption. In addition, a hash function is
|
|||
|
needed so that only a compressed form of long text need be signed.
|
|||
|
We do not endorse specific public-key systems or hash functions.
|
|||
|
The conventional system could be taken to be DES.
|
|||
|
|
|||
|
|
|||
|
6.1 Integration into a network.
|
|||
|
|
|||
|
|
|||
|
There are basically two modes of implementation of encryption
|
|||
|
in a network (e.g., [DIFF84],[DIFF86],[TANE81]), namely link and
|
|||
|
end-to-end.
|
|||
|
|
|||
|
Link encryption provides good protection against external
|
|||
|
threats such as traffic analysis because all data flowing on links
|
|||
|
can be encrypted, including addresses. Entire packets, including
|
|||
|
addresses, are encrypted on exit from, and decrypted on entry to,
|
|||
|
a node. Link encryption is easy to incorporate into network
|
|||
|
protocols.
|
|||
|
|
|||
|
On the other hand, link encryption has a major disadvantage: a
|
|||
|
message is encrypted and decrypted several times. If a node is
|
|||
|
compromised, all traffic flowing through that node is also
|
|||
|
compromised. A secondary disadvantage is that the individual user
|
|||
|
loses control over algorithms used.
|
|||
|
|
|||
|
In end-to-end encryption, a message is encrypted and decrypted
|
|||
|
only at endpoints, thereby largely circumventing problems with
|
|||
|
compromise of intermediate nodes. However, some address information
|
|||
|
(data link headers) must be left unencrypted to allow nodes to
|
|||
|
route packets. Also, high-level network protocols must be augmented
|
|||
|
with a separate set of cryptographic protocols.
|
|||
|
|
|||
|
Here we assume end-to-end encryption. In terms of the OSI model,
|
|||
|
encryption can occur at various levels, including application,
|
|||
|
presentation, network or transport. As noted in [ISO-87], the
|
|||
|
appropriate level depends on desired granularity of protection. In
|
|||
|
particular, high granularity refers to separate keys for each
|
|||
|
application or user and assurance of integrity. For this
|
|||
|
granularity the presentation or application layers are most
|
|||
|
appropriate. These two layers will be assumed here. In particular,
|
|||
|
integration at the application layer gives the individual user
|
|||
|
complete control over the algorithms used.
|
|||
|
|
|||
|
|
|||
|
6.2 Security threats.
|
|||
|
|
|||
|
|
|||
|
Some basic security threats (cf. ann. A of [CCIT87]) include:
|
|||
|
|
|||
|
|
|||
|
a. masquerade
|
|||
|
|
|||
|
b. replay
|
|||
|
|
|||
|
c. interception of data
|
|||
|
|
|||
|
d. manipulation of messages
|
|||
|
|
|||
|
e. repudiation
|
|||
|
|
|||
|
|
|||
|
Masquerade refers to users representing themselves as other
|
|||
|
users. Replay refers to recording and re-sending a message at a
|
|||
|
later time. Interception of data refers to passive eavesdropping
|
|||
|
on communications. Manipulation refers to unauthorized insertions,
|
|||
|
deletions or other changes to messages. Repudiation refers to
|
|||
|
denial of sending (or possibly receipt) of a message.
|
|||
|
|
|||
|
There are other threats which are outside the present scope per
|
|||
|
se. For example, mis-routing of packets naturally occurs in OSI
|
|||
|
layers 1-3, and we are restricting ourselves to higher layers.
|
|||
|
|
|||
|
|
|||
|
6.3 Security services.
|
|||
|
|
|||
|
|
|||
|
Again from annex A of [CCIT87], some of the most basic security
|
|||
|
services which can be provided include:
|
|||
|
|
|||
|
|
|||
|
a. authentication
|
|||
|
|
|||
|
b. secrecy
|
|||
|
|
|||
|
c. integrity
|
|||
|
|
|||
|
d. nonrepudiation
|
|||
|
|
|||
|
|
|||
|
Authentication refers to verification of the identity of the
|
|||
|
sender or receiver of a communication. It can protect against
|
|||
|
masquerade. It may also provide protection against replay,
|
|||
|
depending on implementation. Secrecy refers to protection against
|
|||
|
interception of data. Integrity refers to protection against
|
|||
|
manipulation (including accidental) of data. Nonrepudiation refers
|
|||
|
to protection against denial of sending (or possibly receipt) of
|
|||
|
a message.
|
|||
|
|
|||
|
The kernel of a proposed system would include basic support for
|
|||
|
the above services. This kernel could be standardized to a large
|
|||
|
extent. However, outer layers of an implementation would need to
|
|||
|
interface with various external frameworks as well. For example,
|
|||
|
a system is needed to bind user public components and user
|
|||
|
identities; this forms an important part of the authentication
|
|||
|
service. Also, support for nonrepudiation is a complex matter as
|
|||
|
we have noted. A public-key signature system implements basic
|
|||
|
nonrepudiation of sending automatically, but does not a priori
|
|||
|
protect against repudiation of sending due to compromised private
|
|||
|
components; nor does it provide proof of receipt. Thus (4) is an
|
|||
|
example of a service which relies heavily on an interface with an
|
|||
|
external system which most likely would be implementation-
|
|||
|
dependent, since its structure depends on considerations such as
|
|||
|
contractual agreements which cannot be incorporated into a generic
|
|||
|
structure.
|
|||
|
|
|||
|
There are other services which could be provided as well. One
|
|||
|
example is access control with differing capabilities for different
|
|||
|
classes of users. However, a public key system does not provide
|
|||
|
this type of service per se, since it would require restricted
|
|||
|
access to public components. This type of service is thus another
|
|||
|
example of a layer which could be added in a given implementation,
|
|||
|
e.g. by centralized key distribution which might be considered
|
|||
|
undesirable in many settings.
|
|||
|
|
|||
|
|
|||
|
6.4 Security mechanisms.
|
|||
|
|
|||
|
|
|||
|
Once more we follow annex A of [CCIT87], which identifies some
|
|||
|
of the basic mechanisms which can implement security services.
|
|||
|
These include:
|
|||
|
|
|||
|
|
|||
|
a. encryption
|
|||
|
|
|||
|
b. manipulation detection codes
|
|||
|
|
|||
|
c. signatures
|
|||
|
|
|||
|
d. authentication framework
|
|||
|
|
|||
|
|
|||
|
Encryption refers to application of cryptographic
|
|||
|
transformations to messages or keys; it implements secrecy.
|
|||
|
Manipulation detection can be effected via hash functions producing
|
|||
|
compressed versions of the text. Manipulation detection in
|
|||
|
conjunction with authentication implements integrity. Signature
|
|||
|
refers to application of private components to message digests
|
|||
|
(output of hash functions); it implements authentication and basic
|
|||
|
nonrepudiation, in concert with an authentication framework. The
|
|||
|
form of the latter is implementation-dependent. For example, a
|
|||
|
directory service might be provided, along with "hot lists" of
|
|||
|
compromised keys.
|
|||
|
|
|||
|
The four mechanisms above may be regarded as the kernel of an
|
|||
|
implementation. Various other mechanisms which could be provided
|
|||
|
are noted, e.g., in [ISO-87]. For example, to guard against replay,
|
|||
|
timestamps using synchronized clocks might be provided. Another
|
|||
|
possibility is the addition of a handshaking protocol. For
|
|||
|
enhancement of the basic nonrepudiation mechanism (the signature),
|
|||
|
a notary system could be used. Again these auxiliary services are
|
|||
|
best added at the discretion of implementors. For example,
|
|||
|
synchronized clocks may not be present, and notaries violate the
|
|||
|
desirable feature of point-to-point communication, and hence should
|
|||
|
not be included in standard specifications.
|
|||
|
|
|||
|
|
|||
|
6.5 Criteria for cryptosystems.
|
|||
|
|
|||
|
|
|||
|
There are various criteria which could be employed in selection
|
|||
|
of a cryptosystem (or systems) to implement key distribution and
|
|||
|
signatures. Logically these are separate functions and a hybrid of
|
|||
|
two separate systems could be used. Some relevant criteria
|
|||
|
(including suggestions from Dr. Dennis Branstad of NIST and Dr.
|
|||
|
Ronald Rivest) are:
|
|||
|
|
|||
|
|
|||
|
a. security
|
|||
|
|
|||
|
b. versatility
|
|||
|
|
|||
|
c. bandwidth
|
|||
|
|
|||
|
d. data expansion
|
|||
|
|
|||
|
e. key size
|
|||
|
|
|||
|
f. key generation time
|
|||
|
|
|||
|
g. patent restrictions/license fees
|
|||
|
|
|||
|
h. software support
|
|||
|
|
|||
|
i. hardware support
|
|||
|
|
|||
|
j. number of pseudorandom bits needed
|
|||
|
|
|||
|
k. interoperability
|
|||
|
|
|||
|
|
|||
|
Most of these are self-explanatory. The reference to
|
|||
|
pseudorandom bits in (j) is related to key generation, which
|
|||
|
requires a stream of pseudorandom bits generated from a random
|
|||
|
seed. Interoperability refers to the ability to communicate with
|
|||
|
other equipment designed to provide the same security mechanisms
|
|||
|
or functions.
|
|||
|
|
|||
|
|
|||
|
6.5.1 Security.
|
|||
|
|
|||
|
|
|||
|
The first and foremost criterion is of course security. It may
|
|||
|
take 5 years or more for a given method to be thoroughly
|
|||
|
cryptanalyzed, starting from the time it receives widespread public
|
|||
|
exposure.
|
|||
|
|
|||
|
One subcriterion in this regard is that a system should be
|
|||
|
published in an outlet such as a refereed journal with a reasonably
|
|||
|
large circulation, or a book or conference proceeding which is
|
|||
|
present in libraries at larger academic institutions and research
|
|||
|
laboratories. This subcriterion is somewhat vague and not
|
|||
|
intrinsic, but may serve to avoid future embarrassment on the part
|
|||
|
of implementors.
|
|||
|
|
|||
|
A second subcriterion connected with security deals with
|
|||
|
mathematical and computational infrastructure. For example, the
|
|||
|
security of systems such as RSA is connected with the problem of
|
|||
|
factoring. It is safe to assume that thousands (or perhaps
|
|||
|
millions) of hours have been spent on this problem. This does not
|
|||
|
preclude major advances over the next decade or so, but at least
|
|||
|
guarantees that such advances will not occur simply because experts
|
|||
|
have suddenly become aware of a problem. In particular, systems
|
|||
|
based on longstanding problems such as factoring, discrete
|
|||
|
logarithm and discrete root extraction have a certain degree of
|
|||
|
security in this regard. In contrast, for example, the ElGamal
|
|||
|
signature scheme can be broken if the "transcendental" equation c
|
|||
|
= brrs (mod n) can be solved for some r and s. This is easier than
|
|||
|
solving the logarithm or root problem y = xa (mod n); and
|
|||
|
furthermore in all likelihood the ElGamal equation has not been
|
|||
|
studied as extensively.
|
|||
|
|
|||
|
|
|||
|
6.5.2 Numerical criteria.
|
|||
|
|
|||
|
|
|||
|
Quantitative criteria for cryptosystems include bandwidth
|
|||
|
(encryption and decryption rates), data expansion (relative sizes
|
|||
|
of plaintext and ciphertext), key size and key generation time. We
|
|||
|
have already noted the phenomenon that systems which appear to be
|
|||
|
secure are also characterized by low bandwidths. Exponentiation-
|
|||
|
based methods such as RSA and the Diffie/Hellman exponential key
|
|||
|
exchange are examples. Other systems suffer from large data
|
|||
|
expansion, large key size or long key generation time.
|
|||
|
|
|||
|
There seem to be some inherent tradeoffs in this regard. That
|
|||
|
is, it does not seem possible to construct a system which is secure
|
|||
|
and also scores well on all numeric counts. The classic example is
|
|||
|
key size; e.g., small key size in RSA would produce a high
|
|||
|
bandwidth, but would also produce insecurity. That is, in this case
|
|||
|
high bandwidth would produce low cryptanalysis time. Data expansion
|
|||
|
seems to have a similar impact. For example, in appendix E it is
|
|||
|
noted that Shamir's knapsack attack runs in time which rises as nd
|
|||
|
where d = expansion factor. Again high bandwidth produced
|
|||
|
insecurity. It would be interesting to know whether this trade-
|
|||
|
off notion could be formalized.
|
|||
|
|
|||
|
|
|||
|
6.5.3 Other criteria.
|
|||
|
|
|||
|
|
|||
|
Versatility is an important criterion. The RSA system is
|
|||
|
distinguished in this regard since it supports both key
|
|||
|
distribution and signatures. All other major systems are limited
|
|||
|
to one service or the other, although hybrids can achieve the
|
|||
|
capabilities of RSA.
|
|||
|
|
|||
|
Patent restrictions and license fees may be a major factor in
|
|||
|
practice. Software and hardware support is another important
|
|||
|
practical matter.
|
|||
|
|
|||
|
|
|||
|
6.6 Criteria for hash functions.
|
|||
|
|
|||
|
|
|||
|
In section 3.2 we discussed some of the characterizations which
|
|||
|
have been proposed for hash functions, including measures of
|
|||
|
security. Some of the discussion of section 6.5 applies here as
|
|||
|
well. For example, a hash function should be widely publicized for
|
|||
|
a period of time before it is trusted. Bandwidth is also an
|
|||
|
important criterion. Software and hardware support is relevant as
|
|||
|
well.
|
|||
|
|
|||
|
|
|||
|
6.7 Example of a LAN security framework.
|
|||
|
|
|||
|
|
|||
|
Finally we give a brief outline of a framework for incorporating
|
|||
|
public-key cryptography into a local area network.
|
|||
|
|
|||
|
|
|||
|
6.7.1 Key management.
|
|||
|
|
|||
|
|
|||
|
The framework for key management described in this section is
|
|||
|
compatible with a subset of [CCIT87]. Public components of
|
|||
|
receivers are used as key-encrypting keys; private components of
|
|||
|
senders are used to encrypt message digests. Data-encrypting keys
|
|||
|
are generated for individual sessions. These may be associated to
|
|||
|
an arbitrary conventional cryptosystem; DES is a possibility. The
|
|||
|
public and private components may be associated to different
|
|||
|
public-key systems if different algorithms are used for key
|
|||
|
encryption and signatures.
|
|||
|
|
|||
|
Certificate-based key management is proposed. Since we are
|
|||
|
focusing on local-area networks, a simple tree structure is
|
|||
|
proposed, consisting of a root and one additional level containing
|
|||
|
all users. In particular, the root issues all certificates.
|
|||
|
Certification paths are thus trivial.
|
|||
|
|
|||
|
|
|||
|
6.7.2 Component generation and storage.
|
|||
|
|
|||
|
|
|||
|
It is proposed that users generate their own public/private
|
|||
|
component pairs, using trusted software or hardware supplied by the
|
|||
|
system. Key pairs could be stored on smart cards [HAYK88] or
|
|||
|
tokens, along with the user's certificate. Such kernel mechanisms
|
|||
|
could be augmented by involvement of a central key distribution
|
|||
|
facility. However, we have noted that this would negate a major
|
|||
|
advantage of public-key cryptography, since compromise of the
|
|||
|
central facility would compromise all keys of users who obtained
|
|||
|
their keys from it.
|
|||
|
|
|||
|
|
|||
|
6.7.3 Secret-key generation.
|
|||
|
|
|||
|
|
|||
|
Numerous schemes exist for generation of data-encrypting keys.
|
|||
|
For example, in [MATY78] it is noted that keys can be generated by
|
|||
|
a conventional system such as DES. A master key might be used to
|
|||
|
encrypt data-encrypting keys or other key-encrypting keys. The
|
|||
|
master key, presumably long-term, is generated randomly. Other key-
|
|||
|
encrypting keys can be generated using DES as a pseudorandom
|
|||
|
generator. These are then encrypted under the master, which can
|
|||
|
also be involved in generation of other key-encrypting keys. A
|
|||
|
whole set of key-encrypting keys can be generated from a random 64-
|
|||
|
bit seed, with every eighth bit adjusted for parity. Data-
|
|||
|
encrypting keys can be produced dynamically by pseudorandom number
|
|||
|
generators which are time-variant.
|
|||
|
|
|||
|
An example of a generator for data-encrypting keys, as well as
|
|||
|
initializing vectors, is given in appendix C of [ANSI85]. Let
|
|||
|
E(K,Y) be encryption by DEA (essentially equivalent to DES) with
|
|||
|
key K. Let K be a DEA key reserved for usage in key generation and
|
|||
|
let V0 be a 64-bit secret seed. Let T be a date/time vector,
|
|||
|
updated on each key or IV generation. Let
|
|||
|
|
|||
|
|
|||
|
Ri = E(K,E(K,Ti) XOR Vi),
|
|||
|
|
|||
|
Vi+1 = E(K,Ri XOR E(K,Ti)).
|
|||
|
|
|||
|
|
|||
|
Then Ri may be employed as an IV. To obtain a DEA key from R,
|
|||
|
reset every eighth bit to odd parity.
|
|||
|
|
|||
|
Routines for generating DES keys are supplied with various
|
|||
|
products. Schemes for pseudorandom number generation include [AKL-
|
|||
|
84], [BLUM84],[BRIG76]. The last gives a pseudorandom bit generator
|
|||
|
whose security is equivalent to discrete logarithm.
|
|||
|
|
|||
|
|
|||
|
6.7.4 Issuance and distribution of certificates.
|
|||
|
|
|||
|
|
|||
|
Public components are registered with the root. The root
|
|||
|
generates a certificate containing the user's public component and
|
|||
|
identifying information, and a validity period. Distribution of
|
|||
|
certificates by users is recommended; certificates may be cached.
|
|||
|
This eliminates the necessity of having the root be on-line.
|
|||
|
|
|||
|
However, a user may wish to send a privacy-enhanced message to
|
|||
|
a user with whom he has not previously communicated, and who is
|
|||
|
currently unavailable. Thus it may be desirable to augment this
|
|||
|
kernel mechanism with a supplementary source of certificates. There
|
|||
|
are disadvantages to any augmentation. For example, if a phone-
|
|||
|
book approach to certificates is used, entries may be inaccurate
|
|||
|
or altered. If a central directory mechanism is involved in key
|
|||
|
distribution it must be on-line. On the other hand, a central
|
|||
|
mechanism can provide instantaneous validity checks of public
|
|||
|
components and certificates.
|
|||
|
|
|||
|
|
|||
|
The root should maintain a list of old public components for a
|
|||
|
period of time in event of disputes, e.g., over attempted
|
|||
|
repudiation.
|
|||
|
|
|||
|
|
|||
|
6.7.5 Compromised or invalidated certificates.
|
|||
|
|
|||
|
|
|||
|
Assuming that certificates are cached, the root must
|
|||
|
periodically issue hot lists of invalidated certificates. This
|
|||
|
kernel service may be augmented in various ways to provide more
|
|||
|
current validity information. Again, however, additional mechanisms
|
|||
|
have drawbacks. As noted above, a central directory service could
|
|||
|
provide real-time validity checks, but it must be on-line.
|
|||
|
Furthermore, such checks a priori do not account for compromised
|
|||
|
private components, during the period following compromise but
|
|||
|
before a report is filed with the root. Even if users are required
|
|||
|
to report known compromises within a specified time period, a
|
|||
|
compromise may not become known to the user until later. As we
|
|||
|
noted, this creates an administrative/legal problem, since a user
|
|||
|
could disavow a signature on the basis of the latter type of
|
|||
|
compromise. A notary system can be used to add a layer of validity
|
|||
|
by having secondary signatures attest to the validity of senders'
|
|||
|
signatures, but this violates the desired criterion of point-to-
|
|||
|
point communication.
|
|||
|
|
|||
|
This is clearly an area in which solutions must be customized
|
|||
|
to some degree. For example, authentication in a system used for
|
|||
|
financial transactions may require more stringent controls than a
|
|||
|
kernel provides.
|
|||
|
|
|||
|
The root should maintain a time-stamped list of revoked
|
|||
|
certificates.
|
|||
|
|
|||
|
|
|||
|
6.7.6 Authentication.
|
|||
|
|
|||
|
|
|||
|
A hash function is used to produce a message digest. This is
|
|||
|
signed with the private component of the sender. Timestamps and
|
|||
|
random numbers may also be included to prevent replay. If more than
|
|||
|
one hash function is permitted, identification of the function used
|
|||
|
should be included.
|
|||
|
|
|||
|
Privacy-enhanced communication between two users begins when A
|
|||
|
requests the certificate of B. This initial message contains A's
|
|||
|
certificate. As noted above, it is desirable if this request can
|
|||
|
be met directly by B. In this event, B first validates A's
|
|||
|
certificate. This uses the public component of the root, which is
|
|||
|
assumed to be known to all users. Then B forwards his certificate
|
|||
|
to A, who validates it. Each may cache the certificate of the
|
|||
|
other.
|
|||
|
|
|||
|
Now A and B may communicate securely. If A sends a message to
|
|||
|
B, B uses A's validated public component, extracted from A's
|
|||
|
certificate, to decipher the message digest. Then B may decrypt the
|
|||
|
key used for data encryption, using B's private component. Now B
|
|||
|
may decrypt the message text using this session key, then re-
|
|||
|
compute the message digest and compare to the transmitted form.
|
|||
|
|
|||
|
|
|||
|
Appendix A. Mathematical and computational aspects.
|
|||
|
|
|||
|
|
|||
|
We discuss here some issues related to the computational
|
|||
|
complexity of public-key cryptography. The foundation of the
|
|||
|
security of such systems is the computational infeasibility of
|
|||
|
performing cryptanalysis, in contradistinction to the relative ease
|
|||
|
of encryption/decryption. We analyze some of the issues which arise
|
|||
|
in this context. Also included is some background theoretical
|
|||
|
computer science needed to discuss the issue of computational
|
|||
|
complexity of cryptography and cryptanalysis, as well as zero-
|
|||
|
knowledge proofs and related schemes.
|
|||
|
|
|||
|
This discussion may aid in understanding the security basis of
|
|||
|
public-key cryptography. It may also shed some light upon the more
|
|||
|
practical matter of choosing key sizes, i.e., the number of bits
|
|||
|
in private and public components. This section may safely be
|
|||
|
skipped by readers who do not wish to gain an in-depth
|
|||
|
understanding of such issues.
|
|||
|
|
|||
|
|
|||
|
A.1 Computational complexity and cryptocomplexity.
|
|||
|
|
|||
|
|
|||
|
An ideal cryptosystem would have the property that encryption
|
|||
|
and decryption are easy, but cryptanalysis is computationally
|
|||
|
infeasible. In practice, this is commonly interpreted (e.g.,
|
|||
|
[DIFF76b]) to mean that encryption/decryption should be executable
|
|||
|
in polynomial time, while ideally cryptanalysis should take
|
|||
|
exponential time. More generally, cryptanalytic time should be an
|
|||
|
exponential function of encryption/decryption time.
|
|||
|
|
|||
|
Unfortunately, it is difficult to determine when this criterion
|
|||
|
holds in practice. This is because it is usually very difficult to
|
|||
|
determine a nonpolynomial lower bound for the time required for
|
|||
|
cryptanalysis (or computations in general), even in instances when
|
|||
|
this process reduces to simple and well-known problems. In some
|
|||
|
cases the latter problems have been studied for centuries, but
|
|||
|
their computational complexity is still unknown.
|
|||
|
|
|||
|
In fact, whenever we try to determine the relative complexity
|
|||
|
of cryptanalysis and encryption, we encounter the problem of
|
|||
|
determining accurate lower bounds on computations.
|
|||
|
|
|||
|
Also, an analysis of security and efficiency of public-key
|
|||
|
systems should take into account not only encryption/decryption
|
|||
|
time versus anticipated time for cryptanalysis, but also other
|
|||
|
parameters such as key size, key generation time, and data
|
|||
|
expansion. Developing a theory to characterize both security and
|
|||
|
practicality of cryptosystems seems very challenging.
|
|||
|
|
|||
|
|
|||
|
A.2 Classical complexity theory.
|
|||
|
|
|||
|
|
|||
|
Here we briefly introduce some notions from the theory of
|
|||
|
computation. In Appendix C some of these notions are given a more
|
|||
|
formal treatment.
|
|||
|
|
|||
|
One attempt to formalize the study of hard problems is the
|
|||
|
theory of NP-completeness (e.g., [GARE79],[HORO78]). The class P
|
|||
|
is defined (loosely) to be the class of decision problems solvable
|
|||
|
in polynomial time via a deterministic algorithm. The latter is
|
|||
|
essentially an algorithm executable on an ordinary sequential
|
|||
|
computer. A nondeterministic algorithm is a more ephemeral concept:
|
|||
|
it is essentially executable on a machine with unbounded
|
|||
|
parallelism. This means that an unlimited number of possibilities
|
|||
|
can be explored in parallel. For example, suppose a set of n items
|
|||
|
is to checked for the presence or absence of a given item. The
|
|||
|
worst-case deterministic complexity is n, the number of operations
|
|||
|
needed by a sequential machine to check all n items. In contrast,
|
|||
|
the nondeterministic complexity is 1, since a machine with
|
|||
|
unbounded parallelism could check all n items in parallel
|
|||
|
regardless of n.
|
|||
|
|
|||
|
The class NP is (loosely) the class of decision problems
|
|||
|
solvable in polynomial time via a nondeterministic algorithm.
|
|||
|
Perhaps the single most important problem in computer science is
|
|||
|
to decide whether P = NP. The NP-complete problems are the hardest
|
|||
|
subclass of NP, having the property that if one instance of the
|
|||
|
subclass is in P then P = NP. Many classical combinatorial search
|
|||
|
problems can be given NP-complete formulations. Traveling salesman
|
|||
|
and knapsack are examples (see [GARE79] for a long list).
|
|||
|
|
|||
|
The class of NP-hard problems are those problems, decision or
|
|||
|
otherwise, which are at least as hard as NP-complete problems. Some
|
|||
|
NP-hard problems are so hard that no algorithm will solve them;
|
|||
|
they are undecidable. Such problems cannot be in NP. An example is
|
|||
|
the halting problem (e.g., [HORO78]).
|
|||
|
|
|||
|
A more formal treatment of the classes P and NP requires a
|
|||
|
framework such as Turing machines (app. C).
|
|||
|
|
|||
|
|
|||
|
A.3 Public-key systems and cryptocomplexity.
|
|||
|
|
|||
|
|
|||
|
The use of NP-complete problems to generate public-key
|
|||
|
cryptosystems was suggested in [DIFF76b]. Later this approach
|
|||
|
materialized in the form of trapdoor knapsacks [MERK78b]. As we
|
|||
|
have noted, however, most knapsacks have been broken, despite the
|
|||
|
continuing intractability of the underlying NP-complete problem
|
|||
|
(integer programming). There are two separate explanations for this
|
|||
|
phenomenon. First of all, in most cases it has not been proven that
|
|||
|
the security of the public-key system is equivalent to the
|
|||
|
intractability of the underlying problem.
|
|||
|
|
|||
|
Secondly, it is important to note that the classical theory of
|
|||
|
computational complexity has been founded around the cornerstone
|
|||
|
of worst-case complexity, with average-case complexity as a
|
|||
|
secondary criterion. As Rabin [RABI76] notes, these measures are
|
|||
|
of limited relevance in analyzing the complexity of cryptanalysis,
|
|||
|
since a cryptosystem must be immune to attack in almost all
|
|||
|
instances.
|
|||
|
|
|||
|
Attempts to formalize the notion of "almost-everywhere hardness"
|
|||
|
have been made (e.g., [GROL88]). An early characterization was
|
|||
|
suggested by Shamir [SHAM79], who quantifies this notion by
|
|||
|
defining a complexity measure C(n,a) for algorithms as follows:
|
|||
|
C(n,a) is a measure of an algorithm if at least a fraction a of
|
|||
|
problem instances of size n can be solved by the algorithm in time
|
|||
|
C(n,a). For example, an algorithm for finding one factor of n could
|
|||
|
have complexity C(n,1/2) = O(1), since n has a 50% chance of being
|
|||
|
even. However, such investigations have thus far failed to produce
|
|||
|
a comprehensive framework, although they may be useful in a few
|
|||
|
special instances.
|
|||
|
|
|||
|
Another simple example illustrates the difference between worst-
|
|||
|
case and average-case complexity: as noted in [RABI76], algorithms
|
|||
|
to sort n items are often predicated on the assumption that the
|
|||
|
items are arranged in random order; i.e., all n! arrangements are
|
|||
|
equally likely. If the file has a real-world origin it is more
|
|||
|
likely that the file is already partially sorted. An optimized
|
|||
|
algorithm might anticipate this and utilize an adaptive strategy.
|
|||
|
|
|||
|
In practice, a cryptosystem for which cryptanalysis has an
|
|||
|
average-case polynomial complexity is generally worthless; in fact
|
|||
|
this remains true if any measurable fraction of all instances
|
|||
|
permits polynomial-time cryptanalysis (this is difficult to make
|
|||
|
precise, since the fraction may vary with key size). Thus there is
|
|||
|
no a priori connection between the breaking of a system and the
|
|||
|
difficulty of the underlying problem, since the latter is
|
|||
|
characterized in terms of worst-case complexity. For example, often
|
|||
|
there exists a heuristic technique which yields an approximate
|
|||
|
solution to an NP-complete problem. Such techniques may not
|
|||
|
converge in polynomial time to an exact solution, but may break the
|
|||
|
corresponding cryptosystem.
|
|||
|
|
|||
|
In passing we remark that some authors (e.g., [WAGN84]) have
|
|||
|
attempted to go beyond the Diffie/Hellman notion of utilizing NP-
|
|||
|
complete problems to construct systems, by using the even more
|
|||
|
intractable class of undecidable problems instead. It would be
|
|||
|
interesting to know if such systems could be made practical.
|
|||
|
|
|||
|
|
|||
|
A.4 Probabilistic algorithms.
|
|||
|
|
|||
|
|
|||
|
Another important distinction between the classical theory of
|
|||
|
complexity and cryptocomplexity is that the classical theory of
|
|||
|
algorithms does not encompass probabilistic algorithms (e.g.,
|
|||
|
[RABI76]), which again may produce rapid solutions to problems in
|
|||
|
many instances but not even terminate in a few instances. They may
|
|||
|
also produce answers which are probably but not necessarily
|
|||
|
correct. Such algorithms are inappropriate in many contexts, e.g.,
|
|||
|
real-time control settings in which a response must be guaranteed
|
|||
|
in a fixed period of time, or where provable solutions are
|
|||
|
required. However, they are powerful tools in both cryptography and
|
|||
|
cryptanalysis.
|
|||
|
|
|||
|
As noted in [RABI76], probabilistic algorithms cannot be
|
|||
|
measured by classical criteria, which focus on worst-case runtime.
|
|||
|
Instead, a probabilistic algorithm may involve a tradeoff between
|
|||
|
execution time and confidence. For example, most numbers have all
|
|||
|
small factors. If an algorithm exploits this fact it may terminate
|
|||
|
quickly for most inputs but take exponential time when large primes
|
|||
|
appear as factors.
|
|||
|
|
|||
|
Gill [GILL77] models probabilistic computation by extending the
|
|||
|
classical Turing machine model (e.g., [HORO78]) to the
|
|||
|
probabilistic Turing machine (app. D). This has proven valuable in
|
|||
|
the analysis of cryptographic systems, and probabilistic encryption
|
|||
|
schemes in particular.
|
|||
|
|
|||
|
|
|||
|
A.5 Status of some relevant problems.
|
|||
|
|
|||
|
|
|||
|
The security of several major cryptosystems mentioned herein
|
|||
|
depends on the hardness of problems whose complexity status is
|
|||
|
unresolved. This includes factoring and discrete logarithm. The
|
|||
|
importance of the subclass of NP-complete problems emerges in this
|
|||
|
regard: if a problem is known to be in NP but is not known to be
|
|||
|
NP-complete, a solution to the problem in polynomial time (placing
|
|||
|
the problem in P) would not imply that problems such as traveling
|
|||
|
salesman are in P. The latter proposition is widely disbelieved.
|
|||
|
|
|||
|
A second relevant class is co-NP, the complements of problems
|
|||
|
in NP. For example, the complement of deciding whether n is prime
|
|||
|
is deciding if n is composite. In fact, primality and compositeness
|
|||
|
are in both NP and co-NP. Some experts have speculated (e.g.,
|
|||
|
[GARE79]) that P is the intersection of NP and co-NP. For example,
|
|||
|
linear programming was known to be in both of the latter long
|
|||
|
before its status was resolved; eventually it was shown to be in
|
|||
|
P, via the ellipsoid method [KHAC79]. This illustrates that it
|
|||
|
would indeed be desirable to have available cryptosystems based on
|
|||
|
NP-complete problems (but see below).
|
|||
|
|
|||
|
Good surveys of the status of many problems important in
|
|||
|
security of public-key systems are given in [ADLE86] and [POME86].
|
|||
|
Let
|
|||
|
|
|||
|
|
|||
|
L(n) = exp((1 + o(1))(ln n * ln ln n)1/2).
|
|||
|
|
|||
|
|
|||
|
Then Adleman notes that many algorithms for factoring n have
|
|||
|
probabilistic execution times believed to be of the form L(n)c
|
|||
|
(e.g., [SCHN84]). However, only the algorithm of Dixon [DIXO81] has
|
|||
|
been rigorously analyzed. Similarly, various algorithms for
|
|||
|
discrete logarithms mod p are believed to take time L(p). These
|
|||
|
results would be viewed with mistrust in the classical theory due
|
|||
|
to their probabilistic nature and lack of rigorous upper bounds for
|
|||
|
worst-case or average-case times. In contrast, Adleman [ADLE83]
|
|||
|
gives a deterministic algorithm for primality testing which
|
|||
|
executes in time
|
|||
|
|
|||
|
|
|||
|
O((ln n)c ln ln ln n).
|
|||
|
|
|||
|
|
|||
|
In the classical theory this result would be valuable, but we
|
|||
|
have noted that probabilistic algorithms are more efficient and far
|
|||
|
less complex, hence much more relevant in the present setting.
|
|||
|
Again this is indicative of the divergence between classical
|
|||
|
complexity and cryptocomplexity.
|
|||
|
|
|||
|
The status of the problem of taking roots mod n, i.e., solving
|
|||
|
xe <20> c (mod n), depends on the parameters (e.g., [SALO85]). A
|
|||
|
polynomial-time probabilistic algorithm to find x exists if e, c
|
|||
|
and n are fixed and n is prime. If n is composite with unknown
|
|||
|
factors, no polynomial-time algorithm exists, even probabilistic.
|
|||
|
If e = 2 the complexity is essentially equivalent to factoring n
|
|||
|
(lem. N.3.2). If e > 2 the status is less clear; as a consequence
|
|||
|
it is not clear that the security of RSA is equivalent to
|
|||
|
factoring.
|
|||
|
|
|||
|
Brassard [BRAS79] has shown that the discrete logarithm has an
|
|||
|
associated decision problem which lies in the intersection of NP
|
|||
|
and co-NP. Thus, if either factoring or taking discrete logarithms
|
|||
|
is NP-hard, it follows from the definition of this class that the
|
|||
|
associated decision problem is NP-complete and in co-NP. In turn
|
|||
|
this would imply NP = co-NP, which is widely disbelieved.
|
|||
|
|
|||
|
More generally, in [BRAS83] a function f is called restricted
|
|||
|
one-way if f is easily computable, f-1 is not, and f is injective
|
|||
|
and polynomially bounded. It is shown that if restricted one-way
|
|||
|
functions exist then P is not the intersection of NP and co-NP as
|
|||
|
many believe; and if f is restricted one-way and f-1 is NP-hard then
|
|||
|
NP = co-NP. Discrete logarithm is thought to be restricted one-
|
|||
|
way.
|
|||
|
|
|||
|
We conclude that there is little hope for fulfilling the
|
|||
|
Diffie/Hellman quest for public-key systems based on NP-complete
|
|||
|
problems. The same may be true of the search for one-way functions
|
|||
|
to employ as hash functions. Prospects for use of NP-hard problems
|
|||
|
seem difficult to assess at this time.
|
|||
|
|
|||
|
|
|||
|
Appendix B. Algorithms and architectures.
|
|||
|
|
|||
|
|
|||
|
We briefly survey some of the considerations relevant to
|
|||
|
determining what type of hardware and software support for
|
|||
|
cryptanalysis, or to a lesser extent encryption, may be forthcoming
|
|||
|
from the creators of algorithms and architectures of the future.
|
|||
|
We also mention some examples already in existence. This represents
|
|||
|
an excursion into high-performance computing, only a small fraction
|
|||
|
of which is applicable to cryptography. Nonetheless, in order to
|
|||
|
evaluate security of methods or ascertain key sizes, it is
|
|||
|
necessary to make some educated guesses as to how this field will
|
|||
|
progress over the next few decades.
|
|||
|
|
|||
|
|
|||
|
B.1 Technology.
|
|||
|
|
|||
|
|
|||
|
Computing at present is silicon-based. Thus all estimates of
|
|||
|
achievable computer performance are geared to this technology. The
|
|||
|
question arises as to whether a radically different technology such
|
|||
|
as superconductivity or optical computing will make silicon-based
|
|||
|
performance standards obsolete, and if so, when this might occur.
|
|||
|
We have no idea, and hence we ignore these.
|
|||
|
|
|||
|
Gallium arsenide technology is another matter. It has already
|
|||
|
been integrated into some existing supercomputers. Some of the
|
|||
|
differences between GaAs and silicon VLSI are (e.g., [MILU88]):
|
|||
|
|
|||
|
|
|||
|
a. GaAs gates have a higher switching speed.
|
|||
|
|
|||
|
b. Off-chip communication in GaAs pays a relatively higher
|
|||
|
penalty.
|
|||
|
|
|||
|
c. GaAs chips have lower density.
|
|||
|
|
|||
|
|
|||
|
Gate delays in GaAs (DCFL E/D-MESFET) may be as low as 50
|
|||
|
picoseconds, as opposed to at least 1 nanosecond in Silicon (NMOS).
|
|||
|
Similarly, on-chip memory access in GaAs may take as little as 500
|
|||
|
picoseconds, as opposed to at least 10 nanoseconds in silicon. This
|
|||
|
indicates that performance of GaAs-based computers could
|
|||
|
theoretically be as much as 20 times greater than even the fastest
|
|||
|
silicon-based supercomputers. However, GaAs levels of integration
|
|||
|
are currently much lower: at most about 50,000 transistors per
|
|||
|
chip, as opposed to 1,000,000 in silicon. This is due to problems
|
|||
|
in GaAs of power dissipation, yield and area limitations. Thus the
|
|||
|
number of chips necessary to build systems using GaAs is higher;
|
|||
|
minimizing chip count is important for high performance.
|
|||
|
|
|||
|
Off-chip communication in GaAs is another factor at the system
|
|||
|
level. The peak performance of a computer system is limited by the
|
|||
|
bandwidth of the slowest subsystem [HWAN84]. Inter-chip signal
|
|||
|
propagation is not significantly different for silicon or GaAs, but
|
|||
|
the relative effect is different: off-chip communication is more
|
|||
|
of a bottleneck in GaAs because of its ratio to on-chip speed.
|
|||
|
Silicon solutions to the problem of CPU speed versus other
|
|||
|
subsystem speeds include cache and multilevel memory hierarchies;
|
|||
|
these may not carry over mutatis mutandis to GaAs.
|
|||
|
|
|||
|
We conclude that at the moment, GaAs technology does not present
|
|||
|
a real threat to silicon performance standards. Furthermore, it
|
|||
|
does not appear likely that problems such as yield and integration
|
|||
|
will be solved in the near future. Thus, for the remainder of
|
|||
|
appendix B we assume no radical change in technology from the
|
|||
|
present.
|
|||
|
|
|||
|
|
|||
|
B.2. Computing modes.
|
|||
|
|
|||
|
|
|||
|
Classically, computing was dominated by the Von Neumann model,
|
|||
|
with a single processor executing a single instruction scheme on
|
|||
|
a single data stream. This paradigm reached its peak with computers
|
|||
|
such as the Cray-1 [CRAY80] and CYBER 205 [CONT80]. However, the
|
|||
|
performance of a single processing unit is limited by its clock
|
|||
|
speed. It does not seem feasible to reduce major cycles much below
|
|||
|
1 ns with silicon technology. Furthermore, at these speeds memory
|
|||
|
access becomes a bottleneck, not to mention I/O. Thus it is not
|
|||
|
likely that uniprocessors will exceed 109 operations per second,
|
|||
|
barring radical new technologies.
|
|||
|
|
|||
|
Two alternatives to the Von Neumann model are parallel and
|
|||
|
distributed computing (e.g., [HWAN84]). Parallel computing
|
|||
|
generally refers to processors in one box; distributed means each
|
|||
|
processor is in its own box. Parallel computers may (loosely) be
|
|||
|
subdivided into shared-memory, in which all processors share a
|
|||
|
common address space, and distributed-memory, in which each
|
|||
|
processor has its own address space. These modes remove the
|
|||
|
restriction on the number of instruction and/or data streams which
|
|||
|
may be processed concurrently. In theory these modes of computing
|
|||
|
can produce unlimited computing power, by splicing together single
|
|||
|
processing nodes and memory units (or processor/memory pairs) into
|
|||
|
a unified system. However, there are three major limitations in
|
|||
|
this regard:
|
|||
|
|
|||
|
|
|||
|
a. Cost-effectiveness.
|
|||
|
|
|||
|
b. The interconnection network.
|
|||
|
|
|||
|
c. Parallel algorithms.
|
|||
|
|
|||
|
|
|||
|
Cost-effectiveness alone has been a deterrent to the development
|
|||
|
of parallel systems. The Denelcor HEP (e.g., [KOWA85]), Floating
|
|||
|
Point T-Series [HAWK87] and ETA-10 [STEI86] are examples of
|
|||
|
parallel systems which have not proven to be commercially
|
|||
|
successful. Also, Cray and other supercomputer manufacturers have
|
|||
|
been reluctant to expand into large-scale parallelism, partially
|
|||
|
because of cost-related concerns. This creates an interesting
|
|||
|
situation from a cryptographic point of view: there may be cases
|
|||
|
where a computer powerful enough to break a given system could be
|
|||
|
built in theory. Security of the system might then rest on the
|
|||
|
assumption that no one will spend the money to build it, or that
|
|||
|
the only units built will belong to wealthy government agencies and
|
|||
|
be subject to tight controls.
|
|||
|
|
|||
|
Even if computers with 1000 or more powerful processors are
|
|||
|
constructed, the question arises as to whether such a configuration
|
|||
|
can achieve computing power in proportion to the number of
|
|||
|
processors, i.e., linear speedup. The mode of interconnecting the
|
|||
|
processors and memories is critical. If the shared-memory
|
|||
|
configuration is used, with a collection of processors accessing
|
|||
|
common memory partitioned into modules, interference in paths
|
|||
|
through the network or in simultaneous attempts to access a module
|
|||
|
will cause a bottleneck if a low-cost, low-bandwidth network such
|
|||
|
as a bus is used. If a high-bandwidth network such as a crossbar
|
|||
|
is used (i.e., with concurrent data transfers possible between many
|
|||
|
processors and memory modules), the number of units interconnected
|
|||
|
is limited by cost which rises as the square of the number of
|
|||
|
processors. Thus such systems seem to be inherently limited in the
|
|||
|
extent to which they can improve on uniprocessor performance.
|
|||
|
|
|||
|
An alternative is to connect processor/memory pairs using a
|
|||
|
network such as a hypercube [SEIT85]. Machines of this type with
|
|||
|
up to 65,536 weak processing elements (e.g., the Connection Machine
|
|||
|
[HILL85]) or up to 1024 powerful processors (e.g., the NCUBE/10
|
|||
|
[HAYE86]) have been constructed, and systems with up to 32,000
|
|||
|
Cray-1 level processors have been proposed. There is debate (and
|
|||
|
some controversy) over the speedups which such distributed-memory
|
|||
|
machines can achieve. The latter consideration is related to cost-
|
|||
|
effectiveness, which requires nearly-linear speedup. Also, the cost
|
|||
|
of interconnection in a hypercube-based system rises as O(n log n),
|
|||
|
where n is the number of processor/memory pairs.
|
|||
|
|
|||
|
Another concern is algorithms. A problem must be highly
|
|||
|
decomposable to be amenable to parallel or distributed computation.
|
|||
|
Furthermore, algorithms for non-Von Neumann machines must be
|
|||
|
tailored to individual architectures to a much greater extent than
|
|||
|
their Von Neumann counterparts, adding to the cost of software
|
|||
|
development.
|
|||
|
|
|||
|
Because of inherent tradeoffs between performance and cost,
|
|||
|
there may be a divergence between the computing power attainable
|
|||
|
in theory and that which is practical (and in the event of
|
|||
|
commercial machines, marketable). Within 10 years it is conceivable
|
|||
|
that machines executing 1012 operations per second could be built
|
|||
|
with refinements of existing technology; the real question seems
|
|||
|
to be financing.
|
|||
|
|
|||
|
An alternative to the single-machine approach is the use of
|
|||
|
networks for completely distributed computing (e.g., [LENS89]). The
|
|||
|
class of problems amenable to solution via networks (and wide-area
|
|||
|
networks in particular) is restricted, since the nodes must
|
|||
|
communicate infrequently (typically only at the beginning and end
|
|||
|
of a computation). Nonetheless, in section 4 it was noted that some
|
|||
|
of the strongest cryptanalytically-related results have been
|
|||
|
obtained by networks of computers. This is possible because many
|
|||
|
of the relevant cryptanalytic algorithms are fully decomposable
|
|||
|
into independent portions which do not need to interact. An example
|
|||
|
is the quadratic sieve.
|
|||
|
|
|||
|
It may be possible to assemble more computing power in such a
|
|||
|
network than is present in any single computer. Once again, the
|
|||
|
constraints are largely pragmatic. Designers of cryptosystems must
|
|||
|
therefore attempt to anticipate not only advances in algorithms and
|
|||
|
architectures, but also the greatest amount of computing power
|
|||
|
which might realistically be brought to bear against a given task.
|
|||
|
|
|||
|
|
|||
|
B.3 Some relevant algorithms and implementation.
|
|||
|
|
|||
|
|
|||
|
Most of the powerful algorithms for factoring and discrete
|
|||
|
logarithm are fairly new. As we have noted, most of them have not
|
|||
|
been fully analyzed for runtimes. Nonetheless, some standards have
|
|||
|
emerged in this regard. The best guess for the future can only
|
|||
|
amount to anticipation of improvements in the present algorithms.
|
|||
|
|
|||
|
|
|||
|
B.3.1 Quadratic sieve factoring algorithm.
|
|||
|
|
|||
|
|
|||
|
The quadratic sieve [POME84] provides an alternative to the
|
|||
|
earlier continued fraction factorization algorithm [MORR75].
|
|||
|
|
|||
|
As noted in [DAVI83b], the continued fraction approach uses
|
|||
|
considerable multiple precision division. The quadratic sieve works
|
|||
|
with larger residues but involves mainly single-precision
|
|||
|
subtraction. Both have runtimes of exp(sqrt(c ln n ln ln n)) but
|
|||
|
c = 2 for continued fraction, c = 9/8 for the quadratic sieve.
|
|||
|
|
|||
|
In [DAVI84] the results of implementing the quadratic sieve on
|
|||
|
a Cray X-MP [CRAY85] are reported. Factorization of 70-digit
|
|||
|
numbers takes about an hour; 100-digit numbers should take about
|
|||
|
a year. The key to this match of algorithm and architecture is the
|
|||
|
utilization of the vector capability of the Cray architecture. In
|
|||
|
particular, a steady stream of operands is necessary to take
|
|||
|
advantage of a pipelined, register-to-register machine. The loops
|
|||
|
in the sieve are amenable to streaming of operands, and about 75%
|
|||
|
efficiency was obtained. However, the multitasking capability of
|
|||
|
the X-MP was not utilized. Since Crays with up to 16 processors are
|
|||
|
expected in the near future, with even greater parallelism to be
|
|||
|
anticipated, it follows that the results of such experiments are
|
|||
|
probably too conservative. On the other hand, utilizing both vector
|
|||
|
and parallel capabilities of a system is nontrivial, partially as
|
|||
|
a result of memory bank contention. Furthermore, adaption of the
|
|||
|
algorithm to exploit both capabilities may be nontrivial. Hence it
|
|||
|
is not clear to what extent the preceding efficiency can be
|
|||
|
maintained as the degree of parallelism grows.
|
|||
|
|
|||
|
An alternative is distributed computing: Silverman [SILV87] has
|
|||
|
used the quadratic sieve implemented via a network of 9 SUN 3
|
|||
|
workstations to factor numbers up to 80 digits in 8 weeks. Recently
|
|||
|
another network was used to factor 106-digit numbers [LENS89].
|
|||
|
|
|||
|
It should be noted that the results obtained via the quadratic
|
|||
|
sieve are directly relevant cryptanalytically, since the integers
|
|||
|
factored are general. Integers of up to 155 digits, but with
|
|||
|
special forms, have been factored, also by use of networks
|
|||
|
[SIAM90]. However, these results are only indirectly relevant to
|
|||
|
systems such as RSA, assuming moduli are properly chosen.
|
|||
|
|
|||
|
|
|||
|
B.3.2 Computations in finite fields.
|
|||
|
|
|||
|
|
|||
|
This is a subject which has been explored fairly thoroughly
|
|||
|
(e.g., [BART63]), and we do not review it here.
|
|||
|
|
|||
|
Multiplication of elements in GF(m) has classically been
|
|||
|
implemented at the circuit level using linear feedback shift
|
|||
|
registers. However, Laws [LAWS71] has noted the potential for using
|
|||
|
cellular arrays. These are highly amenable to VLSI implementation.
|
|||
|
A pipeline architecture for multiplication and inverses is proposed
|
|||
|
in [WANG85].
|
|||
|
|
|||
|
One class of algorithms of particular interest is for discrete
|
|||
|
logarithms in GF(pn). Still more particularly, the case n = 2 has
|
|||
|
been explored considerably ([BLAK84],[BLAK84b],[COPP84]). Since
|
|||
|
finite logarithms are easy to compute in GF(m) if m has only small
|
|||
|
factors [POHL78], n should be chosen so that 2n - 1 is (a Mersenne)
|
|||
|
prime, e.g., n = 521. However, Odlyzko [ODLY84b] notes that a next-
|
|||
|
generation supercomputer might break n = 521 in a year. A special-
|
|||
|
purpose computer might attack n on the order of 700 in a year.
|
|||
|
|
|||
|
Odlyzko also notes that with similar bounds on key size, GF(p)
|
|||
|
may be preferable to GF(2n); e.g., n = 2000 is roughly equivalent
|
|||
|
to p of about 750 bits. As noted above, this advantage may be
|
|||
|
counterbalanced by implementation efficiency.
|
|||
|
|
|||
|
|
|||
|
B.3.3 Other algorithms.
|
|||
|
|
|||
|
|
|||
|
Many of the most fundamental operations in this setting seem to
|
|||
|
be characterized by inherent sequentiality. An example is
|
|||
|
exponentiation; computing the n-th power seems to take log n steps
|
|||
|
regardless of the number of processors available.
|
|||
|
|
|||
|
Another classical example is greatest common divisor. Although
|
|||
|
some partial results are noted in [ADLE86], major improvement over
|
|||
|
Euclid does not seem forthcoming regardless of advances in
|
|||
|
architecture.
|
|||
|
|
|||
|
Many of the powerful factoring algorithms are highly
|
|||
|
parallelizable (e.g., [SCHN84]). The main requirement is existence
|
|||
|
of appropriate architectures.
|
|||
|
|
|||
|
|
|||
|
B.4. Application-specific architectures.
|
|||
|
|
|||
|
|
|||
|
General-purpose architectures such as the Cray are of interest
|
|||
|
in this setting because of their immediate availability. At the
|
|||
|
other extreme, architectures closely matching the algorithms of
|
|||
|
interest could be constructed, but their over-specialized nature
|
|||
|
would virtually preclude their commercial distribution. In between
|
|||
|
are classes of architectures which are more versatile but not truly
|
|||
|
general-purpose. We note several examples of partly-specific
|
|||
|
architectures and a proposed highly-specific machine.
|
|||
|
|
|||
|
|
|||
|
B.4.1 Systolic and wavefront arrays.
|
|||
|
|
|||
|
|
|||
|
The notion of systolic arrays ([KUNG82],[KUNG78]) is an
|
|||
|
extension of pipelining. The idea is to have a collection of
|
|||
|
processors operate on data which is pulsed rhythmically through the
|
|||
|
array. If the original requirement of a synchronous mode of
|
|||
|
operation is relaxed, the result is a wavefront array [KUNG82b].
|
|||
|
Both types were originally targeted at applications such as signal
|
|||
|
processing which are compute-intensive and involve repetitions of
|
|||
|
operations on many operands.
|
|||
|
|
|||
|
A systolic array for the computation of GCDs is proposed in
|
|||
|
[BREN83]. It is very amenable to VLSI implementation because of its
|
|||
|
regular topology. Furthermore it is linear, limiting I/O
|
|||
|
requirements which can constitute a bottleneck in VLSI
|
|||
|
implementations. Supporting algorithms are noted in [BREN83b].
|
|||
|
|
|||
|
It would be of interest to know what a more general-purpose
|
|||
|
linear systolic array such as the Warp [ANNA87] (which curiously
|
|||
|
more closely resembles a wavefront array) could accomplish on some
|
|||
|
of the problems discussed in this paper, and factoring in
|
|||
|
particular. The Warp is already in production.
|
|||
|
|
|||
|
|
|||
|
B.4.2 Proposal for a quadratic sieve machine.
|
|||
|
|
|||
|
|
|||
|
Pomerance et al. [POME88] describe a pipeline architecture which
|
|||
|
would efficiently execute the quadratic sieve. This notion is of
|
|||
|
considerable interest to anyone implementing an algorithm such as
|
|||
|
RSA, since such a machine could presumably factor numbers beyond
|
|||
|
the reach of present-day supercomputers.
|
|||
|
|
|||
|
Cost-effectiveness is carefully analyzed, as is critical for an
|
|||
|
application-specific architecture. They speculate that a $50,000
|
|||
|
version of the architecture should factor 100-digit numbers in
|
|||
|
about 2 weeks; or 140 digits in a year on a $10 million version;
|
|||
|
or 200 digits in 1 year on a $100 billion version. It should be
|
|||
|
noted that the last is clearly predicated on the notion that the
|
|||
|
architecture and algorithm will scale linearly with the number of
|
|||
|
processing units; we noted earlier that various bottlenecks such
|
|||
|
as inter-processor communication and memory access make this
|
|||
|
somewhat dubious. Nonetheless the possibility arises that moduli
|
|||
|
approaching 200 digits may be necessary in RSA because of the
|
|||
|
potential existence of machines such as these.
|
|||
|
|
|||
|
The crux of the architecture are the pipe and pipe I/O units.
|
|||
|
These should be custom and should be able to handle variable
|
|||
|
strides without the considerable loss of efficiency which usually
|
|||
|
accompanies nonconstant stride. The two units should be chained
|
|||
|
together. The pipe should consist of stages, all of which are bus-
|
|||
|
connected to the pipe I/O unit. The cycle time of memory should be
|
|||
|
the same as the processing elements.
|
|||
|
|
|||
|
It is interesting to note that this architecture bears a close
|
|||
|
resemblance to a linear systolic array.
|
|||
|
|
|||
|
|
|||
|
B.4.3 Massively parallel machines.
|
|||
|
|
|||
|
|
|||
|
An alternative to pipelined machines is to configure a large
|
|||
|
number of primitive processing elements in an array and have them
|
|||
|
execute the same instruction stream synchronously, processing a
|
|||
|
large quantity of data in parallel (SIMD mode). Such machines are
|
|||
|
generally applied to real-time image or signal processing, or to
|
|||
|
large-scale matrix operations.
|
|||
|
|
|||
|
The MPP [BATC80] is an example. It consists of 16,384 processors
|
|||
|
in a square array. It was intended mainly for image processing of
|
|||
|
data from satellites; but in [WUND83] and [WILL87] it is used for
|
|||
|
an implementation of the continued-fraction factoring algorithm.
|
|||
|
Wunderlich [WUND85] also implements this algorithm on the DAP
|
|||
|
(e.g., [HOCK81]), another massively parallel machine with 4096
|
|||
|
processors. Unlike the MPP, the DAP has been marketed.
|
|||
|
|
|||
|
|
|||
|
Appendix C. The classical theory of computation.
|
|||
|
|
|||
|
|
|||
|
In appendix A a number of topics from the classical theory of
|
|||
|
computation were mentioned. Here we give a more precise treatment
|
|||
|
of some notions from the classical theory (e.g., [LEWI81]).
|
|||
|
|
|||
|
An alphabet is a finite set of symbols. A string is a sequence
|
|||
|
of symbols from an alphabet. A language on an alphabet is a set of
|
|||
|
strings from the alphabet. If S is an alphabet, S* denotes the set
|
|||
|
of all strings from S, including the empty string. Concatenation
|
|||
|
of strings a and b is written ab. If A and B are subsets of S*, AB
|
|||
|
is the set of strings formed by concatenating elements from A and
|
|||
|
B.
|
|||
|
|
|||
|
|
|||
|
C.1 Turing machines.
|
|||
|
|
|||
|
|
|||
|
A (one-tape, deterministic) Turing machine is a quadruple
|
|||
|
(K,S,D,s) where:
|
|||
|
|
|||
|
|
|||
|
a. S is an alphabet which contains a blank = #, but not the
|
|||
|
symbols L or R which are reserved for tape movement to the
|
|||
|
left or right.
|
|||
|
|
|||
|
b. K is a set of states which does not include the halt state
|
|||
|
= h, which signals an end to computation.
|
|||
|
|
|||
|
c. s = initial state; it is in K.
|
|||
|
|
|||
|
d. D : K x S -> (K + {h}) x (S + {L,R}) where + denotes
|
|||
|
union.
|
|||
|
|
|||
|
|
|||
|
A Turing machine = M may be interpreted semi-physically as
|
|||
|
consisting of a control unit and a tape. At any time M is in some
|
|||
|
state, and the read/write head of the tape is over some symbol on
|
|||
|
the tape. If D(q,a) = (p,b) then initially the head is scanning a
|
|||
|
and M is in state q; its next move will be to enter state p. If b
|
|||
|
is in S the head will set a := b without moving; otherwise b = L
|
|||
|
or R in which case the head will move to the left or right. M halts
|
|||
|
when state h is entered. or M hangs (the left end of the tape is
|
|||
|
surpassed). The tape has no right end.
|
|||
|
|
|||
|
Input to M consists of a string. The string is padded by a # on
|
|||
|
each side and placed on the leftmost squares of the tape. The rest
|
|||
|
of the tape consists of #'s. Initially the head is positioned over
|
|||
|
the # which marks the right end of the input. Initially M is in
|
|||
|
state s; its first move is thus D(s,#).
|
|||
|
|
|||
|
At a given time M is in configuration (q,w,a,u), where:
|
|||
|
|
|||
|
|
|||
|
a. q = state (element of K + {h}).
|
|||
|
|
|||
|
b. w = portion of the tape to the left of the head (element
|
|||
|
of S*).
|
|||
|
|
|||
|
c. a = symbol under the head (element of S).
|
|||
|
|
|||
|
d. u = portion of the tape to the right of the head.
|
|||
|
|
|||
|
|
|||
|
If e denotes the empty string, u in (d) is required to be an
|
|||
|
element of (S*)(S-{#})+{e}; i.e., either u = e, meaning the tape
|
|||
|
has all #'s to the right of the head, or the last symbol of u is
|
|||
|
the last nonblank symbol to the right of the head position. This
|
|||
|
gives the configuration a unique description. In particular, if the
|
|||
|
input to M is w then the initial configuration of M is (s,#w,#,e).
|
|||
|
|
|||
|
M is said to halt on input w if some halted configuration (state
|
|||
|
= h) is reached from (s,#w,#,e) in a finite number of steps; then
|
|||
|
it is said that (s,#w,#,e) yields a halted configuration. If M
|
|||
|
halts on input w, M is said to accept w. The language accepted by
|
|||
|
M is the set of strings w accepted by M. Conversely, a language is
|
|||
|
said to be Turing-acceptable if it is accepted by some Turing
|
|||
|
machine.
|
|||
|
|
|||
|
Suppose S is an alphabet, T and W are subsets of S, and
|
|||
|
f: W -> T. Suppose there exists a Turing machine M = (K,S,D,s) such
|
|||
|
that for any w in W, the configuration (s,#w,#,e) yields
|
|||
|
(h,#u,#,e), i.e., u is the output of M on input w, and furthermore
|
|||
|
u = f(w). Then f is said to be computed by M.
|
|||
|
|
|||
|
Suppose alphabet A does not contain #, Y or N. Suppose L is a
|
|||
|
language in A* and X is its characteristic function, i.e., for w
|
|||
|
in A*, X(w) = Y if w is in L, X(w) = N otherwise. If X is computed
|
|||
|
by Turing machine M then M is said to decide (or recognize) L.
|
|||
|
Conversely, if X is the characteristic function of a language L and
|
|||
|
X is Turing-computable, i.e., there exists a Turing machine which
|
|||
|
computes X, then L is said to be Turing-decidable.
|
|||
|
|
|||
|
An extension of the basic model is to permit the control unit
|
|||
|
to control (a finite number of) multiple tapes. However, a language
|
|||
|
accepted by a multitape Turing machine is also accepted by a one-
|
|||
|
tape Turing machine; i.e., additional tapes do not increase the
|
|||
|
computing power of Turing machines in terms of expanding the class
|
|||
|
of languages accepted.
|
|||
|
|
|||
|
|
|||
|
C.2 Nondeterministic Turing machines.
|
|||
|
|
|||
|
|
|||
|
The preceding Turing machines were deterministic; i.e., D was
|
|||
|
a function: if D(q,a) = (p,b) then the next state p and scanned
|
|||
|
symbol b were uniquely determined by the present state q and symbol
|
|||
|
a. A nondeterministic Turing machine is defined similarly except
|
|||
|
that D is now a relation on
|
|||
|
|
|||
|
|
|||
|
(K x S) x ((K + {h}) x (S + {L,R})).
|
|||
|
|
|||
|
|
|||
|
That is, D is now multiple-valued, so that the next
|
|||
|
configuration is no longer uniquely determined by the present.
|
|||
|
Instead, in a given number of steps a configuration may yield a
|
|||
|
number of configurations. Consequently an input may yield many
|
|||
|
outputs. A sequence of steps starting from a given input defines
|
|||
|
a computation; in general many computations are possible on one
|
|||
|
input. A nondeterministic machine is said to accept an input if
|
|||
|
there exists a halting computation on it. Again the language
|
|||
|
accepted by a machine is the set of strings accepted by it.
|
|||
|
Trivially any language accepted by nondeterministic machines is
|
|||
|
also accepted by deterministic machines, which are merely special
|
|||
|
cases of the more general nondeterministic case.
|
|||
|
|
|||
|
It is also true (but not as trivial) that any language accepted
|
|||
|
by a nondeterministic Turing machine is also accepted by a
|
|||
|
deterministic Turing machine. That is, nondeterminism does not
|
|||
|
increase the power of Turing machines insofar as the class of
|
|||
|
languages is concerned.
|
|||
|
|
|||
|
Similar extensions hold for decidable languages.
|
|||
|
|
|||
|
|
|||
|
C.3 Computational complexity.
|
|||
|
|
|||
|
|
|||
|
The time complexity of Turing machines is measured by the number
|
|||
|
of steps taken by a computation. If T is a function on the
|
|||
|
nonnegative integers, a deterministic Turing machine M is said to
|
|||
|
decide language L in time T if it decides in time T(n) or less
|
|||
|
whether w is or is not in L, where w has length n. If T is a
|
|||
|
polynomial then L is said to be decided in polynomial time. If a
|
|||
|
language is decidable in polynomial time on a multitape
|
|||
|
deterministic Turing machine then it is decidable in polynomial
|
|||
|
time on a one-tape Turing machine.
|
|||
|
|
|||
|
A nondeterministic Turing machine M is said to accept w in time
|
|||
|
T if there is halting computation on w of T(n) or fewer steps,
|
|||
|
where w has length n. M is said to accept language L in time T if
|
|||
|
it accepts each string in L in time T.
|
|||
|
|
|||
|
The class of languages decidable in polynomial time on some
|
|||
|
deterministic Turing machine is denoted by P. The class of
|
|||
|
languages acceptable in polynomial time on some nondeterministic
|
|||
|
Turing machine is denoted by NP.
|
|||
|
|
|||
|
It is not known whether P = NP.
|
|||
|
|
|||
|
|
|||
|
Appendix C. The classical theory of computation.
|
|||
|
|
|||
|
|
|||
|
In appendix A a number of topics from the classical theory of
|
|||
|
computation were mentioned. Here we give a more precise treatment
|
|||
|
of some notions from the classical theory (e.g., [LEWI81]).
|
|||
|
|
|||
|
An alphabet is a finite set of symbols. A string is a sequence
|
|||
|
of symbols from an alphabet. A language on an alphabet is a set of
|
|||
|
strings from the alphabet. If S is an alphabet, S* denotes the set
|
|||
|
of all strings from S, including the empty string. Concatenation
|
|||
|
of strings a and b is written ab. If A and B are subsets of S*, AB
|
|||
|
is the set of strings formed by concatenating elements from A and
|
|||
|
B.
|
|||
|
|
|||
|
|
|||
|
C.1 Turing machines.
|
|||
|
|
|||
|
|
|||
|
A (one-tape, deterministic) Turing machine is a quadruple
|
|||
|
(K,S,D,s) where:
|
|||
|
|
|||
|
|
|||
|
a. S is an alphabet which contains a blank = #, but not the
|
|||
|
symbols L or R which are reserved for tape movement to the
|
|||
|
left or right.
|
|||
|
|
|||
|
b. K is a set of states which does not include the halt state
|
|||
|
= h, which signals an end to computation.
|
|||
|
|
|||
|
c. s = initial state; it is in K.
|
|||
|
|
|||
|
d. D : K x S -> (K + {h}) x (S + {L,R}) where + denotes
|
|||
|
union.
|
|||
|
|
|||
|
|
|||
|
A Turing machine = M may be interpreted semi-physically as
|
|||
|
consisting of a control unit and a tape. At any time M is in some
|
|||
|
state, and the read/write head of the tape is over some symbol on
|
|||
|
the tape. If D(q,a) = (p,b) then initially the head is scanning a
|
|||
|
and M is in state q; its next move will be to enter state p. If b
|
|||
|
is in S the head will set a := b without moving; otherwise b = L
|
|||
|
or R in which case the head will move to the left or right. M halts
|
|||
|
when state h is entered. or M hangs (the left end of the tape is
|
|||
|
surpassed). The tape has no right end.
|
|||
|
|
|||
|
Input to M consists of a string. The string is padded by a # on
|
|||
|
each side and placed on the leftmost squares of the tape. The rest
|
|||
|
of the tape consists of #'s. Initially the head is positioned over
|
|||
|
the # which marks the right end of the input. Initially M is in
|
|||
|
state s; its first move is thus D(s,#).
|
|||
|
|
|||
|
At a given time M is in configuration (q,w,a,u), where:
|
|||
|
|
|||
|
|
|||
|
a. q = state (element of K + {h}).
|
|||
|
|
|||
|
b. w = portion of the tape to the left of the head (element
|
|||
|
of S*).
|
|||
|
|
|||
|
c. a = symbol under the head (element of S).
|
|||
|
|
|||
|
d. u = portion of the tape to the right of the head.
|
|||
|
|
|||
|
|
|||
|
If e denotes the empty string, u in (d) is required to be an
|
|||
|
element of (S*)(S-{#})+{e}; i.e., either u = e, meaning the tape
|
|||
|
has all #'s to the right of the head, or the last symbol of u is
|
|||
|
the last nonblank symbol to the right of the head position. This
|
|||
|
gives the configuration a unique description. In particular, if the
|
|||
|
input to M is w then the initial configuration of M is (s,#w,#,e).
|
|||
|
|
|||
|
M is said to halt on input w if some halted configuration (state
|
|||
|
= h) is reached from (s,#w,#,e) in a finite number of steps; then
|
|||
|
it is said that (s,#w,#,e) yields a halted configuration. If M
|
|||
|
halts on input w, M is said to accept w. The language accepted by
|
|||
|
M is the set of strings w accepted by M. Conversely, a language is
|
|||
|
said to be Turing-acceptable if it is accepted by some Turing
|
|||
|
machine.
|
|||
|
|
|||
|
Suppose S is an alphabet, T and W are subsets of S, and
|
|||
|
f: W -> T. Suppose there exists a Turing machine M = (K,S,D,s) such
|
|||
|
that for any w in W, the configuration (s,#w,#,e) yields
|
|||
|
(h,#u,#,e), i.e., u is the output of M on input w, and furthermore
|
|||
|
u = f(w). Then f is said to be computed by M.
|
|||
|
|
|||
|
Suppose alphabet A does not contain #, Y or N. Suppose L is a
|
|||
|
language in A* and X is its characteristic function, i.e., for w
|
|||
|
in A*, X(w) = Y if w is in L, X(w) = N otherwise. If X is computed
|
|||
|
by Turing machine M then M is said to decide (or recognize) L.
|
|||
|
Conversely, if X is the characteristic function of a language L and
|
|||
|
X is Turing-computable, i.e., there exists a Turing machine which
|
|||
|
computes X, then L is said to be Turing-decidable.
|
|||
|
|
|||
|
An extension of the basic model is to permit the control unit
|
|||
|
to control (a finite number of) multiple tapes. However, a language
|
|||
|
accepted by a multitape Turing machine is also accepted by a one-
|
|||
|
tape Turing machine; i.e., additional tapes do not increase the
|
|||
|
computing power of Turing machines in terms of expanding the class
|
|||
|
of languages accepted.
|
|||
|
|
|||
|
|
|||
|
C.2 Nondeterministic Turing machines.
|
|||
|
|
|||
|
|
|||
|
The preceding Turing machines were deterministic; i.e., D was
|
|||
|
a function: if D(q,a) = (p,b) then the next state p and scanned
|
|||
|
symbol b were uniquely determined by the present state q and symbol
|
|||
|
a. A nondeterministic Turing machine is defined similarly except
|
|||
|
that D is now a relation on
|
|||
|
|
|||
|
|
|||
|
(K x S) x ((K + {h}) x (S + {L,R})).
|
|||
|
|
|||
|
|
|||
|
That is, D is now multiple-valued, so that the next
|
|||
|
configuration is no longer uniquely determined by the present.
|
|||
|
Instead, in a given number of steps a configuration may yield a
|
|||
|
number of configurations. Consequently an input may yield many
|
|||
|
outputs. A sequence of steps starting from a given input defines
|
|||
|
a computation; in general many computations are possible on one
|
|||
|
input. A nondeterministic machine is said to accept an input if
|
|||
|
there exists a halting computation on it. Again the language
|
|||
|
accepted by a machine is the set of strings accepted by it.
|
|||
|
Trivially any language accepted by nondeterministic machines is
|
|||
|
also accepted by deterministic machines, which are merely special
|
|||
|
cases of the more general nondeterministic case.
|
|||
|
|
|||
|
It is also true (but not as trivial) that any language accepted
|
|||
|
by a nondeterministic Turing machine is also accepted by a
|
|||
|
deterministic Turing machine. That is, nondeterminism does not
|
|||
|
increase the power of Turing machines insofar as the class of
|
|||
|
languages is concerned.
|
|||
|
|
|||
|
Similar extensions hold for decidable languages.
|
|||
|
|
|||
|
|
|||
|
C.3 Computational complexity.
|
|||
|
|
|||
|
|
|||
|
The time complexity of Turing machines is measured by the number
|
|||
|
of steps taken by a computation. If T is a function on the
|
|||
|
nonnegative integers, a deterministic Turing machine M is said to
|
|||
|
decide language L in time T if it decides in time T(n) or less
|
|||
|
whether w is or is not in L, where w has length n. If T is a
|
|||
|
polynomial then L is said to be decided in polynomial time. If a
|
|||
|
language is decidable in polynomial time on a multitape
|
|||
|
deterministic Turing machine then it is decidable in polynomial
|
|||
|
time on a one-tape Turing machine.
|
|||
|
|
|||
|
A nondeterministic Turing machine M is said to accept w in time
|
|||
|
T if there is halting computation on w of T(n) or fewer steps,
|
|||
|
where w has length n. M is said to accept language L in time T if
|
|||
|
it accepts each string in L in time T.
|
|||
|
|
|||
|
The class of languages decidable in polynomial time on some
|
|||
|
deterministic Turing machine is denoted by P. The class of
|
|||
|
languages acceptable in polynomial time on some nondeterministic
|
|||
|
Turing machine is denoted by NP.
|
|||
|
|
|||
|
It is not known whether P = NP.
|
|||
|
|
|||
|
|
|||
|
Appendix D. The theory of probabilistic computing.
|
|||
|
|
|||
|
|
|||
|
Probabilistic algorithms are employed as adjuncts in
|
|||
|
cryptosystems for purposes such as finding primes. They have also
|
|||
|
produced virtually all major practical cryptanalytic algorithms for
|
|||
|
factoring, discrete logarithm etc. Here we review an extension of
|
|||
|
the classical theory of computation which incorporates
|
|||
|
probabilistic computing. This extension has proven particularly
|
|||
|
valuable in the study of probabilistic cryptosystems.
|
|||
|
|
|||
|
An ordinary deterministic multitape Turing machine may be
|
|||
|
considered to have an input tape, an output tape, and read-write
|
|||
|
worktapes. A modification of the ordinary model (e.g., [GILL77])
|
|||
|
is the probabilistic Turing machine. It has a distinguished state
|
|||
|
called the coin-tossing state, which permits the machine to make
|
|||
|
random decisions. In terms of languages recognized, these have the
|
|||
|
same power as deterministic machines. However, time considerations
|
|||
|
are more subtle. In particular, a notion of probabilistic run time
|
|||
|
is needed, rather than measures such as maximum run time used for
|
|||
|
ordinary machines.
|
|||
|
|
|||
|
A probabilistic Turing machine operates deterministically,
|
|||
|
except when it is in a special coin-tossing state (or states). In
|
|||
|
such a state the machine may enter either of two possible next
|
|||
|
states. The choice between these is made via the toss of an
|
|||
|
unbiased coin. The sequence of coin tosses may be considered to
|
|||
|
constitute the contents of an auxiliary read-only input tape, the
|
|||
|
random tape, which contains a binary string. Thus a computation by
|
|||
|
a probabilistic machine is a function of two variables, the
|
|||
|
ordinary input tape and the random tape.
|
|||
|
|
|||
|
If the random tape is unspecified, the output of the computation
|
|||
|
of probabilistic machine M, M(x), is a random variable (e.g.,
|
|||
|
[MCEL77]): M produces output y with probability Pr{M(x) = y}. For
|
|||
|
a given input x, there may exist a y such that Pr{M(x) = y} > 1/2.
|
|||
|
Such a y is clearly unique if it exists, in which case we can write
|
|||
|
q(x) = y. This defines a partial function: q is undefined if no
|
|||
|
such y exists. The partial function q is said to be computed by M.
|
|||
|
The set accepted by M is the domain of q.
|
|||
|
|
|||
|
If x is accepted by M let e(x) = Pr{M(x) != y}. It is direct
|
|||
|
from definition that e(x) < 1/2. Suppose there exists a constant
|
|||
|
c < 1/2 such that e(x) <= c for all x in the domain of e. Then it
|
|||
|
may be said that M has bounded error probability (the error
|
|||
|
probability e is bounded away from 1/2), another concept important
|
|||
|
in zero-knowledge frameworks.
|
|||
|
|
|||
|
Again leaving the random tape unspecified, Pr{M(x) = y in time
|
|||
|
n} is the probability that probabilistic Turing machine M with
|
|||
|
input x gives output y in some computation of at most n steps. The
|
|||
|
probabilistic run time T(x) of M is defined to be infinity if x is
|
|||
|
not accepted by M, i.e., if x is not in the domain of the partial
|
|||
|
function q computed by M. If x is in the domain of q, T(x) is the
|
|||
|
smallest n such that Pr{M(x) = q(x) in time n} > 1/2. This is
|
|||
|
somewhat analogous to defining the run time of a nondeterministic
|
|||
|
Turing machine to be the length of the shortest accepting
|
|||
|
computation.
|
|||
|
|
|||
|
A function is probabilistically computable if it is computed by
|
|||
|
some probabilistic Turing machine. There are many important
|
|||
|
examples of functions which are probabilistically computable in
|
|||
|
polynomial probabilistic run time and bounded error probability,
|
|||
|
but are not known to be computable in polynomial deterministic
|
|||
|
time, i.e., in P. An example is the characteristic function of the
|
|||
|
set of primes, which is probabilistically computable in polynomial
|
|||
|
time (e.g., [SOLO77]), but for which no deterministic algorithm is
|
|||
|
known.
|
|||
|
|
|||
|
Let BPP be the class of languages recognized by polynomial-
|
|||
|
bounded probabilistic Turing machines with bounded error
|
|||
|
probability. Letting < denote inclusion, it follows easily that P
|
|||
|
< BPP < NP. An important question, with implications for schemes
|
|||
|
such as RSA as well as zero-knowledge schemes, probabilistic
|
|||
|
encryption etc., is whether either of these inclusions is proper.
|
|||
|
|
|||
|
|
|||
|
Appendix E. Breaking knapsacks.
|
|||
|
|
|||
|
|
|||
|
We give a brief account of the demise of the Merkle/Hellman
|
|||
|
trapdoor knapsack public-key system and some of its variants. A
|
|||
|
much more complete discussion is given in [BRIC88].
|
|||
|
|
|||
|
We recall from section 4.2.1 that the security of this approach
|
|||
|
rests on the difficulty of solving knapsack problems of the form
|
|||
|
|
|||
|
|
|||
|
C = b1 * M1 + ... + bn * Mn,
|
|||
|
|
|||
|
|
|||
|
where the {bi} are obtained from superincreasing {ai} by modular
|
|||
|
"disguising:"
|
|||
|
|
|||
|
|
|||
|
bi = w * ai mod u.
|
|||
|
|
|||
|
|
|||
|
Around 1982, several authors (e.g.[DESM83]) made the observation
|
|||
|
that if W * w <20> 1 (mod u), where W may be found as in appendix H,
|
|||
|
then for some {ki},
|
|||
|
|
|||
|
|
|||
|
ai = W * bi - u * ki.
|
|||
|
|
|||
|
|
|||
|
In particular
|
|||
|
|
|||
|
|
|||
|
a1 = W * b1 - u * k1,
|
|||
|
|
|||
|
|
|||
|
and hence
|
|||
|
|
|||
|
|
|||
|
bi * k1 - b1 * ki = (b1 * ai - bi * a1)/u.
|
|||
|
|
|||
|
|
|||
|
Since u > a1 +...+ an, bi < u, and a1 < ai,
|
|||
|
|
|||
|
|
|||
|
|bi * k1 - b1 * ki| < uai/(a1+...+an).
|
|||
|
|
|||
|
|
|||
|
Now it is easily shown that
|
|||
|
|
|||
|
|
|||
|
ai+j <20> 2j-1 * (ai + 1),
|
|||
|
|
|||
|
|
|||
|
and hence
|
|||
|
|
|||
|
|
|||
|
|bi * k1 - b1 * ki| < 2i+1-n * u.
|
|||
|
|
|||
|
|
|||
|
Thus
|
|||
|
|
|||
|
|
|||
|
|k1/ki - b1/bi| < 2i+1-n*u/kibi < 2i+1-n*u/bi.
|
|||
|
|
|||
|
|
|||
|
This shows that the {ki} are in fact not random; they are
|
|||
|
determinable via the above inequalities if u is known. Shamir
|
|||
|
[SHAM84b] observed that an intruder merely seeks any trapdoor, as
|
|||
|
represented by any u, w, and {ai} which produce an easy knapsack.
|
|||
|
Thus the last inequality may be regarded as an integer programming
|
|||
|
problem. In this particular instance Shamir noted that the
|
|||
|
algorithm of Lenstra [LENS83] is applicable, together with
|
|||
|
classical methods of Diophantine approximation. This yields the
|
|||
|
{ki}, and the system is then broken easily.
|
|||
|
|
|||
|
Lenstra's algorithm made use of the Lovasz lattice basis
|
|||
|
reduction algorithm [LENS82], one of the basic tools in "unusually
|
|||
|
good" simultaneous diophantine approximation [LAGA84]. This
|
|||
|
approach was utilized by Adleman [ADLE82] to break the
|
|||
|
Shamir/Graham knapsack, and by Brickell [BRIC84] to break the
|
|||
|
iterated Merkle/Hellman knapsack. The multiplicative version was
|
|||
|
broken by Odlyzko [ODLY84]. In fact all major proposed knapsacks
|
|||
|
based on modular disguises have been broken using this approach.
|
|||
|
|
|||
|
It should be noted that the low-density attacks
|
|||
|
([BRIC83],[LAGA83]) are successful where finding trapdoors fails.
|
|||
|
These use a measure of density for a knapsack with coefficients
|
|||
|
b1,...,bn defined by density = n/(log max {bi}). This type of attack
|
|||
|
is independent of whether the knapsack is a disguised version of
|
|||
|
another. Trapdoors, in contrast, are easiest to find for high-
|
|||
|
density knapsacks.
|
|||
|
|
|||
|
The concept of density is related to two important parameters
|
|||
|
of cryptosystems, namely information rate and expansion factor d.
|
|||
|
In [LAGA84] the information rate is defined to be the ratio of the
|
|||
|
size of plaintext to the maximum size of the ciphertext. This is
|
|||
|
the reciprocal of d, i.e., ciphertext/plaintext. Information rate
|
|||
|
is essentially the same as density, although for the above knapsack
|
|||
|
and modulus u it is defined slightly differently, namely as n/(log
|
|||
|
nu). Both definitions are derived from approximations to the actual
|
|||
|
ciphertext size, which is log(b1 * M1+...+bn * Mn). Lagarias notes
|
|||
|
that the attack in [SHAM84b] runs in time O(P(n)*nd) for a
|
|||
|
polynomial P. Hence the attack is feasible if d is fixed but not
|
|||
|
if the expansion factor d is large. This illustrates the
|
|||
|
interrelation between security and practicality.
|
|||
|
|
|||
|
|
|||
|
Appendix F. Birthday attacks.
|
|||
|
|
|||
|
|
|||
|
In section 4 we noted several usages of birthday attacks against
|
|||
|
hash functions. Here we give a brief summary of the relevant
|
|||
|
mathematics.
|
|||
|
|
|||
|
Suppose H is a function which has m possible outputs. Whenever
|
|||
|
H outputs a value it is totally random and independent of any
|
|||
|
previous values which have been output.
|
|||
|
|
|||
|
If H is evaluated k times, each output is akin to an object
|
|||
|
placed in one of m cells corresponding to the range of H. Since the
|
|||
|
k values of H are independent, any object could be placed in any
|
|||
|
of m cells; the total number of ways of distributing the k objects
|
|||
|
is mk. If no two objects are to be placed in any cell (i.e. if
|
|||
|
there are to be no collisions in applying H k times), the first
|
|||
|
object can be placed anywhere; the second can go in any of the m-
|
|||
|
1 remaining cells; the third in m-2 cells; etc. The total number
|
|||
|
of ways of distributing the objects is m(m-1)...(m-k+1) (sometimes
|
|||
|
called a falling factorial). The probability of no collisions is
|
|||
|
m(m-1)...(m-k+1)/mk. Hence the probability of at least one
|
|||
|
collision is
|
|||
|
|
|||
|
|
|||
|
P(m,k) = 1 - (m-1)...(m-k+1)/mk-1
|
|||
|
|
|||
|
= 1 - (1 - 1/m)...(1 - (k-1)/m).
|
|||
|
|
|||
|
|
|||
|
This yields
|
|||
|
|
|||
|
|
|||
|
LEMMA F.1. Suppose the function H, with m possible outputs, is
|
|||
|
evaluated k times, where m > k > (2cm)1/2 for some constant c. Then
|
|||
|
the probability of at least one collision (i.e., x and y with H(x)
|
|||
|
= H(y) for some x,y) is at least 1 - e-c, e = 2.718...
|
|||
|
|
|||
|
|
|||
|
Proof: for 0 < x < 1,
|
|||
|
|
|||
|
|
|||
|
1 - x < 1 - x + x2(1 - x/3)/2 + x4(1 - x/5)/24 + ...
|
|||
|
|
|||
|
= e-x.
|
|||
|
|
|||
|
|
|||
|
For k < m this gives
|
|||
|
|
|||
|
|
|||
|
(1 - 1/m)...(1 - (k-1)/m) < e-1/m...-(k-1)/m)
|
|||
|
|
|||
|
= e-k(k-1)/2m.
|
|||
|
|
|||
|
|
|||
|
Thus
|
|||
|
|
|||
|
|
|||
|
P(m,k) > 1 - e-k(k-1)/2m
|
|||
|
|
|||
|
|
|||
|
The lemma follows. QED.
|
|||
|
|
|||
|
|
|||
|
EXAMPLE F.1. Suppose the H of lemma F.1 is evaluated k times
|
|||
|
where k > (2(ln 2)m)1/2 = 1.17 * m1/2. Then the probability of at
|
|||
|
least one collision is > 1/2.
|
|||
|
|
|||
|
|
|||
|
This suggests an attack on hash functions. Its name derives from
|
|||
|
the classical problem of computing the probability that two members
|
|||
|
of a group of people have the same birthday.
|
|||
|
|
|||
|
|
|||
|
Appendix G. Modular arithmetic and Galois fields.
|
|||
|
|
|||
|
|
|||
|
We give a brief introduction to arithmetic modulo n where n is
|
|||
|
a positive integer. A ring structure may be imposed on Zn =
|
|||
|
{0,1,...,n-1} by doing addition, subtraction and multiplication mod
|
|||
|
n (e.g., [DENN83], [HERS64] or any book on elementary number
|
|||
|
theory). We use GCD for greatest common divisor; i.e., GCD(x,y) =
|
|||
|
n if n is the largest positive integer dividing x and y. For n >
|
|||
|
1 let
|
|||
|
|
|||
|
|
|||
|
Zn* = {x <20> Zn : x > 0 and GCD(x,n) = 1}.
|
|||
|
|
|||
|
|
|||
|
For example, Z10* = {1,3,7,9}. That is, Zn* consists of the
|
|||
|
nonzero elements of Zn which are relatively prime to n.
|
|||
|
|
|||
|
|
|||
|
If a <20> Zn* let
|
|||
|
|
|||
|
a * Zn* = {a * x mod n : x <20> Zn*}.
|
|||
|
|
|||
|
|
|||
|
For example, 2 * Z10* = {2,6,14,18} mod 10 = {2,6,4,8}, 3 * Z10*
|
|||
|
= {3,9,21,27} mod 10 = Z10*. We have:
|
|||
|
|
|||
|
|
|||
|
LEMMA G.1. Suppose n > 1 and a <20> Zn*. Then
|
|||
|
|
|||
|
a. For any x and y: a * x <20> a * y ( mod n ) iff x <20> y (mod
|
|||
|
n).
|
|||
|
|
|||
|
b. a * Zn* = Zn*.
|
|||
|
|
|||
|
c. a has a multiplicative inverse modulo n; i.e.
|
|||
|
there exists b <20> Zn* such that b * a <20> 1 (mod n).
|
|||
|
|
|||
|
|
|||
|
Proof: if x <20> y (mod n) then trivially a * x <20> a * y (mod n).
|
|||
|
Conversely, suppose a * x <20> a * y (mod n). Then n | (a * (x - y)).
|
|||
|
But GCD(a,n) = 1, so n | (x - y), i.e. x <20> y (mod n). Thus (a)
|
|||
|
holds.
|
|||
|
|
|||
|
For (b): if x <20> Zn* then GCD(x,n) = 1, so GCD(a*x,n) = 1. Thus
|
|||
|
a * x mod n <20> Zn*. Hence a * Zn* is contained in Zn*. By (a), if a *
|
|||
|
x <20> a * y (mod n), then x <20> y (mod n). Thus a * Zn* consists of n
|
|||
|
distinct elements, and cannot be a proper subset of Zn*; (b)
|
|||
|
follows. In particular, since 1 <20> Zn*, there exists some b <20> Zn* such
|
|||
|
that a * b mod n = 1; (c) follows. QED.
|
|||
|
|
|||
|
|
|||
|
G.1 The Euler Phi function.
|
|||
|
|
|||
|
|
|||
|
The cardinality of a set S is denoted by |S|. In particular,|Zn*|
|
|||
|
is denoted by <20>(n), the Euler totient function.
|
|||
|
|
|||
|
|
|||
|
LEMMA G.1.1.
|
|||
|
|
|||
|
a. If p is prime then <20>(p) = p-1.
|
|||
|
|
|||
|
b. If n = p * q, p and q prime, then <20>(n) = (p-1)(q-1).
|
|||
|
|
|||
|
|
|||
|
Proof: (a) is trivial, since Zp* = {1,...,p-1}.
|
|||
|
|
|||
|
For (b): let Yp = {p,...,(q-1)p}, i.e., the nonzero elements of
|
|||
|
Zn divisible by p. Let Yq = {q,...,(p-1)q}, i.e., the nonzero
|
|||
|
elements of Zn divisible by q. If a * p = b * q, then p | b and q
|
|||
|
| a; hence a * p and b * q cannot be in Yp and Yq, respectively.
|
|||
|
Thus Yp and Yq are disjoint. Letting + denote disjoint union,
|
|||
|
|
|||
|
|
|||
|
Zn = {0} + Yp + Yq + Zn*.
|
|||
|
|
|||
|
|
|||
|
Taking cardinalities,
|
|||
|
|
|||
|
|
|||
|
p * q = 1 + q-1 + p-1 + |Zn*|.
|
|||
|
|
|||
|
|
|||
|
Then (b) follows. QED.
|
|||
|
|
|||
|
|
|||
|
G.2 The Euler-Fermat Theorem.
|
|||
|
|
|||
|
|
|||
|
LEMMA G.2.1 (Euler's Theorem). Suppose n > 0 and a <20> Zn*. Then
|
|||
|
|
|||
|
|
|||
|
a<>(n) <20> 1 (mod n).
|
|||
|
|
|||
|
|
|||
|
Proof: if Zn* = {r1,...,rm} then a restatement of (b) of lemma G.1
|
|||
|
is
|
|||
|
|
|||
|
|
|||
|
{a * r1 mod n, ... , a * rm mod n} = Zn*.
|
|||
|
|
|||
|
|
|||
|
Hence
|
|||
|
|
|||
|
|
|||
|
a * r1 * ... * a * rm <20> r1 * ... * rm (mod n).
|
|||
|
|
|||
|
|
|||
|
Thus
|
|||
|
|
|||
|
|
|||
|
am * r1 * ... * rm <20> r1 *... * rm (mod n).
|
|||
|
|
|||
|
|
|||
|
By (a) of lemma G.1, each ri above may be canceled, leaving
|
|||
|
|
|||
|
|
|||
|
am <20> 1 (mod n).
|
|||
|
|
|||
|
|
|||
|
Noting that by definition m = <20>(n) gives Euler's Theorem. QED.
|
|||
|
|
|||
|
|
|||
|
COROLLARY G.2.1 (Fermat's Theorem). Suppose p is prime and a <20>
|
|||
|
Zp*. Then
|
|||
|
|
|||
|
|
|||
|
ap-1 <20> 1 (mod p).
|
|||
|
|
|||
|
|
|||
|
Proof: use (a) of lemma G.1.1 in lemma G.2.1. QED.
|
|||
|
|
|||
|
|
|||
|
COROLLARY G.2.2. Suppose n > 0, a <20> Zn*, and x <20> 1 (mod m) where
|
|||
|
m = <20>(n). Then ax <20> a (mod n).
|
|||
|
|
|||
|
|
|||
|
Proof: we have x = m * y + 1 for some y. Now by lemma G.2.1,
|
|||
|
|
|||
|
|
|||
|
ax <20> (am)y * a <20> 1y * a <20> a (mod n).
|
|||
|
|
|||
|
|
|||
|
QED.
|
|||
|
|
|||
|
|
|||
|
COROLLARY G.2.3. Suppose n > 0. Let m = <20>(n). Suppose e and d
|
|||
|
are in Zm* and e * d <20> 1 (mod m). Let E(M) = Me mod n and D(C) = Cd
|
|||
|
mod n. Then D(E(M)) = E(D(M)) = M for any M in [0,n).
|
|||
|
|
|||
|
|
|||
|
Proof:
|
|||
|
|
|||
|
|
|||
|
D(E(M)) <20> (Me mod n)d mod n <20> Me*d mod n <20> M (mod n).
|
|||
|
|
|||
|
|
|||
|
The last step uses corollary G.2.2. Also 0 <20> D(E(M)) < n and 0
|
|||
|
<EFBFBD> M < n, so D(E(M)) = M. Similarly E(D(M)) = M. QED.
|
|||
|
|
|||
|
|
|||
|
G.3 Galois fields.
|
|||
|
|
|||
|
|
|||
|
Lemma G.1 shows that Zn* is an abelian group (e.g., [HERS64] p.
|
|||
|
27) under the operation of multiplication modulo n; Zn* is called
|
|||
|
the multiplicative group of units of Zn.
|
|||
|
|
|||
|
In particular, if p is prime then Zp* = {1,...,p-1} is a group;
|
|||
|
i.e., each nonzero element of Zp has a multiplicative inverse
|
|||
|
modulo p. Thus the ring Zp = {0,1,...,p-1} is in fact a finite
|
|||
|
field (e.g., [HERS64] p. 84) with p elements.
|
|||
|
|
|||
|
It can be shown (e.g., [HERS64] p. 314) that every finite field
|
|||
|
has pn elements for some prime p. These are called the Galois
|
|||
|
fields, and denoted GF(pn). We have already noted that GF(p) = Zp
|
|||
|
is defined by doing arithmetic modulo p. The elements of Zp are
|
|||
|
called the residues modulo p; i.e., each integer x has a unique
|
|||
|
representation x = q * p + r where r <20> Zp. To define GF(pn) we
|
|||
|
choose an irreducible polynomial f(x) of degree n in the ring of
|
|||
|
polynomials modulo p (e.g., [DENN83] p. 49). Now arithmetic may be
|
|||
|
defined on this ring of polynomials, modulo f(x); i.e., write g(x)
|
|||
|
<EFBFBD> h(x) iff f(x) is a divisor of g(x) - h(x). Each polynomial g(x)
|
|||
|
has a unique representation g(x) = q(x)f(x) + r(x) for some
|
|||
|
polynomial r(x) of degree at most n-1. The residues modulo f(x) are
|
|||
|
the elements of GF(pn). These consist of polynomials of degree <20> n-
|
|||
|
1 with coefficients from Zp. Each of the n coefficients of a
|
|||
|
residue has p possible values, accounting for the pn element count
|
|||
|
for GF(pn).
|
|||
|
|
|||
|
|
|||
|
Appendix H. Euclid's algorithm.
|
|||
|
|
|||
|
|
|||
|
On a number of occasions we referred to Euclid's algorithm,
|
|||
|
which can be used to find greatest common divisors and
|
|||
|
multiplicative inverses. We give some versions of it here. These
|
|||
|
versions are recursive, and minimize storage requirements.
|
|||
|
|
|||
|
Suppose x and y are arbitrary positive integers. Their greatest
|
|||
|
common divisor GCD(x,y) can be computed in O(log max{x,y}) steps
|
|||
|
by recursively employing GCD(s,t) = GCD(s,t mod s). This is
|
|||
|
Euclid's algorithm:
|
|||
|
|
|||
|
|
|||
|
function GCD(x,y) returns integer;
|
|||
|
/* return greatest common divisor of x > 0 and y > 0 */
|
|||
|
s := x; t := y;
|
|||
|
while (s > 0) do
|
|||
|
div := s; s := t mod s; t := div;
|
|||
|
end while;
|
|||
|
return(div);
|
|||
|
end GCD;
|
|||
|
|
|||
|
|
|||
|
This is readily generalized to
|
|||
|
|
|||
|
|
|||
|
function Multi_GCD(m; x : array[0..m]);
|
|||
|
/* for m > 0 return greatest common divisor of
|
|||
|
x1,...,xm > 0 */
|
|||
|
if (m = 1) return(x1)
|
|||
|
else return(GCD(xm,Multi_GCD(m-1,x)));
|
|||
|
end Multi_GCD;
|
|||
|
|
|||
|
|
|||
|
The above runs in O(m * log max{xi}) time.
|
|||
|
|
|||
|
For x <20> Zn*, with latter as in appendix G, a simple extension of
|
|||
|
GCD yields the multiplicative inverse of x modulo n, i.e., u with
|
|||
|
x * u <20> 1 (mod n). With [y] denoting the largest integer <20> y, the
|
|||
|
extended Euclid algorithm to find u is:
|
|||
|
|
|||
|
|
|||
|
function INVERSE(n,x) returns integer;
|
|||
|
/* for n > 0 and x <20> Zn* return u <20> Zn*
|
|||
|
with u * x <20> 1 (mod n) */
|
|||
|
procedure Update(a,b);
|
|||
|
temp := b; b := a - y * temp; a := temp;
|
|||
|
end Update;
|
|||
|
g := n; h := x; w := 1; z := 0; v := 0; r := 1;
|
|||
|
while (h > 0) do
|
|||
|
y : = [g/h]; Update(g,h); Update(w,z); Update(v,r);
|
|||
|
end while;
|
|||
|
return(v mod n);
|
|||
|
end INVERSE;
|
|||
|
|
|||
|
|
|||
|
For example, for n = 18, x = 7, this gives the values
|
|||
|
|
|||
|
|
|||
|
g: 18 7 4 3 1
|
|||
|
h: 7 4 3 1 0
|
|||
|
w: 1 0 1 -1 2
|
|||
|
z: 0 1 -1 2 -7
|
|||
|
v: 0 1 -2 3 -5
|
|||
|
r: 1 -2 3 -5 18
|
|||
|
y: 2 1 1 3
|
|||
|
|
|||
|
|
|||
|
Finally u = -5 mod 18 = 13 is returned. This is equivalent to
|
|||
|
finding the sequence 7/18, 2/5, 1/3, 1/2, 0/1 in which each
|
|||
|
neighboring pair is a pair of Farey fractions; a/b and c/d are
|
|||
|
Farey fractions (e.g., [RADE64]) if a * d - b * c = <20>1. We have
|
|||
|
found 2 * 18 - 5 * 7 = 1, so that -5 * 7 <20> 1 (mod 18), or
|
|||
|
equivalently 13 * 7 <20> 1 (mod 18). Thus finding multiplicative
|
|||
|
inverses modulo n can also be done in O(log n) steps.
|
|||
|
|
|||
|
This will also find s with u * x + s * n = 1: take s = (1 - u
|
|||
|
* x) / n. More generally we have (with GCD(x) = x):
|
|||
|
|
|||
|
|
|||
|
procedure Coeffs(m; x : in array[1..m]; u : out array[1..m]);
|
|||
|
/* given m > 0 and x1,...,xm > 0 with GCD(x1,...,xm) = 1,
|
|||
|
find u1,...,um with u1x1 + ... + umxm = 1 */
|
|||
|
if (m = 1) return(x1)
|
|||
|
else
|
|||
|
g = Multi_GCD(m-1,x);
|
|||
|
for i := 1 to m-1 do yi := xi/g;
|
|||
|
Coeffs(m-1,y,u');
|
|||
|
um := INVERSE(g,xm);
|
|||
|
b := (1 - um*xm)/g;
|
|||
|
for i := 1 to m-1 do ui := b*ui';
|
|||
|
end else;
|
|||
|
end Coeffs;
|
|||
|
|
|||
|
|
|||
|
This runs in O(m*log max{xi}) time.
|
|||
|
|
|||
|
|
|||
|
Appendix I. The Chinese Remainder Theorem.
|
|||
|
|
|||
|
|
|||
|
The Chinese Remainder Theorem is useful for purposes such as
|
|||
|
simplifying modular arithmetic. In particular we note in a later
|
|||
|
appendix that its use increases the efficiency of decryption in
|
|||
|
RSA.
|
|||
|
|
|||
|
We begin with a special case: with Zn as in appendix G, we have
|
|||
|
|
|||
|
|
|||
|
LEMMA I.1. Suppose p and q are primes and p < q. Then:
|
|||
|
|
|||
|
|
|||
|
a. For arbitrary a <20> Zp and b <20> Zq, there exists a unique
|
|||
|
x <20> Zpq with
|
|||
|
|
|||
|
x <20> a (mod p),
|
|||
|
|
|||
|
x <20> b (mod q).
|
|||
|
|
|||
|
b. If u * q <20> 1 (mod p), the x in (a) is given by
|
|||
|
|
|||
|
x = (((a - b) * u) mod p) * q + b.
|
|||
|
|
|||
|
|
|||
|
Proof: we note that for any y and s, 0 <20> y mod s <20> s-1. Thus if
|
|||
|
x and u are as in (b), 0 <20> x <20> (p-1) * q + q - 1 = p * q - 1. Hence
|
|||
|
x <20> Zpq. Trivially x <20> b (mod q). Also
|
|||
|
|
|||
|
|
|||
|
x <20> (((a - b) * u) mod p) * q + b
|
|||
|
|
|||
|
<20> (a - b) * u * q + b
|
|||
|
|
|||
|
<20> (a - b) * 1 + b
|
|||
|
|
|||
|
<20> a (mod p).
|
|||
|
|
|||
|
|
|||
|
Thus x is a solution to the simultaneous linear system in (a).
|
|||
|
To show that it is unique, suppose x' <20> a (mod p) and x' <20> b (mod
|
|||
|
q). Then for some k and m, x - x' = k * p = m * q. Thus k = q * k'
|
|||
|
for some k'; hence x - x' = p * q * k', i.e., x' = x - p * q * k'.
|
|||
|
Since 0 <20> x <20> p * q - 1, if k' > 0 then x' < 0; if k' < 0 then x'
|
|||
|
<EFBFBD> p * q. Hence x' <20> Zpq iff k' = 0, i.e., x' = x. QED.
|
|||
|
|
|||
|
We note that in (b) above, u can be found via the INVERSE
|
|||
|
function of appendix H.
|
|||
|
|
|||
|
The condition p < q is arbitrary, but useful in noting
|
|||
|
|
|||
|
COROLLARY I.1. Suppose p and q are primes, p < q, 0 <20> x < p *
|
|||
|
q, and a = x mod p, b = x mod q. Then
|
|||
|
|
|||
|
|
|||
|
a. x = (((a - (b mod p)) * u) mod p) * q + b
|
|||
|
(a <20> b mod p)
|
|||
|
|
|||
|
b. x = (((a + p - (b mod p)) * u) mod p) * q + b
|
|||
|
(a <20> b mod p)
|
|||
|
|
|||
|
|
|||
|
Proof: immediate from lemma I.1. QED.
|
|||
|
|
|||
|
|
|||
|
The corollary provides an optimal framework for representing x
|
|||
|
via a and b, i.e., the residues of x modulo p and q, respectively.
|
|||
|
|
|||
|
Although the most general case of the Chinese Remainder Theorem
|
|||
|
is not used in this exposition, we remark that the above can be
|
|||
|
extended:
|
|||
|
|
|||
|
|
|||
|
THEOREM I.1. Given pairwise relatively prime moduli {p1,...,pn}
|
|||
|
and arbitrary {a1,...,an}, there exists a unique x <20> [0,p1*..*pn)
|
|||
|
satisfying x <20> ai (mod pi) for each i.
|
|||
|
|
|||
|
|
|||
|
Proof: a straightforward generalization of the above (e.g.,
|
|||
|
[DENN83] p. 47).
|
|||
|
|
|||
|
|
|||
|
Appendix J. Quadratic residues and the Jacobi symbol.
|
|||
|
|
|||
|
|
|||
|
Quadratic residues play a role in primality testing as we note
|
|||
|
in a later appendix. In appendices O and P we also note their usage
|
|||
|
in encryption.
|
|||
|
|
|||
|
Let Zn* be as in appendix G. For a positive integer n and a <20> Zn*,
|
|||
|
a is called a quadratic residue modulo n if x2 <20> a (mod n) for some
|
|||
|
x; otherwise a is a quadratic nonresidue.
|
|||
|
|
|||
|
|
|||
|
LEMMA J.1. Suppose n > 0 and a is a quadratic residue modulo n.
|
|||
|
Then every y with y2 <20> a (mod n) has the form y = x + k * n where
|
|||
|
k is an integer and x <20> Zn*.
|
|||
|
|
|||
|
|
|||
|
Proof: suppose y2 <20> a (mod n). Let x = y mod n. Then x <20> [0,n).
|
|||
|
Also, x2 <20> a (mod n). Now x2 = a + j * n for some j. Suppose for
|
|||
|
some m we have m > 0, m | x and m | n. Then m | a, so m = 1 since
|
|||
|
GCD(a,n) = 1. Hence x <20> Zn*; also y = x + k * n for some k. QED.
|
|||
|
|
|||
|
|
|||
|
Thus the square roots of a quadratic residue modulo n can be
|
|||
|
taken to be elements of Zn*; all other square roots are obtained by
|
|||
|
adding multiples of n to these.
|
|||
|
|
|||
|
|
|||
|
J.1 Quadratic residues modulo a prime.
|
|||
|
|
|||
|
|
|||
|
If p is prime and 0 < a < p, a is a quadratic residue modulo p
|
|||
|
if and only if x2 <20> a (mod p) for some x with 0 < x < p. For
|
|||
|
example, the quadratic residues modulo 7 are
|
|||
|
|
|||
|
|
|||
|
{12,22,32,42,52,62} mod 7 = {1,2,4}.
|
|||
|
|
|||
|
|
|||
|
The quadratic nonresidues modulo 7 are {3,5,6}.
|
|||
|
|
|||
|
Given a prime p, let s = (p-1)/2 and
|
|||
|
|
|||
|
|
|||
|
Sp = {x2 mod p : 0 < x <20> s}.
|
|||
|
|
|||
|
|
|||
|
Then Sp is a set of quadratic residues modulo p. In fact we have
|
|||
|
|
|||
|
|
|||
|
LEMMA J.1.1. Suppose p > 2 is prime. Let s = (p-1)/2. Then
|
|||
|
|
|||
|
a. The elements of Sp are precisely the quadratic residues
|
|||
|
modulo p.
|
|||
|
|
|||
|
b. There are s quadratic residues modulo p.
|
|||
|
|
|||
|
c. There are s quadratic nonresidues modulo p.
|
|||
|
|
|||
|
|
|||
|
Proof: as noted above, Sp is a subset of the set of quadratic
|
|||
|
residues modulo p. Furthermore, if x2 <20> y2 (mod p) then p | x2-y2;
|
|||
|
hence p | x-y or p | x+y. If x and y are in (0,s] then 1 < x+y <
|
|||
|
p; thus p | x-y; hence x = y. It follows that Sp contains distinct
|
|||
|
elements. QED.
|
|||
|
|
|||
|
Now suppose a is a quadratic residue, x2 <20> a (mod p), and x <20>
|
|||
|
Zp*. We note
|
|||
|
|
|||
|
|
|||
|
(p - x)2 <20> p2 - 2 * p * x + x2 <20> a (mod p).
|
|||
|
|
|||
|
|
|||
|
Since 0 < x < p, either x or p - x is in (0,s]. It follows that
|
|||
|
a <20> Sp. Thus the set of quadratic residues modulo p is contained in
|
|||
|
S. Hence the two sets are identical, establishing (a). Since |Sp|
|
|||
|
= s, (b) follows. Also, the complement of Sp in Zp* is the set of
|
|||
|
quadratic nonresidues modulo p. Since |Zp*| = 2s, the complement of
|
|||
|
Sp also has cardinality s; (c) follows. QED.
|
|||
|
|
|||
|
|
|||
|
J.2 The Jacobi symbol.
|
|||
|
|
|||
|
|
|||
|
If p is a prime > 2 and 0 < a < p, the Legendre symbol (a/p) is
|
|||
|
a characteristic function of the set of quadratic residues modulo
|
|||
|
p (e.g., [RADE64]):
|
|||
|
|
|||
|
|
|||
|
a. (a/p) = 1 if a is a quadratic residue mod p.
|
|||
|
|
|||
|
b. (a/p) = -1 if a is a quadratic nonresidue mod p.
|
|||
|
|
|||
|
|
|||
|
More generally, if k > 1 is odd and h is in Zk*, the Jacobi
|
|||
|
symbol (h/k) may be defined as follows:
|
|||
|
|
|||
|
|
|||
|
a. The Jacobi symbol (h/p) coincides with the Legendre symbol
|
|||
|
if p is prime.
|
|||
|
|
|||
|
b. If k = p1*...*pm with pi prime, (h/k) = (h/p1)*...*(h/pm).
|
|||
|
|
|||
|
|
|||
|
An efficient mode for computing the Jacobi symbol is via the
|
|||
|
recursion:
|
|||
|
|
|||
|
|
|||
|
a. (1/k) = 1.
|
|||
|
|
|||
|
b. (a*b/k) = (a/k)(b/k).
|
|||
|
|
|||
|
c. (2/k) = 1 if (k2-1)/8 is even, -1 otherwise.
|
|||
|
|
|||
|
d. (b/a) = ((b mod a)/a).
|
|||
|
|
|||
|
e. If GCD(a,b) = 1:
|
|||
|
|
|||
|
i. (a/b)(b/a) = 1 if (a-1)(b-1)/4 is even.
|
|||
|
|
|||
|
ii. (a/b)(b/a) = -1 if (a-1)(b-1)/4 is odd.
|
|||
|
|
|||
|
|
|||
|
The key step in the recursion is (e), which is Gauss' law of
|
|||
|
quadratic reciprocity (e.g., [RADE64]). The above shows that the
|
|||
|
Jacobi symbol (a/n) can be computed in O(log n) steps.
|
|||
|
|
|||
|
|
|||
|
J.3 Square roots modulo a prime.
|
|||
|
|
|||
|
|
|||
|
Regarding solutions of x2 <20> a (mod p), i.e., the square roots of
|
|||
|
a modulo p, we have:
|
|||
|
|
|||
|
|
|||
|
LEMMA J.3.1. Suppose p > 2 is prime. Let s = (p-1)/2. Suppose
|
|||
|
a is a quadratic residue modulo p. Then
|
|||
|
|
|||
|
|
|||
|
a. a has exactly two square roots modulo p in Zp*. One of
|
|||
|
these lies in (0,s] and the other in (s,p-1].
|
|||
|
|
|||
|
b. the square roots of a modulo p can be found in
|
|||
|
probabilistic polynomial time.
|
|||
|
|
|||
|
|
|||
|
Proof: by lemma J.1.1 we know that a <20> Sp as defined in J.1;
|
|||
|
hence there exists a unique x in (0,s] with x2 <20> a (mod p). Then y
|
|||
|
= p - x satisfies y2 <20> a (mod p), and y is in (s,p-1]. Conversely,
|
|||
|
suppose y is in (s,p-1] and y2 <20> a (mod p). Then x = p - y is in
|
|||
|
(0,s], and x2 <20> a (mod p). Hence y is unique. Thus we have (a).
|
|||
|
|
|||
|
For (b) we invoke a probabilistic polynomial-time algorithm for
|
|||
|
finding square roots modulo a prime (e.g., [PERA86] or p. 22 of
|
|||
|
[KRAN86]). QED.
|
|||
|
|
|||
|
|
|||
|
J.4 Quadratic residuosity modulo a prime.
|
|||
|
|
|||
|
|
|||
|
Deciding quadratic residuosity plays a role in both primality
|
|||
|
testing and probabilistic encryption. For a prime p > 2, to decide
|
|||
|
whether a given element a <20> Zp* is a quadratic residue modulo p,
|
|||
|
define
|
|||
|
|
|||
|
|
|||
|
ep(a) = as mod p (s = (p-1)/2).
|
|||
|
|
|||
|
|
|||
|
Then we have
|
|||
|
|
|||
|
|
|||
|
LEMMA J.4.1. If p > 2 is a prime and a <20> Zp*, ep(a) = 1 if and
|
|||
|
only if a is a quadratic residue modulo p; ep(a) = p - 1 if and
|
|||
|
only if a is a quadratic nonresidue modulo p.
|
|||
|
|
|||
|
|
|||
|
Proof: by the Euler/Fermat Theorem (cor. G.2.1), ep(a)2 <20> 1 (mod
|
|||
|
p). By lemma J.3.1, 1 has exactly two square roots modulo p in Zp*,
|
|||
|
namely 1 and p - 1. Hence ep(a) = 1 or p - 1. If a is a quadratic
|
|||
|
residue modulo p, then a = x2 mod p for some x with 0 < x < p. Then
|
|||
|
ep(a) = xp-1 mod p. Again by Euler/Fermat, ep(a) = 1. Thus all s
|
|||
|
quadratic residues a satisfy as - 1 = 0 (mod p). An s-th degree
|
|||
|
congruence modulo p has at most s solutions (e.g., [RADE64] p. 21).
|
|||
|
Thus all quadratic nonresidues b must have ep(b) = p - 1. QED.
|
|||
|
|
|||
|
|
|||
|
Also, ep can be evaluated in O(log p) time. Thus quadratic
|
|||
|
residuosity mod p can be decided in O(log p) time.
|
|||
|
|
|||
|
|
|||
|
Appendix K. Primitive roots and discrete logarithms.
|
|||
|
|
|||
|
|
|||
|
The use of primitive roots was noted in sections 2.2 and 4.2.2.
|
|||
|
We also observed that the security of exponentiation-based
|
|||
|
cryptosystems depends in part on the difficulty of computing
|
|||
|
discrete logarithms. Here we briefly explore these topics.
|
|||
|
|
|||
|
Let Zp* be as in appendix G. Suppose p is a prime and a <20> Zp*.
|
|||
|
Suppose m > 0, am <20> 1 (mod p), but ar !<21> 1 (mod p) for any r with
|
|||
|
0 < r < m. Then we say that a belongs to the exponent m modulo p.
|
|||
|
The existence of m is guaranteed by the Euler/Fermat Theorem (cor.
|
|||
|
G.2.1), which shows m < p. Let
|
|||
|
|
|||
|
|
|||
|
Cp(a) = {ax mod p : 0 <20> x < m}.
|
|||
|
|
|||
|
|
|||
|
Then we have
|
|||
|
|
|||
|
|
|||
|
LEMMA K.1. Suppose p is prime, a <20> Zp*, and a belongs to the
|
|||
|
exponent m modulo p. Then:
|
|||
|
|
|||
|
|
|||
|
a. Cp(a) contains distinct elements; i.e. |Cp(a)| = m.
|
|||
|
|
|||
|
b. Cp(a) is a cyclic subgroup of Zp*.
|
|||
|
|
|||
|
c. m | p-1.
|
|||
|
|
|||
|
|
|||
|
Proof: suppose Cp(a) does not contain distinct elements. Then
|
|||
|
for some {k,j} in [0,m) with k < j we have ak <20> aj (mod p). Thus
|
|||
|
aj-k <20> 1 (mod p), contradiction. This gives (a). Now suppose x and
|
|||
|
y are in [0,m) and x + y = k * m + r where r is in [0,m). Since am
|
|||
|
<EFBFBD> 1 (mod p), ax * ay mod p = ar mod p. Thus Cp(a) is closed under
|
|||
|
multiplication, and forms a subgroup of Zp*; this is called the
|
|||
|
cyclic subgroup generated by a (e.g., [HERS64]). This gives (b).
|
|||
|
The order of a subgroup divides the order (= p - 1) of the whole
|
|||
|
group Zp* (ibid). This gives (c). QED.
|
|||
|
|
|||
|
If g belongs to the exponent p - 1 modulo prime p, g is called
|
|||
|
a primitive root modulo p.
|
|||
|
|
|||
|
|
|||
|
LEMMA K.2. Suppose p is a prime and g is a primitive root modulo
|
|||
|
p. Then Cp(g) = Zp*; that is, each y <20> [1,p) has a unique
|
|||
|
representation y = gx mod p for some x <20> [0,p-1).
|
|||
|
|
|||
|
|
|||
|
Proof: Cp(g) is a subset of Zp*. The result follows from lemma
|
|||
|
K.1, which shows |Cp(g)| = p - 1 = |Zp*|. QED.
|
|||
|
|
|||
|
|
|||
|
The x in lemma K.2 is the discrete logarithm, or index, of y
|
|||
|
modulo p with base = g. However, the range of the logarithm can be
|
|||
|
any interval of length p - 1. We have used [0,p-2], but, e.g., we
|
|||
|
could also take x to lie in [1,p-1].
|
|||
|
|
|||
|
A restatement of lemma K.2 is that the cyclic subgroup generated
|
|||
|
by the primitive root g modulo p is the whole group Zp*. Thus g is
|
|||
|
a generator of Zp*.
|
|||
|
|
|||
|
|
|||
|
LEMMA K.3. Suppose p > 2 is prime and p-1 has k distinct prime
|
|||
|
factors which are known. Then:
|
|||
|
|
|||
|
|
|||
|
a. The number of primitive roots modulo p is <20>(p-1), where
|
|||
|
<20> is the Phi function (app. G.1).
|
|||
|
|
|||
|
2. Testing a given a to determine if it is a primitive root
|
|||
|
modulo p can be done in time O(k * log p) = O((log p)2).
|
|||
|
|
|||
|
|
|||
|
Proof: for (a) see, e.g., [RADE64] p. 49. For (b), if the
|
|||
|
exponent of a modulo p is m, then m | p-1 by lemma K.1. Now m < p -
|
|||
|
1 iff m | (p-1)/q for some prime factor q of p, whence a(p-1)/q <20> 1
|
|||
|
(mod p). Thus a is a primitive root modulo p iff a(p-1)/q !<21> 1 (mod
|
|||
|
p) for each prime factor q of p. This condition can be tested for
|
|||
|
each of the k factors in O(log p) time. Clearly k = O(log p). QED.
|
|||
|
|
|||
|
|
|||
|
In particular, if p has the form 2q + 1 for prime q, it is easy
|
|||
|
to find the exponent m modulo p for a given a, since m = 2, q, or
|
|||
|
2q. It is also easy to find primitive roots modulo p: <20>(p-1) = q -
|
|||
|
1 = (p-3)/2; thus for large p, a random element of Zp* has about
|
|||
|
a 1/2 probability of being a primitive root.
|
|||
|
|
|||
|
|
|||
|
LEMMA K.4. Suppose p > 2 is prime and g is a primitive root
|
|||
|
modulo p. Let s = (p-1)/2. Then:
|
|||
|
|
|||
|
|
|||
|
a. gs <20> -1 (mod p).
|
|||
|
|
|||
|
b. g is a quadratic nonresidue modulo p.
|
|||
|
|
|||
|
|
|||
|
Proof: for (a): we note g0 <20> 1 (mod p). Since g is a generator
|
|||
|
of {1,g,...,gp-2} and 0 < s < p-1 we thus know gs !<21> 1 (mod p). Also,
|
|||
|
g2s <20> 1 (mod p), so that gs is a square root of 1 modulo p. By lemma
|
|||
|
J.3.1, 1 has exactly two square roots modulo p, namely 1 and -1.
|
|||
|
Thus gs <20> -1 (mod p).
|
|||
|
|
|||
|
For (b): suppose x2 <20> g (mod p). Now x <20> gr (mod p) for some r;
|
|||
|
hence g2r <20> g (mod p), and g2r-1 <20> 1 (mod p). Thus 2r - 1 <20> 0 (mod p-
|
|||
|
1), impossible since p - 1 is even. QED.
|
|||
|
|
|||
|
|
|||
|
Appendix L. Primality testing.
|
|||
|
|
|||
|
|
|||
|
Testing large integers to determine whether they are prime plays
|
|||
|
a major role in key generation in RSA and other public-key systems.
|
|||
|
We give a few examples of algorithms to effect this.
|
|||
|
|
|||
|
It is well-known (e.g., [KNUT81] p. 366) that if the number of
|
|||
|
primes between 1 and x is f(x), then with ln denoting natural
|
|||
|
logarithm (to base e = 2.718..),
|
|||
|
|
|||
|
|
|||
|
f(x) = x/(ln x) + O(x/(ln x)2).
|
|||
|
|
|||
|
|
|||
|
The number of primes between x and x + h is f(x + h) - f(x), and
|
|||
|
hence the probability that a number between x and x + h is prime
|
|||
|
is roughly
|
|||
|
|
|||
|
|
|||
|
(f(x+h)-f(x))/h = f'(x) = 1/(ln x) - 1/(ln x)2.
|
|||
|
|
|||
|
|
|||
|
That is, roughly ln x numbers must be tested before a prime is
|
|||
|
found near x; but the evens may be ignored, so that roughly (ln
|
|||
|
x)/2 odd numbers need be tested. For example, about (ln 10100)/2 =
|
|||
|
115 odd numbers must be tested to find a prime of about 100 digits.
|
|||
|
If multiples of small primes > 2 are eliminated, even fewer numbers
|
|||
|
need be tested before a prime is found (e.g., [GORD84]).
|
|||
|
|
|||
|
A number of tests have been given to establish the primality of
|
|||
|
a candidate. Proving primality deterministically (i.e., with
|
|||
|
certainty) is less difficult than factoring or computing discrete
|
|||
|
logarithms, but is nonetheless nontrivial. For example, the
|
|||
|
algorithms of [ADLE83] or [COHE84] could be used; but they have a
|
|||
|
run time on the order of
|
|||
|
|
|||
|
|
|||
|
(log n)c log log log n.
|
|||
|
|
|||
|
|
|||
|
Such deterministic algorithms are computationally infeasible or
|
|||
|
inadvisable unless high-performance computers are used for key
|
|||
|
generation. This may be undesirable even if a high-performance
|
|||
|
computer is available, since it may not constitute a
|
|||
|
cryptographically secure environment. For key generation on, e.g.,
|
|||
|
personal computers or smart cards, which is preferable from a
|
|||
|
security standpoint, more efficient algorithms are desirable. Thus,
|
|||
|
probabilistic tests may be used in practice to make an "educated
|
|||
|
guess" as to whether a candidate is prime.
|
|||
|
|
|||
|
Often a Monte Carlo approach is employed. In this event there
|
|||
|
is a slight possibility of an erroneous conclusion; however, the
|
|||
|
error probability can be made arbitrarily small. Typically, a
|
|||
|
sequence of "witnesses" attest to the primality or compositeness
|
|||
|
of a number. Agreement among a group of about 100 witnesses is
|
|||
|
generally sufficient to reach a conclusion beyond any reasonable
|
|||
|
doubt, although evidently the legality of this procedure has not
|
|||
|
been tested in the courts.
|
|||
|
|
|||
|
|
|||
|
L.1 The Solovay/Strassen test.
|
|||
|
|
|||
|
|
|||
|
One example of a probabilistic polynomial-time primality test
|
|||
|
is the Solovay/Strassen test [SOLO77] mentioned in section 4.1.1
|
|||
|
(although this approach is commonly attributed to Solovay and
|
|||
|
Strassen, it was noted implicitly by Lehmer [LEHM76]; cf.
|
|||
|
[LENS86]). If n is an odd positive integer and a <20> Zn*, with the
|
|||
|
latter as in Appendix G, let
|
|||
|
|
|||
|
|
|||
|
e(a,n) <20> a(n-1)/2 (mod n), -1 <20> e(a,n) <20> n - 2.
|
|||
|
|
|||
|
|
|||
|
For convenience we have e(a,n) take on the value -1 instead of
|
|||
|
the usual n - 1.
|
|||
|
|
|||
|
If p is prime we have e(a,p) <20> ep(a) (mod p) with ep as in
|
|||
|
appendix J.4. Lemma J.4.1 shows that e(a,p) = (a/p), where the
|
|||
|
latter is the Jacobi symbol (app. J.3). The latter equality thus
|
|||
|
provides evidence of primality. That is, if p is prime and a <20> Zn*
|
|||
|
then e(a,p) = (a/p). Per se this is useless, but the contrapositive
|
|||
|
provides a proof of compositeness: if (a/n) <20> e(a,n) then n is
|
|||
|
composite. Also, both (a/n) and e(a,n) can be computed in O(log n)
|
|||
|
steps, so this proof of compositeness runs in deterministic
|
|||
|
polynomial time. The converse is more subtle. Suppose n is an odd
|
|||
|
positive integer and 0 < a < n. If GCD(a,n) > 1 then n is certainly
|
|||
|
composite. Let
|
|||
|
|
|||
|
|
|||
|
G = {a <20> Zn*: (a/n) = e(a,n)}.
|
|||
|
|
|||
|
|
|||
|
Now the Jacobi symbol is multiplicative; i.e.,
|
|||
|
|
|||
|
|
|||
|
(a*b/n) = (a/n) * (b/n).
|
|||
|
|
|||
|
|
|||
|
Also
|
|||
|
|
|||
|
|
|||
|
e(a*b,n) <20> e(a,n) * e(b,n) (mod n).
|
|||
|
|
|||
|
|
|||
|
That is, e is also multiplicative. It follows that G is a
|
|||
|
subgroup of Zn*. The order of G must divide the order of Zn* (e.g.,
|
|||
|
[HERS64] p. 35). Thus if G <20> Zn*, G has cardinality at most (n-
|
|||
|
1)/2. Solovay and Strassen showed that indeed G <20> Zn* if n is
|
|||
|
composite. Hence if n is composite and a is chosen at random, the
|
|||
|
probability that a is in G is at most 1/2. We thus test as follows:
|
|||
|
|
|||
|
|
|||
|
function Solovay_Strassen(a,n) returns charstring;
|
|||
|
/* for n > 2, n odd, a <20> Zn, decides probabilistically
|
|||
|
whether n is prime */
|
|||
|
if (GCD(a,n) > 1) return("composite")
|
|||
|
else
|
|||
|
if ((a/n) = e(a,n)) return("prime")
|
|||
|
else return("composite");
|
|||
|
end Solovay_Strassen;
|
|||
|
|
|||
|
|
|||
|
We will certainly reach a correct conclusion in any of the
|
|||
|
following cases:
|
|||
|
|
|||
|
|
|||
|
a. n is prime.
|
|||
|
|
|||
|
b. n is composite and GCD(a,n) > 1.
|
|||
|
|
|||
|
c. n is composite, GCD(a,n) = 1, and (a/n) <20> e(a,n).
|
|||
|
|
|||
|
|
|||
|
In the remaining case, i.e. n is composite, GCD(a,n) = 1, and
|
|||
|
(a/n) = e(a,n), n "masquerades" as a prime due to the perjury of
|
|||
|
a. But such an a is in G above; hence the probability of false
|
|||
|
testimony from an a is at most 1/2 in this case. If 100 random a's
|
|||
|
are used as witnesses, we conclude n is prime or composite with
|
|||
|
probability of error zero if n is prime, and at most 2-100 otherwise.
|
|||
|
At most 6 * log n operations are needed (see [SOLO77]).
|
|||
|
|
|||
|
|
|||
|
L.2 Lehman's test.
|
|||
|
|
|||
|
|
|||
|
Lehman [LEHM82] noted that the Jacobi function is not needed in
|
|||
|
Monte Carlo testing for primality. He defines
|
|||
|
|
|||
|
|
|||
|
e'(a,n) = a(n-1)/2 mod n,
|
|||
|
|
|||
|
G = {e'(a,n) : a <20> Zn*}.
|
|||
|
|
|||
|
|
|||
|
We note that e' differs only slightly from e, taking on the
|
|||
|
value p - 1 instead of -1.
|
|||
|
|
|||
|
He shows that if n is odd, G = {1,p-1} iff n is prime. Again 100
|
|||
|
a's are tested, but only a(n-1)/2 mod n is computed. If anything
|
|||
|
except 1 or -1 is found, n is composite. If only 1's and -1's are
|
|||
|
found, conclude n is prime if any -1's are found; otherwise
|
|||
|
conclude n is composite. Again the probability of error is at most
|
|||
|
2-100.
|
|||
|
|
|||
|
|
|||
|
L.3 The Miller/Rabin test.
|
|||
|
|
|||
|
|
|||
|
Another Monte Carlo test was noted by Miller [MILL76] and Rabin
|
|||
|
[RABI80]. If n - 1 = u * 2k where u is odd and k > 0, let exp(i) =
|
|||
|
2i, 0 <20> i <20> k - 1. If a <20> Zn* then a is a witness to the
|
|||
|
compositeness of n if au !<21> 1 (mod n) and au*exp(i) !<21> -1 (mod n), 0
|
|||
|
<EFBFBD> i <20> k - 1. Again, e.g., 100 witnesses may be tested; if none
|
|||
|
attest to compositeness of n then n may be assumed prime.
|
|||
|
|
|||
|
When n <20> 3 (mod 4) this test is similar to Lehman's.
|
|||
|
|
|||
|
|
|||
|
Appendix M. Mathematics of RSA and other exponential systems.
|
|||
|
|
|||
|
|
|||
|
In section 1.5 the basic exponential cipher was introduced;
|
|||
|
i.e., E(M) = Mk mod p, D(C) = CI mod p, where K * I <20> 1 (mod p-1).
|
|||
|
We recall (appendix H) that I can be computed from K using Euclid's
|
|||
|
algorithm in O(log p) time. Also, by lemma G.1.1 we have <20>(p) = p-
|
|||
|
1. Thus, by corollary G.2.3 we have D(E(M)) = M and E(D(C)) = C.
|
|||
|
|
|||
|
The RSA system is analogous: we have E(M) = Me mod n, D(C) = Cd
|
|||
|
mod n, n = p * q, e * d <20> 1 (mod m), m = (p-1)(q-1). By lemma G.1.1
|
|||
|
we have <20>(n) = m, so once again corollary G.2.3 gives D(E(M)) = M
|
|||
|
and E(D(C)) = C.
|
|||
|
|
|||
|
We have noted in appendix L how the Solovay/Strassen or Lehman
|
|||
|
tests can be used to choose p and q efficiently, i.e., in O(log n)
|
|||
|
steps. However, these involve multiple-precision arithmetic
|
|||
|
[KNUT81]. Hence the total time can be significant, especially in
|
|||
|
software.
|
|||
|
|
|||
|
Once p and q have been chosen, e is chosen easily; then d is
|
|||
|
computed via e * d <20> 1 (mod m). This can be done in O(log n) steps
|
|||
|
using INVERSE from appendix H. Thus key material can be generated
|
|||
|
in linear time.
|
|||
|
|
|||
|
Encryption is easy since e can be chosen small. However,
|
|||
|
efficient decryption requires the Chinese remainder theorem. In
|
|||
|
general we have
|
|||
|
|
|||
|
|
|||
|
(y mod n) mod p = y mod p,
|
|||
|
|
|||
|
(y mod n) mod q = y mod q.
|
|||
|
|
|||
|
|
|||
|
Suppose we are given ciphertext C; we wish to efficiently
|
|||
|
compute
|
|||
|
|
|||
|
|
|||
|
M = Cd mod n.
|
|||
|
|
|||
|
|
|||
|
To use the machinery of appendix I, let y = Cd and x = M = y mod
|
|||
|
n. Then
|
|||
|
|
|||
|
|
|||
|
a = Cd mod p,
|
|||
|
|
|||
|
b = Cd mod q.
|
|||
|
|
|||
|
|
|||
|
Also, suppose d = k * (p - 1) + r. Then by the Euler/Fermat
|
|||
|
theorem,
|
|||
|
|
|||
|
|
|||
|
a = (Cp-1)k * Cr mod p = 1k * Cr mod p = (C mod p)r mod p.
|
|||
|
|
|||
|
|
|||
|
Similarly if d = j * (q - 1) + s,
|
|||
|
|
|||
|
|
|||
|
b = (C mod q)s mod q.
|
|||
|
|
|||
|
|
|||
|
Also r = d mod p-1 and s = d mod q-1. Thus by corollary I.1, an
|
|||
|
algorithm for decryption [QUIS82] is as follows:
|
|||
|
|
|||
|
|
|||
|
a. Compute
|
|||
|
|
|||
|
i. a = (C mod p)d mod (p-1) mod p,
|
|||
|
|
|||
|
ii. b = (C mod q)d mod (q-1) mod q.
|
|||
|
|
|||
|
b. Find u with 0 < u < p and
|
|||
|
|
|||
|
u * q <20> 1 (mod p).
|
|||
|
|
|||
|
c. Use one of
|
|||
|
|
|||
|
i. M = (((a - (b mod p)) * u) mod p) * q + b
|
|||
|
(a <20> b mod p),
|
|||
|
|
|||
|
ii. M = (((a + p - (b mod p)) * u) mod p) * q + b
|
|||
|
(a < b mod p).
|
|||
|
|
|||
|
|
|||
|
|
|||
|
These represent roughly optimal formulae for deciphering. Again
|
|||
|
u is found easily using INVERSE, and M is easy to compute once a
|
|||
|
and b have been found. Finding a and b requires at most 2 log p and
|
|||
|
2 log q multiplications, respectively ([KNUT81] p. 442). Thus both
|
|||
|
encryption and decryption can be done in O(log n) operations, i.e.,
|
|||
|
linear time. Nonetheless, these operations are relatively time-
|
|||
|
consuming (though elementary), since they involve multiplications
|
|||
|
and divisions of numbers of about 100 digits. For efficiency this
|
|||
|
requires hardware support.
|
|||
|
|
|||
|
|
|||
|
Appendix N. Quadratic residuosity modulo a composite.
|
|||
|
|
|||
|
|
|||
|
Deciding quadratic residuosity modulo a composite played a major
|
|||
|
role in appendices O and P. In particular, suppose N = p * q where
|
|||
|
p and q are large primes. Deciding quadratic residuosity modulo
|
|||
|
such N when p and q are unknown is regarded as computationally
|
|||
|
intractable. This forms the basis of many probabilistic encryption
|
|||
|
and zero-knowledge schemes.
|
|||
|
|
|||
|
Also, it was noted by Rabin that finding square roots modulo N
|
|||
|
in this event has essentially the same complexity as factoring N,
|
|||
|
the intractability of which forms the basis for RSA. This was
|
|||
|
exploited by Rabin (cf. sec. 4.1.4) to obtain a modification of RSA
|
|||
|
which is provably equivalent to factoring. Essentially his scheme
|
|||
|
was to encrypt via
|
|||
|
|
|||
|
|
|||
|
EN(x) = x2 mod N.
|
|||
|
|
|||
|
|
|||
|
Let ZN* be as in appendix G.
|
|||
|
|
|||
|
|
|||
|
N.1 Characterizing quadratic residues.
|
|||
|
|
|||
|
|
|||
|
The basic extension of quadratic residuosity modulo a prime to
|
|||
|
the composite modulus case is:
|
|||
|
|
|||
|
|
|||
|
LEMMA N.1.1. If N = p * q, p and q primes > 2, then:
|
|||
|
|
|||
|
|
|||
|
a. Suppose z <20> ZN*. Then z is a quadratic residue modulo
|
|||
|
N iff z mod p is a quadratic residue modulo p and z mod
|
|||
|
q is a quadratic residue modulo q.
|
|||
|
|
|||
|
b. A quadratic residue z modulo N has exactly four square
|
|||
|
roots of the form {x,N-x,y,N-y} in ZN*.
|
|||
|
|
|||
|
c. If z is a quadratic residue modulo N, and p and q are
|
|||
|
known, then the square roots of z modulo N can be found
|
|||
|
in probabilistic polynomial time.
|
|||
|
|
|||
|
|
|||
|
Proof: suppose z <20> ZN*, z mod p is a quadratic residue modulo p,
|
|||
|
and z mod q is a quadratic residue modulo q. Then for some r and
|
|||
|
t in Zp* and Zq*, respectively, we have r2 <20> z (mod p) and t2 <20> z
|
|||
|
(mod q). By the Chinese Remainder Theorem (app. I) there exists w
|
|||
|
in ZN with w <20> r (mod p) and w <20> t (mod q). Then w2 <20> z (mod p or
|
|||
|
q), so w2 <20> z (mod N). Thus z is a quadratic residue modulo N. This
|
|||
|
proves one direction of (a).
|
|||
|
|
|||
|
Now suppose z is a quadratic residue modulo N. Let zp = z mod p
|
|||
|
and zq = z mod q. Then z <20> ZN*, and hence zp <20> Zp* and zq <20> Zq*. Also,
|
|||
|
w2 <20> z (mod N) for some w in ZN*. Thus w2 <20> z (mod p or q) and hence
|
|||
|
w2 <20> zp (mod p) and w2 <20> zq (mod q). Thus zp and zq are quadratic
|
|||
|
residues modulo p and q, respectively, proving (a) in the other
|
|||
|
direction.
|
|||
|
|
|||
|
Furthermore, by lemma J.3.1, zp has exactly two square roots
|
|||
|
{x1,x2} in Zp*, and zq has exactly two square roots {y1,y2} in Zq*.
|
|||
|
Hence w <20> xi (mod p) and w <20> yj (mod q) for some i and j. There are
|
|||
|
four possible pairs (i = 1,2 and j = 1,2). The Chinese Remainder
|
|||
|
Theorem shows that w is uniquely determined in ZN by a given i and
|
|||
|
j; hence z has at most four square roots modulo N in ZN*.
|
|||
|
Conversely, by the Chinese Remainder Theorem once again, w can be
|
|||
|
found for each (i,j) pair. Thus z has exactly four square roots
|
|||
|
modulo N in ZN*. Let x denote one root. Then N - x is another. If
|
|||
|
y is a third, then N - y is the fourth. This proves (b).
|
|||
|
|
|||
|
By lemma J.3.1, {xi} and {yj} can be found in probabilistic
|
|||
|
polynomial time; the corresponding w's can then be found in
|
|||
|
polynomial time. This proves (c). QED.
|
|||
|
|
|||
|
|
|||
|
COROLLARY N.1.1. Suppose N = p * q, p and q primes > 2. Then:
|
|||
|
|
|||
|
|
|||
|
a. EN is a four-to-one function.
|
|||
|
|
|||
|
b. If p and q are known and z is a quadratic residue modulo
|
|||
|
N, the four values of x for which EN(x) = z can be found
|
|||
|
in probabilistic polynomial time.
|
|||
|
|
|||
|
|
|||
|
Proof: immediate from the previous lemma. QED.
|
|||
|
|
|||
|
|
|||
|
N.2 The Jacobi symbol once more.
|
|||
|
|
|||
|
|
|||
|
Suppose N = p * q where p and q are primes > 2. Then for x in
|
|||
|
ZN*, the Jacobi symbol (x/N) is given by
|
|||
|
|
|||
|
|
|||
|
(x/N) = (x/p)(x/q).
|
|||
|
|
|||
|
|
|||
|
If the Jacobi symbol (x/N) = -1, then (x/p) or (x/q) = -1. Hence
|
|||
|
x mod p and x mod q are quadratic nonresidues modulo p and q,
|
|||
|
respectively. By lemma N.1.1, x is a quadratic nonresidue modulo
|
|||
|
N. Since (x/N) can be evaluated in O(log N) time, (x/N) = -1 is a
|
|||
|
deterministic polynomial-time test for quadratic nonresiduosity of
|
|||
|
x modulo N, N = p * q. The interesting case is (x/N) = 1, whence
|
|||
|
no conclusion can be drawn regarding quadratic residuosity of x
|
|||
|
modulo N. To study this further, ZN* may be partitioned into four
|
|||
|
subclasses, according to the Jacobi symbols (x/p) and (x/q):
|
|||
|
|
|||
|
|
|||
|
(x/p) (x/q) class (x/N)
|
|||
|
|
|||
|
1 1 Q00(N) 1
|
|||
|
|
|||
|
-1 -1 Q11(N) 1
|
|||
|
|
|||
|
1 -1 Q01(N) -1
|
|||
|
|
|||
|
-1 1 Q10(N) -1
|
|||
|
|
|||
|
|
|||
|
LEMMA N.2.1. Suppose N = p*q, p and q primes > 2. Then:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
a. The {Qij(N)} partition ZN* into disjoint classes.
|
|||
|
|
|||
|
b. Q00(N) is the set of quadratic residues modulo N; the
|
|||
|
other Q's contain nonresidues.
|
|||
|
|
|||
|
c. For i = 0 or 1 and j = 0 or 1, |Qij(N)| = (p-1)(q-1)/4.
|
|||
|
|
|||
|
|
|||
|
Proof: (a) is trivial, and (b) is immediate from lemma N.1.1.
|
|||
|
For (c), let g and h be generators for Zp* and Zq*, respectively. For
|
|||
|
w <20> ZN*, suppose w <20> gr (mod p) and w <20> hs (mod q), where 0 <20> r < p -
|
|||
|
1 and 0 <20> s < q - 1. Then r and s are unique. Conversely, any such
|
|||
|
pair (r,s) uniquely determines w, by the Chinese Remainder Theorem.
|
|||
|
Let f(w) = (r,s). Then f is a bijection from ZN* to Zp x Zq. Also,
|
|||
|
if f(w) = (r,s) then
|
|||
|
|
|||
|
|
|||
|
(w/p) = (gr/p) = (g/p)r,
|
|||
|
|
|||
|
(w/q) = (hs/q) = (h/q)s.
|
|||
|
|
|||
|
|
|||
|
By lemma K.4, g and h are quadratic nonresidues modulo p and q,
|
|||
|
respectively. Thus (w/p) = (-1)r and (w/q) = (-1)s. Let i = r mod
|
|||
|
2 and j = s mod 2. Then (w/p) = (-1)i and (w/q) = (-1)j. Hence w is
|
|||
|
in Qij(N). For k = 0,1 let Zpk and Zqk be the subsets of Zp* and Zq*,
|
|||
|
respectively, which contain elements = k (mod 2). Then for i = 0,1
|
|||
|
and j = 0,1, f is a bijection from Qij(N) to Zpi x Zqj. The latter
|
|||
|
has cardinality (p-1)(q-1)/2; this gives (c). QED.
|
|||
|
|
|||
|
Thus exactly half of the elements of ZN* have (x/N) = -1; these
|
|||
|
are nonresidues modulo N. The other half have (x/N) = 1. Of the
|
|||
|
latter, half (i.e., Q00(N)) are quadratic residues and half (i.e.,
|
|||
|
Q11(N)) are nonresidues. The quadratic residuosity conjecture is
|
|||
|
that determining which of the elements of ZN* with (x/N) = 1 are
|
|||
|
quadratic residues modulo N is not solvable in probabilistic
|
|||
|
polynomial time, for N a product of two primes. This is in
|
|||
|
contradistinction to the case of one prime p, for which we have
|
|||
|
noted that quadratic residuosity is decidable in deterministic
|
|||
|
polynomial time.
|
|||
|
|
|||
|
|
|||
|
LEMMA N.2.2. Suppose N = p * q, p and q primes > 2. Then:
|
|||
|
|
|||
|
|
|||
|
a. For x,y <20> ZN*, x * y is a quadratic residue modulo N if and
|
|||
|
only if x and y are in the same Qij(N).
|
|||
|
|
|||
|
b. The product of quadratic residues is a quadratic residue.
|
|||
|
|
|||
|
c. The product of a quadratic residue and a nonresidue is a
|
|||
|
nonresidue.
|
|||
|
|
|||
|
|
|||
|
Proof: suppose x <20> Qij(N) and y <20> Qrt(N). Then (x/p) =
|
|||
|
(-1)i, (x/q) = (-1)j, (y/p) = (-1)r, (y/q) = (-1)t. Hence (x*y/p) =
|
|||
|
(-1)i+r and (x*y/q) = (-1)j+t. Now x * y mod N will be a residue if
|
|||
|
and only if i = r and j = t. This gives (a). In particular, x * y
|
|||
|
mod N is a residue if both are in Q00(N), yielding (b). If x is a
|
|||
|
residue and y a nonresidue, x is in Q00(N) but y is not; (c)
|
|||
|
follows. QED.
|
|||
|
|
|||
|
|
|||
|
Thus the quadratic residues modulo N form a subgroup of ZN*.
|
|||
|
|
|||
|
|
|||
|
N.3 Quadratic residuosity and factoring.
|
|||
|
|
|||
|
|
|||
|
We note the connection between quadratic residuosity and
|
|||
|
factoring observed by Rabin [RABI79].
|
|||
|
|
|||
|
|
|||
|
LEMMA N.3.1. Suppose N = p * q, p and q prime, x and y are in
|
|||
|
ZN*, x2 <20> y2 (mod N), and y !<21> x or -x (mod N). Then possession of
|
|||
|
x and y permits factoring N in deterministic polynomial time.
|
|||
|
|
|||
|
|
|||
|
Proof: we have x - y !<21> 0 (mod N) and x + y !<21> 0 (mod N), so
|
|||
|
GCD(N,y+x) < N and GCD(N,y-x) < N. Now x2 - y2 <20> (x-y)(x+y) <20> 0 (mod
|
|||
|
N). Hence (x-y)(x+y) <20> 0 (mod p). Thus p | y-x or p | y+x; also p
|
|||
|
| N. If p | y-x, p | GCD(N,y-x) < N, so p = GCD(N,y-x). The latter
|
|||
|
can be found via Euclid's algorithm (app. H). If p | y+x, p |
|
|||
|
GCD(N,y+x) < N, so p = GCD(N,y+x). QED.
|
|||
|
|
|||
|
|
|||
|
LEMMA N.3.2. Suppose N = p * q, p and q prime. Suppose there
|
|||
|
exists an algorithm to find in probabilistic polynomial time a
|
|||
|
square root of a quadratic residue modulo N, which works for at
|
|||
|
least a fraction 1/logc N of quadratic residues, c a constant
|
|||
|
positive integer. Then N can be factored in probabilistic
|
|||
|
polynomial time.
|
|||
|
|
|||
|
|
|||
|
Proof: let m = logc N. Choose x1,...,xm randomly in ZN* and
|
|||
|
compute zi = xi2 mod N, i = 1,...,m. If any zi has a square root w
|
|||
|
computable in probabilistic polynomial time via the hypothetical
|
|||
|
algorithm, find w. The probability that w !<21> xi or -xi (mod N) is
|
|||
|
1/2. In this event possession of xi and w factors N by lemma N.3.1.
|
|||
|
The probability that some zi has a computable square root is at
|
|||
|
least 1/2. Thus the probability of factoring N is at least 1/4. If
|
|||
|
this procedure is repeated m times, the probability of success is
|
|||
|
at least 1 - (3/4)m. Also, the problem size is log N, so m is a
|
|||
|
polynomial in the problem size. QED.
|
|||
|
|
|||
|
|
|||
|
COROLLARY N.3.2. If N = p * q, p and q prime, and the
|
|||
|
factorization of N is computationally intractable, then the Blum
|
|||
|
encryption function EN above is a trapdoor one-way function, with
|
|||
|
(p,q) forming the trapdoor.
|
|||
|
|
|||
|
|
|||
|
Proof: by the previous theorem, an algorithm to invert EN would
|
|||
|
yield an algorithm to factor N. QED.
|
|||
|
|
|||
|
|
|||
|
N.4 Quadratic residuosity and Blum integers.
|
|||
|
|
|||
|
|
|||
|
Suppose N = p * q where p <20> 3 (mod 4) and q <20> 3 (mod 4). Then
|
|||
|
N is called a Blum integer (normally p and q are specified to have
|
|||
|
roughly the same size). For example, N = 77 is used in appendix O.
|
|||
|
|
|||
|
|
|||
|
LEMMA N.4.1. If p,q <20> 3 (mod 4) then (-1/p) = (-1/q) = -1.
|
|||
|
|
|||
|
|
|||
|
Proof: in lemma J.4.1 take a = -1. We recall that (-1/p) = 1 if
|
|||
|
and only if -1 is a quadratic residue modulo p. Thus (-1/p) = (-
|
|||
|
1)(p-1)/2 (mod p) and similarly (-1/q) = (-1)(q-1)/2 (mod q). The result
|
|||
|
follows. QED.
|
|||
|
|
|||
|
|
|||
|
LEMMA N.4.2. If N = p * q is a Blum integer then (-x/p) = -
|
|||
|
(x/p), (-x/q) = -(x/q), (-1/N) = 1, and (-x/N) = (x/N).
|
|||
|
|
|||
|
|
|||
|
Proof: the first two are immediate from the previous lemma; also
|
|||
|
(-1/N) = (-1/p)(-1/q). QED.
|
|||
|
|
|||
|
|
|||
|
LEMMA N.4.3. Suppose N = p * q is a Blum integer, x and y are
|
|||
|
in ZN*, x2 <20> y2 (mod N), and x !<21> y or -y (mod N). Then (x/N) = -
|
|||
|
(y/N).
|
|||
|
|
|||
|
|
|||
|
Proof: x2 <20> y2 (mod p), so (y-x)(y+x) <20> 0 (mod p), so y <20> d * x
|
|||
|
(mod p) where d = 1 or -1. Similarly y <20> e * x (mod q) where e =
|
|||
|
1 or -1. Now (x/N) = (x/p)(x/q) and (y/N) = (y/p)(y/q) =
|
|||
|
(d*x/p)(e*x/q) = (d/p)(e/q)(x/N). Since (1/p) = (1/q) = 1, by lemma
|
|||
|
N.4.1, (y/N) = e * d * (x/N). If e = d then y <20> d * x (mod q or p),
|
|||
|
so y <20> d * x (mod N). But y !<21> x or -x (mod N), contradiction. Thus
|
|||
|
e <20> d and e * d = -1. QED.
|
|||
|
|
|||
|
|
|||
|
LEMMA N.4.4. If N = p * q is a Blum integer and z is a quadratic
|
|||
|
residue modulo N, then z has a square root in each Qij(N), i = 0,1,
|
|||
|
j = 0,1.
|
|||
|
|
|||
|
|
|||
|
Proof: let {x,N-x,y,N-y} be the square roots of z in ZN*. Since
|
|||
|
N-x <20> -x (mod p), by lemma N.4.2, (N-x/p) = -(x/p). Similarly (N-
|
|||
|
x/q) = -(x/q), so if x <20> Qij(N), N-x <20> Q1-i,1-j(N); similarly for y and
|
|||
|
N-y. Now x2 <20> y2 (mod N) and y !<21> x or -x (mod N). Since by lemma
|
|||
|
N.4.3, (y/N) = -(x/N), y cannot be in the same Q as x. By lemma
|
|||
|
N.4.2, ((N-y)/N) = (y/N), so N-y cannot be in the same Q as x. Thus
|
|||
|
y and N-y must be in Qi,1-j(N) and Q1-i,j(N) in some order. QED.
|
|||
|
|
|||
|
For Blum integers we can restrict the function EN to Q00(N);
|
|||
|
i.e., let BN : Q00(N) -> Q00(N) by BN(x) = x2 mod N. Then we have
|
|||
|
|
|||
|
LEMMA N.4.5. If N = p * q is a Blum integer then:
|
|||
|
|
|||
|
|
|||
|
a. BN is a permutation on Q00(N), i.e., on the set of
|
|||
|
quadratic residues modulo N.
|
|||
|
|
|||
|
b. If the factorization of N is computationally intractable
|
|||
|
then BN is a trapdoor one-way permutation, with (p,q)
|
|||
|
constituting the trapdoor.
|
|||
|
|
|||
|
|
|||
|
Proof: by corollary N.1.1 we know that if p and q are known and
|
|||
|
y is in Q00(N), the equation EN(x) = y has exactly four solutions
|
|||
|
which can be found in probabilistic polynomial time. By lemma
|
|||
|
N.4.4, exactly one of these, x00, lies in Q00(N); x00 is easily
|
|||
|
extracted from the set of four since only it satisfies (x/p) =
|
|||
|
(x/q) = 1. Hence x00 is the unique solution of BN(x) = y. Thus BN is
|
|||
|
a permutation on Q00(N) whose inverse may be computed in
|
|||
|
probabilistic polynomial time with knowledge of the trapdoor (p,q).
|
|||
|
On the other hand, lemma N.3.2 shows that an algorithm to invert
|
|||
|
BN can be converted to an algorithm to factor N. QED.
|
|||
|
|
|||
|
|
|||
|
LEMMA N.4.6. If N = p * q, p and q prime, then it is possible
|
|||
|
to find x in Q11(N), i.e., x <20> ZN* such that x is a quadratic
|
|||
|
nonresidue modulo N and (x/N) = 1, in probabilistic polynomial
|
|||
|
time.
|
|||
|
|
|||
|
|
|||
|
Proof: choose a in Zp* and evaluate a(p-1)/2; if the latter is not
|
|||
|
1 then choose a new a, etc. The probability of failure each time
|
|||
|
is 1/2, so that the probability of not finding an a with a(p-1)/2 =
|
|||
|
1 (mod p) in n tries is 2-n. Hence a can be found in probabilistic
|
|||
|
polynomial time (in n = length of p). Now (a/p) = 1. Similarly,
|
|||
|
find b with (b/q) = 1, also in probabilistic polynomial time. Use
|
|||
|
the Chinese Remainder Theorem to find y in ZN* with y <20> a (mod p)
|
|||
|
and y <20> b (mod q), in polynomial time (in length of N). QED.
|
|||
|
|
|||
|
|
|||
|
Appendix O. An introduction to zero-knowledge.
|
|||
|
|
|||
|
|
|||
|
The notion of zero-knowledge proofs was introduced in [GOLD89].
|
|||
|
The essence of zero-knowledge is that one party can prove something
|
|||
|
to another without revealing any additional information. In
|
|||
|
deference to the depth and scope of this area, we give only an
|
|||
|
illustrative example in this section. However, there is a close
|
|||
|
connection between zero-knowledge schemes and probabilistic public-
|
|||
|
key encryption. Furthermore, some zero-knowledge schemes which have
|
|||
|
drawn attention because of applicability to smart card
|
|||
|
implementations, such as the one used as the basis of the example
|
|||
|
in this section, use Shamir's notion of identity-based public-key
|
|||
|
systems. Thus the reader desiring a more formal introduction to
|
|||
|
these topics may wish to skip to appendix P.
|
|||
|
|
|||
|
Suppose that Alice knows a fact P. She wants to convince Bob
|
|||
|
that she knows P, but she does not trust Bob. Thus, Alice does not
|
|||
|
want to reveal any more knowledge to Bob than is necessary. What
|
|||
|
Alice needs is a zero-knowledge proof of P.
|
|||
|
|
|||
|
For example, suppose that Alice wants to prove to Bob that she
|
|||
|
really is Alice. Suppose for convenience that there is some
|
|||
|
authority which verifies identities. One possibility is that the
|
|||
|
authority could issue Alice an identification. If this were
|
|||
|
contained on a device such as a smart card, Alice could simply show
|
|||
|
it to Bob. However, if Alice and Bob are communicating over a
|
|||
|
network, then Alice's identifying information would have to be
|
|||
|
transmitted to Bob over the network. Upon receiving it, Bob could
|
|||
|
use it to impersonate Alice. Even if Bob were trusted, an
|
|||
|
eavesdropper such as Alice's adversary Carol could do the same.
|
|||
|
|
|||
|
This situation also arises commonly in computer access control:
|
|||
|
Bob might then be a host computer or network server, and Alice's
|
|||
|
identification might be a password. If Alice uses her password to
|
|||
|
identify herself, her password is exposed to the host software as
|
|||
|
well as eavesdroppers; anyone who knows this password can
|
|||
|
impersonate Alice.
|
|||
|
|
|||
|
It is thus desirable for Alice to be able to prove her identity
|
|||
|
without revealing any private information. More generally, we need
|
|||
|
a scheme through which Alice can prove to Bob that she possesses
|
|||
|
something (e.g., a password) without having to reveal it. Such a
|
|||
|
scheme is an example of a zero-knowledge proof. In fact, this
|
|||
|
example is the major practical usage of zero-knowledge which has
|
|||
|
been suggested to date.
|
|||
|
|
|||
|
Here is one way that such a system could be organized: the
|
|||
|
authority decides on a number N used for everyone; e.g., take N =
|
|||
|
77. Everyone knows this number. The authority may then choose,
|
|||
|
e.g., two numbers which form an ID for Alice. Suppose these are
|
|||
|
{58,67}. Everyone knows Alice's ID. The authority then computes two
|
|||
|
other numbers {9,10} which are given to Alice alone; she keeps
|
|||
|
these private. The latter numbers were chosen because 92 * 58 <20> 1
|
|||
|
(mod 77) and 102 * 67 <20> 1 (mod 77).
|
|||
|
|
|||
|
Now Alice can identify herself to Bob by proving that she
|
|||
|
possesses the secret numbers {9,10} without revealing them. Each
|
|||
|
time she wishes to do this she can proceed as follows: she can
|
|||
|
choose some random numbers such as {19,24,51} and compute
|
|||
|
|
|||
|
|
|||
|
192 <20> 53 (mod 77),
|
|||
|
|
|||
|
242 <20> 37 (mod 77),
|
|||
|
|
|||
|
512 <20> 60 (mod 77).
|
|||
|
|
|||
|
|
|||
|
Alice then sends {53,37,60} to Bob. Bob chooses a random 3 by
|
|||
|
2 matrix of 0's and 1's, e.g.,
|
|||
|
|
|||
|
|
|||
|
0 1
|
|||
|
E = 1 0 .
|
|||
|
1 1
|
|||
|
|
|||
|
|
|||
|
Bob sends E to Alice. On receipt, Alice computes
|
|||
|
|
|||
|
|
|||
|
19 * 90 * 101 <20> 36 (mod 77),
|
|||
|
|
|||
|
24 * 91 * 100 <20> 62 (mod 77),
|
|||
|
|
|||
|
51 * 91 * 101 <20> 47 (mod 77).
|
|||
|
|
|||
|
|
|||
|
Alice sends {36,62,47} to Bob. Finally, Bob can check to see
|
|||
|
that Alice is who she says she is. He does this by checking that
|
|||
|
|
|||
|
|
|||
|
362 * 580 * 671 <20> 53 (mod 77),
|
|||
|
|
|||
|
622 * 581 * 670 <20> 37 (mod 77),
|
|||
|
|
|||
|
472 * 581 * 671 <20> 60 (mod 77).
|
|||
|
|
|||
|
|
|||
|
The original numbers {53,37,60} that Alice sent reappear.
|
|||
|
Actually, this doesn't really prove Alice's identity; she could
|
|||
|
have been an impersonator. But the chances of an impersonator
|
|||
|
succeeding would have only been 1 in 64.
|
|||
|
|
|||
|
In an actual system, the number N would have been much larger
|
|||
|
(e.g., 160 digits). Also, Alice would have been assigned an ID
|
|||
|
consisting of more numbers, e.g., 4, by the authority, with a
|
|||
|
secret also consisting of 4 numbers. Furthermore, Alice would have
|
|||
|
generated more random numbers, e.g., 5, to send to Bob. The ID
|
|||
|
numbers, secret numbers, and random numbers would have been about
|
|||
|
as large as N. This would have reduced an impersonator's chances
|
|||
|
of cheating successfully to about 1 in a million (more precisely
|
|||
|
2-20) if 4 and 5 are the parameters, which certainly would have
|
|||
|
convinced Bob of Alice's identity.
|
|||
|
|
|||
|
Why does this work? Because the authority chose {58,67} and
|
|||
|
{9,10} so that
|
|||
|
|
|||
|
|
|||
|
92 * 58 <20> 1 (mod 77),
|
|||
|
|
|||
|
102 * 67 <20> 1 (mod 77).
|
|||
|
|
|||
|
|
|||
|
This says that 92 and 58 are multiplicative inverses modulo 77,
|
|||
|
as are 102 and 67.
|
|||
|
|
|||
|
Thus
|
|||
|
|
|||
|
|
|||
|
362 * 580 * 671 <20> 192 * 92*0 * 580 * 102*1 * 671
|
|||
|
|
|||
|
<20> 192 * (92 * 58)0 * (102 * 67)1
|
|||
|
|
|||
|
<20> 192 <20> 36 (mod 77),
|
|||
|
|
|||
|
622 * 581 * 670 <20> 242 * 92*1 * 581 * 102*0 * 670
|
|||
|
|
|||
|
<20> 242 * (92 * 58)1 * (102 * 67)0
|
|||
|
|
|||
|
<20> 242 <20> 37 (mod 77),
|
|||
|
|
|||
|
472 * 581 * 671 <20> 512 * 92*1 * 581 * 102*1 * 671
|
|||
|
|
|||
|
<20> 512 * (92 * 58)1 * (102 * 67)1
|
|||
|
|
|||
|
<20> 472 <20> 53 (mod 77).
|
|||
|
|
|||
|
|
|||
|
Thus the checks that Bob uses serve their purpose properly;
|
|||
|
i.e., Alice is identified. Also, Bob has learned nothing that would
|
|||
|
permit him to masquerade as Alice; nor has Carol, who may have been
|
|||
|
eavesdropping. Either would need to know that 92 and 102 are the
|
|||
|
multiplicative inverses of 58 and 67, respectively, modulo 77. To
|
|||
|
see this, suppose Carol tries to convince Bob that she is really
|
|||
|
Alice; i.e., Carol pretends that {58,67} is her own ID. For
|
|||
|
simplicity, suppose Carol tries to identify herself as Alice by
|
|||
|
generating the same random {19,24,51}. Then she sends {53,37,60}
|
|||
|
to Bob. Again for simplicity suppose Bob generates the same E and
|
|||
|
sends it to Carol. Now Carol is in trouble; she doesn't know the
|
|||
|
numbers 9 and 10, and can only guess them. The protocol requires
|
|||
|
Carol to send three numbers, say {x,y,z}, to Bob. Then Bob will
|
|||
|
check:
|
|||
|
|
|||
|
|
|||
|
x2 * 580 * 671 <20> 53 (mod 77),
|
|||
|
|
|||
|
y2 * 581 * 670 <20> 37 (mod 77),
|
|||
|
|
|||
|
z2 * 581 * 671 <20> 60 (mod 77).
|
|||
|
|
|||
|
|
|||
|
Carol will have succeeded in her masquerade if she chose {x,y,z}
|
|||
|
to make these checks come out right. But 67-1 <20> 102 <20> 23 (mod 77)
|
|||
|
and 58-1 <20> 92 <20> 4 (mod 77), so x2 <20> 53 * 23 <20> 64 (mod 77), y2 <20> 37
|
|||
|
* 4 <20> 71 (mod 77) and z2 <20> 60 * 23 * 4 <20> 53 (mod 77). Could Carol
|
|||
|
solve these quadratic equations to find, e.g., x = 36, y = 62, z
|
|||
|
= 47? For a small value of N such as N = 77, she could indeed.
|
|||
|
However, if N is a product of two appropriately-chosen large primes
|
|||
|
(e.g., each 80 digits or more), and if these primes are kept secret
|
|||
|
by the authority, then the answer is no. That is, computing square
|
|||
|
roots modulo a composite is computationally infeasible (app. N).
|
|||
|
Thus, anyone who does not know Alice's secret ({9,10} in the above)
|
|||
|
cannot impersonate her when N is large.
|
|||
|
|
|||
|
Another possibility is that Alice's interaction with Bob might
|
|||
|
give Bob information which could allow impersonation of Alice, at
|
|||
|
least on one occasion, by replay. Suppose Bob tries to convince
|
|||
|
Carol that he is really Alice. Bob might try to imitate Alice by
|
|||
|
sending (53,37,60} to Carol to start the protocol. Now Carol
|
|||
|
doesn't necessarily select the E above. Suppose she selects
|
|||
|
|
|||
|
|
|||
|
1 1
|
|||
|
F = 0 0 .
|
|||
|
0 1
|
|||
|
|
|||
|
|
|||
|
and sends F to Bob. Now Bob is in trouble; he might try to imitate
|
|||
|
Alice again by sending {36,62,47} to Carol. Then Carol will check
|
|||
|
|
|||
|
|
|||
|
362 * 581 * 671 <20> 71 (mod 77).
|
|||
|
|
|||
|
|
|||
|
Since 71 <20> 53 (mod 77), Carol knows Bob is a fraud even without
|
|||
|
the other two checks. Can Bob send some {r,s,t} instead of
|
|||
|
{36,62,47} ? This will only work if
|
|||
|
|
|||
|
|
|||
|
|
|||
|
r2 * 581 * 671 <20> 53 (mod 77),
|
|||
|
|
|||
|
s2 * 580 * 670 <20> 37 (mod 77),
|
|||
|
|
|||
|
t2 * 580 * 671 <20> 60 (mod 77).
|
|||
|
|
|||
|
|
|||
|
As before, this gives r2 <20> 58-1 * 67-1 * 53 <20> 25 (mod 77), and
|
|||
|
similarly s2 <20> 37 (mod 77), t2 <20> 71 (mod 77). As above, Bob can
|
|||
|
solve these quadratic equations to find r,s,t because N = 77 is
|
|||
|
small, but could not do so if N were large. Also, in the above
|
|||
|
there is one chance in 64 that Carol would choose F = E, in which
|
|||
|
case Bob's deception would go unmasked; but for larger parameters
|
|||
|
such as 4 and 5 instead of 2 and 3, this would again be improbable
|
|||
|
(one chance in a million (2-20) instead of 64).
|
|||
|
|
|||
|
Another possibility is that when Alice identified himself to
|
|||
|
Bob, she may have inadvertently revealed some information which
|
|||
|
could enable Bob to learn his secret, i.e., {9,10}, which would
|
|||
|
permit impersonation. For this protocol to be zero-knowledge this
|
|||
|
should not be possible. Can Bob deduce the numbers {9,10} from the
|
|||
|
two sets of numbers {53,37,60} and {36,62,47}, and E? He knows that
|
|||
|
Alice started with three numbers {a,b,c}, but he doesn't know these
|
|||
|
were {19,24,51}. He knows that Alice's secret is {u,v} but doesn't
|
|||
|
know these are {9,10}. He knows that the authority computed u and
|
|||
|
v from
|
|||
|
|
|||
|
|
|||
|
u2 <20> 58-1 <20> 4 (mod 77),
|
|||
|
|
|||
|
v2 <20> 67-1 <20> 23 (mod 77).
|
|||
|
|
|||
|
|
|||
|
He also knows that Alice computed
|
|||
|
|
|||
|
|
|||
|
a2 <20> 53 (mod 77),
|
|||
|
|
|||
|
b2 <20> 37 (mod 77),
|
|||
|
|
|||
|
c2 <20> 60 (mod 77),
|
|||
|
|
|||
|
a * u0 * v1 <20> 36 (mod 77),
|
|||
|
|
|||
|
b * u1 * v0 <20> 62 (mod 77),
|
|||
|
|
|||
|
c * u1 * v1 <20> 47 (mod 77).
|
|||
|
|
|||
|
|
|||
|
This gives Bob 8 equations from which to deduce {u,v}. However,
|
|||
|
the last 3 are redundant, and as we have noted, the first 5 cannot
|
|||
|
be solved when N is large.
|
|||
|
|
|||
|
This shows informally that the above protocol works:
|
|||
|
|
|||
|
|
|||
|
a. It identifies Alice by proving that she possesses the
|
|||
|
secret {9,10}.
|
|||
|
|
|||
|
b. It identifies Alice uniquely: anyone who doesn't know
|
|||
|
this secret cannot impersonate Alice.
|
|||
|
|
|||
|
c. Alice's secret is not revealed in the process of
|
|||
|
proving she possesses it.
|
|||
|
|
|||
|
|
|||
|
Actually, (a) means that the possessor of {9,10} is identified
|
|||
|
as the system user who has ID = {58,67} assigned by the authority.
|
|||
|
Also, no matter how many times Alice proves her identity, her
|
|||
|
secret will not be revealed (if N is sufficiently large); i.e., (c)
|
|||
|
states loosely that the protocol is zero-knowledge. All of this
|
|||
|
depends on the assumption that equations of the form x2 <20> y (mod N)
|
|||
|
cannot be solved if N is the product of two large primes which are
|
|||
|
not known, but can be solved easily if the primes are known (app.
|
|||
|
N). Such equations lie at the heart of most concrete zero-knowledge
|
|||
|
schemes.
|
|||
|
|
|||
|
The formal definition of zero-knowledge is more complicated (see
|
|||
|
[GOLD89]), but the above example demonstrates its essence in a
|
|||
|
context which has been proposed as a candidate for actual
|
|||
|
implementation in smart-card based identification schemes.
|
|||
|
|
|||
|
|
|||
|
Appendix P. Alternatives to the Diffie/Hellman model.
|
|||
|
|
|||
|
|
|||
|
The text of this treatise has been based on the work of Diffie
|
|||
|
and Hellman [DIFF76b]. This model of public-key cryptography
|
|||
|
includes two characteristics which have received some criticism:
|
|||
|
|
|||
|
|
|||
|
a. Security of Diffie/Hellman type systems is generally
|
|||
|
established empirically, i.e., by failure of
|
|||
|
cryptanalysis.
|
|||
|
|
|||
|
b. Security of Diffie/Hellman type systems is dependent upon
|
|||
|
a superstructure which binds user IDs and public
|
|||
|
components.
|
|||
|
|
|||
|
|
|||
|
In appendix A we noted that it has proven to be difficult to
|
|||
|
develop a comprehensive axiomatic framework in which to establish
|
|||
|
the security of Diffie/Hellman type public-key systems in some
|
|||
|
provable sense. For example, it is difficult to guarantee that
|
|||
|
partial information about plaintext (e.g., its least significant
|
|||
|
bit) cannot be recovered from the corresponding ciphertext even
|
|||
|
when the entire plaintext cannot be found.
|
|||
|
|
|||
|
In section 5 we noted some examples of authentication frameworks
|
|||
|
(e.g., use of certificates) which bind user IDs and public keys.
|
|||
|
Without such a superstructure a public-key system is useless, since
|
|||
|
a user would not be certain that he was employing the correct
|
|||
|
public key for encryption or decryption. The security of the
|
|||
|
public-key system thus depends on proper functioning of the
|
|||
|
authentication framework, which is a priori unrelated to the
|
|||
|
underlying cryptosystem.
|
|||
|
|
|||
|
In this section we briefly examine two modifications of the
|
|||
|
basic Diffie/Hellman model. In one case the goal is to incorporate
|
|||
|
the binding between a user ID and public key directly into the
|
|||
|
cryptosystem, thereby eliminating the separation between the
|
|||
|
cryptosystem and the authentication framework. The other scheme
|
|||
|
addresses the subject of knowledge concealment; it is closely
|
|||
|
related to zero-knowledge proofs. Both schemes have received
|
|||
|
considerable attention not only because of possibly enhanced
|
|||
|
security, but also because of their potential relevance to smart-
|
|||
|
card implementations of public-key cryptography.
|
|||
|
|
|||
|
|
|||
|
P.1 Probabilistic encryption.
|
|||
|
|
|||
|
|
|||
|
Goldwasser and Micali [GOLD84] note that the public-key systems
|
|||
|
of Diffie and Hellman are not provably secure. They observe that
|
|||
|
use of a trapdoor function f to generate such systems does not
|
|||
|
exclude the possibility that f(x) = y may be solvable for x without
|
|||
|
the (original) trapdoor under certain conditions. Also, even if x
|
|||
|
cannot be found from f(x), it may be possible to extract partial
|
|||
|
information about x. One problem is that such trapdoor systems
|
|||
|
proceed block by block. This makes it difficult to prove security
|
|||
|
with respect to concealment of partial information such as least
|
|||
|
significant bit.
|
|||
|
|
|||
|
In [GOLD84] Goldwasser and Micali suggest an alternative to
|
|||
|
trapdoor-based public-key systems. Their procedure is to encrypt
|
|||
|
bit by bit. They call this probabilistic encryption. It introduces
|
|||
|
several advantages, namely uniformly difficult decoding and hiding
|
|||
|
of partial information. Their scheme has the following properties:
|
|||
|
|
|||
|
|
|||
|
a. Decoding is equivalent to deciding quadratic residuosity
|
|||
|
modulo a composite N, whose factorization is not known to
|
|||
|
an adversary.
|
|||
|
|
|||
|
b. Suppose a predicate P has probability p of being true in
|
|||
|
message space M. For c > 0, assuming intractability of
|
|||
|
quadratic residuosity, an adversary given ciphertext
|
|||
|
cannot decide with probability > p + c whether the
|
|||
|
corresponding plaintext satisfies P; i.e., the
|
|||
|
adversary does not have a c-advantage in guessing P.
|
|||
|
|
|||
|
|
|||
|
In (a) the reference is to the problem of deciding for a given
|
|||
|
x whether there is a y such that y2 <20> x (mod N). As in the case of
|
|||
|
computing discrete logarithms or extracting roots, this is
|
|||
|
computationally infeasible if the factorization of N is unknown
|
|||
|
(app. N).
|
|||
|
|
|||
|
An example of (b): if the messages consist of uniformly
|
|||
|
distributed bit strings and P is "least significant bit = 0," then
|
|||
|
p = 1/2. If the Goldwasser/Micali scheme is employed, an adversary
|
|||
|
cannot guess the least significant bit of plaintext with
|
|||
|
probability greater than 1/2 + c. It may be very difficult to
|
|||
|
verify that traditional public-key systems conceal such partial
|
|||
|
information.
|
|||
|
|
|||
|
The public-key system proposed by Goldwasser and Micali is as
|
|||
|
follows: a user A chooses primes p and q and makes public N = p*q;
|
|||
|
p and q are private. Also, A selects a random y with (y/N) = 1
|
|||
|
(app. N.2) with y a quadratic nonresidue modulo N; y is public. By
|
|||
|
lemma N.4.6, y can be found in probabilistic polynomial time.
|
|||
|
|
|||
|
To send the binary string m = (m1,...,mk) to A, B randomly
|
|||
|
selects {x1,...,xk} in ZN* and computes
|
|||
|
|
|||
|
|
|||
|
zi = xi2 mod N (i = 1,...,k).
|
|||
|
|
|||
|
|
|||
|
Then B sets ei = zi if mi = 0, ei = y * zi otherwise. The encoding
|
|||
|
of m is e = (e1,...,ek), which B sends to A. To decode e, A sets mi
|
|||
|
= 1 if ei is a quadratic residue modulo N, and mi = 0 otherwise.
|
|||
|
This can be effected by A in polynomial time since A knows p and
|
|||
|
q (lemmas J.4.1, N.1.1). It is correct because y * zi, the product
|
|||
|
of a quadratic nonresidue and residue, is a quadratic nonresidue
|
|||
|
modulo N (lemma N.2.2).
|
|||
|
|
|||
|
The security of partial information follows from the fact that
|
|||
|
each bit of the message m is encoded independently. A disadvantage
|
|||
|
of the technique is data expansion: if |N| = n, then n bits are
|
|||
|
transmitted for each bit of a message.
|
|||
|
|
|||
|
One application is coin flipping by telephone: A randomly
|
|||
|
chooses r in ZN* with (r/N) = 1, where (r/N) is the Jacobi symbol
|
|||
|
(app. N.2). Then B guesses whether or not r is a quadratic residue
|
|||
|
modulo N; B wins if and only if he guesses correctly. The
|
|||
|
probability of the latter is 1/2; i.e., exactly half of the
|
|||
|
elements of ZN* satisfying (r/N) = 1 are quadratic residues modulo
|
|||
|
N (lemma N.2.1). The correctness of B's guess can be checked by A;
|
|||
|
the result can be verified by B if A releases the factorization of
|
|||
|
N to B.
|
|||
|
|
|||
|
A second application is to mental poker (e.g., [DENN83b] pp.
|
|||
|
110-117). Goldwasser and Micali show that their implementation
|
|||
|
corrects some deficiencies in hiding partial information in a
|
|||
|
scheme of Shamir, Rivest and Adleman.
|
|||
|
|
|||
|
Quadratic residuosity modulo a composite is an example of a
|
|||
|
trapdoor function. Yao [YAO-82] showed that under certain
|
|||
|
conditions, trapdoor functions in general can be used to construct
|
|||
|
provably secure probabilistic public-key cryptosystems. An
|
|||
|
important role is also played by probabilistic encryption in zero-
|
|||
|
knowledge proofs, especially for problems in NP.
|
|||
|
|
|||
|
We remark briefly that the above scheme is only one of a class
|
|||
|
of encryption schemes which Rivest and Sherman [RIVE82] term
|
|||
|
randomized encryption techniques; various other schemes are
|
|||
|
summarized there. We have characterized schemes such as the above
|
|||
|
as bit-by-bit; more generally, a randomized scheme is any scheme
|
|||
|
in which a ciphertext for a given plaintext is randomly chosen from
|
|||
|
a set of possible ciphertexts. Rivest and Sherman also develop a
|
|||
|
classification for such schemes. A major aspect of randomized
|
|||
|
schemes is often significant data expansion. For example, the
|
|||
|
Goldwasser/Micali scheme would probably have ciphertext around 512
|
|||
|
times as large as the plaintext. On the other hand, probabilistic
|
|||
|
schemes may be much faster than their deterministic counterparts,
|
|||
|
an attractive feature for smart-card implementations.
|
|||
|
|
|||
|
|
|||
|
P.2 Identity-based schemes.
|
|||
|
|
|||
|
|
|||
|
In [SHAM84], Shamir suggests yet another modification of
|
|||
|
traditional public-key systems. In Shamir's framework a user's
|
|||
|
public key coincides with his system ID. This eliminates the need
|
|||
|
for any superstructure for distribution of public keys. It also
|
|||
|
trivializes the authentication of public keys. However, unlike a
|
|||
|
traditional public-key scheme this modification requires a trusted
|
|||
|
key generation center.
|
|||
|
|
|||
|
The center issues a smart card to each user, containing the
|
|||
|
user's private key. Thus the "private" key is really a shared
|
|||
|
secret key. A card can generate the user's digital signature. The
|
|||
|
center does not maintain a database of keys; in fact it need not
|
|||
|
even keep information beyond a list of user IDs (needed to ensure
|
|||
|
that there are no duplicate IDs).
|
|||
|
|
|||
|
Security for such a system differs from the usual requirement
|
|||
|
that a user keep his private key a secret. The latter condition is
|
|||
|
retained, in that a user must guard his card. As in a certificate-
|
|||
|
based traditional system, the center must ascertain a user's
|
|||
|
identity before issuing a card. In addition, however, the
|
|||
|
cryptographic function used by the center to generate private keys
|
|||
|
from IDs must be kept secret. Typically this function would employ
|
|||
|
trapdoor information such as the factorization of a modulus. The
|
|||
|
requirement is that computing the private key from an ID is easy
|
|||
|
if the trapdoor information is known, but knowing any polynomial
|
|||
|
number of public/secret pairs should not reveal the trapdoor.
|
|||
|
|
|||
|
A weakness in such a scheme is that anyone (intruder or insider)
|
|||
|
possessing the trapdoor information can forge the signature of any
|
|||
|
user. This is in contradistinction, e.g., to a credit-card scheme
|
|||
|
in which a transaction is generally valid only if accompanied by
|
|||
|
a user's physical signature. Also, the center is not required to
|
|||
|
maintain any information on lost or stolen cards; thus the loss of
|
|||
|
a card is disastrous since the possessor can forge the legitimate
|
|||
|
user's signature indefinitely. Furthermore, the center may find
|
|||
|
itself involved in litigation produced by any such security
|
|||
|
problems, since it is providing the means by which users generate
|
|||
|
signatures. Again this in contrast to the credit-card situation:
|
|||
|
if a credit card is stolen, the thief cannot forge the legitimate
|
|||
|
holder's physical signature, providing a means of distinguishing
|
|||
|
between legal and illegal usage of the card. Use of passwords
|
|||
|
(PINs) with cards could largely eliminate the problems accruing
|
|||
|
from lost or stolen cards, but compromise of the trapdoor would
|
|||
|
still be disastrous.
|
|||
|
|
|||
|
Shamir's notion was later ([FEIG87],[FIAT86]) incorporated into
|
|||
|
zero-knowledge schemes. One of these was used as the basis for the
|
|||
|
example in appendix O.
|
|||
|
|
|||
|
|
|||
|
REFERENCES
|
|||
|
|
|||
|
|
|||
|
[ADLE79] L. Adleman, "A subexponential algorithm for the discrete
|
|||
|
logarithm problem with applications to cryptography," in 20th
|
|||
|
Annual Symposium on Foundations of Computer Science, San Juan,
|
|||
|
Puerto Rico, October 29-31, 1979, pp. 55-60. Silver Spring, MD:
|
|||
|
IEEE Computer Society Press, 1979.
|
|||
|
|
|||
|
[ADLE82] L. M. Adleman, "On breaking the iterated Merkle-Hellman
|
|||
|
public-key cryptosystems," in D. Chaum, R. L. Rivest, and A. T.
|
|||
|
Sherman, Eds., Advances in Cryptology: proceedings of CRYPTO 82,
|
|||
|
a Workshop on the Theory and Application of Cryptographic
|
|||
|
Techniques, Santa Barbara, CA, August 23-25, 1982, pp. 303-308. New
|
|||
|
York: Plenum Press, 1983.
|
|||
|
|
|||
|
[ADLE86] L. M. Adleman and K. S. McCurley, "Open problems in number
|
|||
|
theoretic complexity," in D. S. Johnson, T. Nishizeki, A. Nozaki,
|
|||
|
and H. S. Wilf, Eds., Discrete Algorithms and Complexity,
|
|||
|
proceedings of the Japan-US Joint Seminar, Kyoto, Japan, June 4-
|
|||
|
6, 1986, pp. 237-262. Orlando, FL: Academic Press, 1987.
|
|||
|
|
|||
|
[ADLE83] L. M. Adleman, C. Pomerance, and R. S. Rumely, "On
|
|||
|
distinguishing prime numbers from composite numbers," Annals of
|
|||
|
Mathematics, Vol. 117, 1983, pp. 173-206.
|
|||
|
|
|||
|
[AKL-83] S. G. Akl, "Digital signatures: a tutorial survey,"
|
|||
|
Computer, Vol. 16, No. 2, February 1983, pp. 15-24.
|
|||
|
|
|||
|
[AKL-84] S. G. Akl and H. Meijer, "A fast pseudo random permutation
|
|||
|
generator with applications to cryptology," in G. R. Blakley and
|
|||
|
D. Chaum, Eds., Lecture Notes in Computer Science Vol. 196:
|
|||
|
Advances in Cryptology: Proceedings of CRYPTO 84, a Workshop on the
|
|||
|
Theory and Application of Cryptographic Techniques, Santa Barbara,
|
|||
|
CA, August 19-22, 1984, pp. 269-275. Berlin/New York: Springer-
|
|||
|
Verlag, 1985.
|
|||
|
|
|||
|
[ANSI85] American National Standard X9.17-1985, Financial
|
|||
|
Institution Key Management (Wholesale), American Bankers
|
|||
|
Association, Washington, DC, 1985.
|
|||
|
|
|||
|
[ANNA87] M. Annaratone, E. Arnould, T. Gross, H. T. Kung, M. Lam,
|
|||
|
O. Menzilcioglu, and J. A. Webb, "The Warp computer: architecture,
|
|||
|
implementation and performance," IEEE Transactions on Computers,
|
|||
|
Vol. C-36, No. 12, December 1987, pp. 1523-1538.
|
|||
|
|
|||
|
[BANE82] S. K. Banerjee, "High speed implementation of DES,"
|
|||
|
Computers & Security, Vol. 1, No. 3, November 1982, pp. 261-267.
|
|||
|
|
|||
|
[BART63] T. C. Bartee and D. I. Schneider, "Computation with Finite
|
|||
|
Fields," Information and Control, Vol. 6, 1963, pp. 79-98.
|
|||
|
|
|||
|
[BATC80] K. E. Batcher, "Design of a massively parallel processor,"
|
|||
|
IEEE Transactions on Computers, Vol. C-29, No. 9, September 1980,
|
|||
|
pp. 836-840.
|
|||
|
|
|||
|
[BLAK84] I. F. Blake, R. Fuji-Hara, R. C. Mullin, and S. A.
|
|||
|
Vanstone, "Computing logarithms in finite fields of characteristic
|
|||
|
two," SIAM Journal on Algebraic and Discrete Methods, Vol. 5, No.
|
|||
|
2, June 1984, pp. 276-285.
|
|||
|
|
|||
|
[BLAK84b] I. F. Blake, R. C. Mullin, and S. A. Vanstone, "Computing
|
|||
|
logarithms in GF(2n)," in G. R. Blakley and D. Chaum, Eds., Lecture
|
|||
|
Notes in Computer Science Vol. 196: Advances in Cryptology:
|
|||
|
Proceedings of CRYPTO 84, a Workshop on the Theory and Application
|
|||
|
of Cryptographic Techniques, Santa Barbara, CA, August 19-22, 1984,
|
|||
|
pp. 73-82. Berlin/New York: Springer-Verlag, 1985.
|
|||
|
|
|||
|
[BLAK83] G. R. Blakley, "A computer algorithm for calculating the
|
|||
|
product AB modulo M," IEEE Transactions on Computers, Vol. C-32,
|
|||
|
No. 5, May 1983, pp. 497-500.
|
|||
|
|
|||
|
[BLUM84] M. Blum and S. Micali, "How to generate cryptographically
|
|||
|
strong sequences of pseudo-random bits," SIAM Journal on
|
|||
|
Computing, Vol. 13, No. 4, November 1984, pp. 850-864.
|
|||
|
|
|||
|
[BOOT81] K. S. Booth, "Authentication of signatures using public
|
|||
|
key encryption," Communications of the ACM, Vol. 24, No. 11,
|
|||
|
November 1981, pp. 772-774.
|
|||
|
|
|||
|
[BRAN75] D. K. Branstad, "Encryption protection in computer data
|
|||
|
communications," in Proceedings of the 4th Data Communications
|
|||
|
Symposium, October 7-9, 1975, pp. 8.1 - 8.7. IEEE.
|
|||
|
|
|||
|
[BRAS79] G. Brassard, "A note on the complexity of cryptography,"
|
|||
|
IEEE Transactions on Information Theory, Vol. IT-25, No. 2, March
|
|||
|
1979, pp. 232-233.
|
|||
|
|
|||
|
[BRAS83] G. Brassard, "Relativized cryptography," IEEE Transactions
|
|||
|
on Information Theory, Vol. IT-29, No. 6, November 1983, pp. 877-
|
|||
|
894.
|
|||
|
|
|||
|
[BRAS88] G. Brassard, Lecture Notes in Computer Science Vol. 325:
|
|||
|
Modern Cryptology: a Tutorial. Berlin/New York: Springer-Verlag,
|
|||
|
1988.
|
|||
|
|
|||
|
[BREN83] R. P. Brent and H. T. Kung, "Systolic VLSI arrays for
|
|||
|
linear-time GCD computation," in F. Anceau and E. J. Aas, Eds.,
|
|||
|
VLSI 83, proceedings of the IFIP TC 10/WG 10.5 International
|
|||
|
Conference on VLSI, Trondheim, Norway, August 16-19, 1983, pp. 145-
|
|||
|
154. Amsterdam/New York: North-Holland, 1983.
|
|||
|
|
|||
|
[BREN83b] R. P. Brent, H. T. Kung, and F. T. Luk, "Some linear-
|
|||
|
time algorithms for systolic arrays," in R. E. A. Mason, Ed., IFIP
|
|||
|
Congress Series Vol. 9: Information Processing 83, proceedings of
|
|||
|
the IFIP 9th World Congress, Paris, France, September 19-23, 1983,
|
|||
|
pp. 865-876. Amsterdam/New York: North-Holland, 1983.
|
|||
|
|
|||
|
[BRIC82] E. F. Brickell, "A fast modular multiplication algorithm
|
|||
|
with application to two key cryptography," in D. Chaum, R. L.
|
|||
|
rivest, and A. T. Sherman, Eds., Advances in Cryptology:
|
|||
|
proceedings of CRYPTO '82, a Workshop on the Theory and Application
|
|||
|
of Cryptographic Techniques, Santa Barbara, CA, August 23-25, 1982,
|
|||
|
pp. 51-60. New York: Plenum Press, 1983.
|
|||
|
|
|||
|
[BRIC83] E. F. Brickell, "Solving low density knapsacks," in D.
|
|||
|
Chaum, Ed., Advances in Cryptology: proceedings of CRYPTO 83, a
|
|||
|
Workshop on the Theory and Application of Cryptographic Techniques,
|
|||
|
Santa Barbara, CA, August 22-24, 1983, pp. 25-37. New York: Plenum
|
|||
|
Press, 1984.
|
|||
|
|
|||
|
[BRIC84] E. F. Brickell, "Breaking iterated knapsacks," in G. R.
|
|||
|
Blakley and D. Chaum, Eds., Lecture Notes in Computer Science Vol.
|
|||
|
196: Advances in Cryptology: Proceedings of CRYPTO 84, a Workshop
|
|||
|
on the Theory and Application of Cryptographic Techniques, Santa
|
|||
|
Barbara, CA, August 19-22, 1984, pp. 342-358. Berlin/New York:
|
|||
|
Springer-Verlag, 1985.
|
|||
|
|
|||
|
[BRIC89] E. F. Brickell, "A survey of hardware implementations of
|
|||
|
RSA," in G. Brassard, Ed., Lecture Notes in Computer Science Vol.
|
|||
|
435: Advances in Cryptology - Proceedings of CRYPTO '89, pp. 368-
|
|||
|
370. Berlin/New York: Springer-Verlag, 1990.
|
|||
|
|
|||
|
[BRIC88] E. F. Brickell and A. M. Odlyzko, "Cryptanalysis: a survey
|
|||
|
of recent results," Proceedings of the IEEE, Vol. 76, No. 5, May
|
|||
|
1988, pp. 578-593.
|
|||
|
|
|||
|
[BRIG76] H. S. Bright and R. L. Enison, "Cryptography using modular
|
|||
|
software elements," in S. Winkler, Ed., AFIPS Conference
|
|||
|
Proceedings Vol. 45: National Computer Conference, New York, NY,
|
|||
|
June 7-10, 1976, pp. 113-123. Montvale, NJ: AFIPS Press, 1976.
|
|||
|
|
|||
|
[CCIT87] CCITT, Draft Recommendation X.509: The Directory -
|
|||
|
Authentication Framework. Gloucester, November 1987.
|
|||
|
|
|||
|
[CARO87] T. R. Caron and R. D. Silverman, "Parallel implementation
|
|||
|
of the quadratic scheme," Journal of Supercomputing, Vol. 1, No.
|
|||
|
3, 1987.
|
|||
|
|
|||
|
[COHE87] H. Cohen and A. K. Lenstra, "Implementation of a new
|
|||
|
primality test," Mathematics of Computation, Vol. 48, No. 177,
|
|||
|
January 1987, pp. 103-121.
|
|||
|
|
|||
|
[COHE84] H. Cohen and H. W. Lenstra, Jr., "Primality testing and
|
|||
|
Jacobi sums," Mathematics of Computation, Vol. 42, No. 165, January
|
|||
|
1984, pp. 297-330.
|
|||
|
|
|||
|
[CONT80] Control Data Corporation, CDC CYBER 200 Model 205 Computer
|
|||
|
System. Minneapolis, MN, 1980.
|
|||
|
|
|||
|
[COPP84] D. Coppersmith, "Fast evaluation of logarithms in fields
|
|||
|
of characteristic two," IEEE Transactions on Information Theory,
|
|||
|
Vol. IT-30, No. 4, July 1984, pp. 587-594.
|
|||
|
|
|||
|
[COPP85] D. Coppersmith, "Another birthday attack," in H. C.
|
|||
|
Williams, Ed., Lecture Notes in Computer Science Vol. 218: Advances
|
|||
|
in Cryptology - CRYPTO '85, proceedings of a Conference on the
|
|||
|
Theory and Applications of Cryptographic Techniques, Santa Barbara,
|
|||
|
CA, August 18-22, 1985, pp. 14-17. Berlin/New York: Springer-
|
|||
|
Verlag, 1986.
|
|||
|
|
|||
|
[COPP87] D. Coppersmith, "Cryptography," IBM Journal of Research
|
|||
|
and Development, Vol. 31, No. 2, March 1987, pp. 244-248.
|
|||
|
|
|||
|
[COPP86] D. Coppersmith, A. M. Odlyzko, and R. Schroeppel,
|
|||
|
"Discrete logarithms in GF(p)," Algorithmica, Vol. 1, No. 1, 1986,
|
|||
|
pp. 1-15.
|
|||
|
|
|||
|
[CRAY80] Cray Research, Inc., Cray 1-S Series Hardware Reference
|
|||
|
Manual. Mendota Heights, MN, June 1980.
|
|||
|
|
|||
|
[CRAY85] Cray Research, Inc., Cray X-MP Series of Computer Systems.
|
|||
|
Mendota Heights, MN, August 1985.
|
|||
|
|
|||
|
[DAVI83] D. W. Davies, "Applying the RSA digital signature to
|
|||
|
electronic mail," Computer, Vol. 16, No. 2, February 1983, pp. 55-
|
|||
|
62.
|
|||
|
|
|||
|
[DAVI80] D. W. Davies and W. L. Price, "The application of digital
|
|||
|
signatures based on public key cryptosystems," NPL Report DNACS
|
|||
|
39/80, National Physics Laboratory, Teddington, Middlesex, England,
|
|||
|
December 1980.
|
|||
|
|
|||
|
[DAVI83b] J. A. Davis and D. B. Holdridge, "Factorization using the
|
|||
|
quadratic sieve algorithm," in D. Chaum, Ed., Advances in
|
|||
|
Cryptology: proceedings of CRYPTO 83, a Workshop on the Theory and
|
|||
|
Application of Cryptographic Techniques, Santa Barbara, CA, August
|
|||
|
22-24, 1983, pp. 103-113. New York: Plenum Press, 1984.
|
|||
|
|
|||
|
[DAVI84] J. A. Davis, D. B. Holdridge, and G. J. Simmons, "Status
|
|||
|
report on factoring," in T. Beth, N. Cot, and I. Ingemarsson, Eds.,
|
|||
|
Lecture Notes in Computer Science Vol. 209: Advances in Cryptology:
|
|||
|
Proceedings of EUROCRYPT 84, a Workshop on the Theory and
|
|||
|
Application of Cryptographic Techniques, Paris, France, April 9-
|
|||
|
11, 1984, pp. 183-215. Berlin/New York: Springer-Verlag, 1985.
|
|||
|
|
|||
|
[DEMI83] R. DeMillo and M. Merritt, "Protocols for data security,"
|
|||
|
Computer, Vol. 16, No. 2, February 1983, pp. 39-51.
|
|||
|
|
|||
|
[DENN79] D. E. Denning, "Secure personal computing in an insecure
|
|||
|
network," Communications of the ACM, Vol. 22, No. 8, August 1979,
|
|||
|
pp. 476-482.
|
|||
|
|
|||
|
[DENN83b] D. E. Denning, "Protecting public keys and signature
|
|||
|
keys," Computer, Vol. 16, No. 2, February 1983, pp. 27-35.
|
|||
|
|
|||
|
[DENN81] D. E. Denning and G. M. Sacco, "Timestamps in key
|
|||
|
distribution protocols," Communications of the ACM, Vol. 24, No.
|
|||
|
8, August 1981, pp. 533-536.
|
|||
|
|
|||
|
[DENN83] D. E. R. Denning, Cryptography and Data Security. Reading,
|
|||
|
MA: Addison-Wesley, 1983.
|
|||
|
|
|||
|
[DESM83] Y. Desmedt, J. Vandewalle, and R. J. M. Govaerts, "A
|
|||
|
critical analysis of the security of knapsack public key
|
|||
|
algorithms," IEEE Transactions on Information Theory, Vol. IT-30,
|
|||
|
No. 4, July 1984, pp. 601-611.
|
|||
|
|
|||
|
[DIFF82] W. Diffie, "Conventional versus public key cryptosystems,"
|
|||
|
in G. J. Simmons, Ed., Secure Communications and Asymmetric
|
|||
|
Cryptosystems, pp. 41-72. Boulder, CO: Westview Press, 1982.
|
|||
|
|
|||
|
[DIFF84] W. Diffie, "Network security problems and approaches,"
|
|||
|
Proceedings of the National Electronics Conference, Vol. 38, 1984,
|
|||
|
pp. 292-314.
|
|||
|
|
|||
|
[DIFF86] W. Diffie, "Communication security and national security
|
|||
|
business, technology, and politics," Proceedings of the National
|
|||
|
Communications Forum, Vol. 40, 1986, pp. 734-751.
|
|||
|
|
|||
|
[DIFF88] W. Diffie, "The first ten years of public-key
|
|||
|
cryptography," Proceedings of the IEEE, Vol. 76, No. 5, May 1988,
|
|||
|
pp. 560-577.
|
|||
|
|
|||
|
[DIFF76] W. Diffie and M. E. Hellman, "Multiuser cryptographic
|
|||
|
techniques," in S. Winkler, Ed., AFIPS Conference Proceedings Vol.
|
|||
|
45: National Computer Conference, New York, NY, June 7-10, 1976,
|
|||
|
pp. 109-112. Montvale, NJ: AFIPS Press, 1976.
|
|||
|
|
|||
|
[DIFF76b] W. Diffie and M. E. Hellman, "New directions in
|
|||
|
cryptography," IEEE Transactions on Information Theory, Vol. IT-22,
|
|||
|
No. 6, November 1976, pp. 644-654.
|
|||
|
|
|||
|
[DIFF79] W. Diffie and M. E. Hellman, "Privacy and authentication:
|
|||
|
an introduction to cryptography," Proceedings of the IEEE, Vol. 67,
|
|||
|
No. 3, March 1979, pp. 397-427.
|
|||
|
|
|||
|
[DIFF87] W. Diffie, B. O'Higgins, L. Strawczynski, and D. Steer,
|
|||
|
"An ISDN secure telephone unit," Proceedings of the National
|
|||
|
Communications Forum, Vol. 41, No. 1, 1987, pp. 473-477.
|
|||
|
|
|||
|
[DIXO81] J. D. Dixon, "Asymptotically fast factorization of
|
|||
|
integers," Mathematics of Computation, Vol. 36, No. 153, January
|
|||
|
1981, pp. 255-260.
|
|||
|
|
|||
|
[DOLE81] D. Dolev and A. C. Yao, "On the security of public key
|
|||
|
protocols," in 22nd Annual Symposium on Foundations of Computer
|
|||
|
Science, Nashville, TN, October 28-30, 1981, pp. 350-357. Silver
|
|||
|
Spring, MD: IEEE Computer Society Press, 1981.
|
|||
|
|
|||
|
|
|||
|
[DUSS90] S. R. Dusse and B. S. Kaliski, Jr., "A cryptographic
|
|||
|
library for the Motorola DSP 56000," presented at EUROCRYPT '90,
|
|||
|
Aarhuis, DEnmark, May 21-24, 1990.
|
|||
|
|
|||
|
[EHRS78] W. F. Ehrsam, S. M. Matyas, C. H. Meyer, and W. L.
|
|||
|
Tuchman, "A cryptographic key management scheme for implementing
|
|||
|
the Data Encryption Standard," IBM Systems Journal, Vol. 17, No.
|
|||
|
2, 1978, pp. 106-125.
|
|||
|
|
|||
|
[ELGA85] T. ElGamal, "A public key cryptosystem and a signature
|
|||
|
scheme based on discrete logarithms," IEEE Transactions on
|
|||
|
Information Theory, Vol. IT-31, No. 4, July 1985, pp. 469-472.
|
|||
|
|
|||
|
[ELGA85b] T. ElGamal, "On computing logarithms over finite fields,"
|
|||
|
in H. C. Williams, Ed., Lecture Notes in Computer Science Vol. 218:
|
|||
|
Advances in Cryptology - CRYPTO '85, proceedings of a Conference
|
|||
|
on the Theory and Applications of Cryptographic Techniques, Santa
|
|||
|
Barbara, CA, August 18-22, 1985, pp. 396-402. Berlin/New York:
|
|||
|
Springer-Verlag, 1986.
|
|||
|
|
|||
|
[EVAN74] A. Evans Jr. and W. Kantrowitz, "A user authentication
|
|||
|
scheme not requiring secrecy in the computer," Communications of
|
|||
|
the ACM, Vol. 17, No. 8, August 1974, pp. 437-442.
|
|||
|
|
|||
|
[FEIG87] U. Feige, A. Fiat, and A. Shamir, "Zero knowledge proofs
|
|||
|
of identity," in Proceedings of the Nineteenth Annual ACM Symposium
|
|||
|
on Theory of Computing, New York, NY, May 25-27, 1987, pp. 210-
|
|||
|
217. New York: ACM, 1987.
|
|||
|
|
|||
|
[FIAT86] A. Fiat and A. Shamir, "How to prove yourself: practical
|
|||
|
solutions to identification and signature problems," in A. M.
|
|||
|
Odlyzko, Ed., Lecture Notes in Computer Science Vol. 263: Advances
|
|||
|
in Cryptology - CRYPTO '86, proceedings of a Conference on the
|
|||
|
Theory and Applications of Cryptographic Techniques, Santa Barbara,
|
|||
|
CA, August 11-15, 1986, pp. 186-194. Berlin/New York: Springer-
|
|||
|
Verlag, 1987.
|
|||
|
|
|||
|
[FLYN78] R. Flynn and A. S. Campasano, "Data dependent keys for a
|
|||
|
selective encryption terminal," in S. P. Ghosh and L. Y. Liu, Eds.,
|
|||
|
AFIPS Conference Proceedings Vol. 47: National Computer Conference,
|
|||
|
Anaheim, CA, June 5-8, 1978, pp. 1127-1129. Montvale, NJ: AFIPS
|
|||
|
Press, 1978.
|
|||
|
|
|||
|
[GARE79] M. R. Garey and D. S. Johnson, Computers and
|
|||
|
Intractability. New York: W. H. Freeman, 1979.
|
|||
|
|
|||
|
[GILL77] J. Gill, "Computational complexity of probabilistic Turing
|
|||
|
machines," SIAM Journal on Computing, Vol. 6, No. 4, December 1977,
|
|||
|
pp. 675-695.
|
|||
|
|
|||
|
[GOLD84] S. Goldwasser and S. Micali, "Probabilistic encryption,"
|
|||
|
Journal of Computer and System Sciences, Vol. 28, No. 2, April
|
|||
|
1984, pp. 270-299.
|
|||
|
|
|||
|
[GOLD89] S. Goldwasser, S. Micali, and C. Rackoff, "The knowledge
|
|||
|
complexity of interactive proof systems," SIAM Journal on
|
|||
|
Computing, Vol. 18, No. 1, February 1989, pp. 186-208.
|
|||
|
|
|||
|
[GOLD88] S. Goldwasser, S. Micali, and R. L. Rivest, "A digital
|
|||
|
signature scheme secure against adaptive chosen-message attacks,"
|
|||
|
SIAM Journal on Computing, Vol. 17, No. 2, April 1988, pp. 281-308.
|
|||
|
|
|||
|
[GORD84b] J. Gordon, "Strong RSA keys," Electronics Letters, Vol.
|
|||
|
20, No. 12, June 7, 1984, pp. 514-516.
|
|||
|
|
|||
|
[GORD84] J. A. Gordon, "Strong primes are easy to find," in T.
|
|||
|
Beth, N. Cot, and I. Ingemarsson, Eds., Lecture Notes in Computer
|
|||
|
Science Vol. 209: Advances in Cryptology: Proceedings of EUROCRYPT
|
|||
|
84, a Workshop on the Theory and Application of Cryptographic
|
|||
|
Techniques, Paris, France, April 9-11, 1984, pp. 216-223.
|
|||
|
Berlin/New York: Springer-Verlag, 1985.
|
|||
|
|
|||
|
[GROL88] J. Grollman and A. L. Selman, "Complexity measures for
|
|||
|
public-key cryptosystems," SIAM Journal on Computing, Vol. 17, No.
|
|||
|
2, April 1988, pp. 309-335.
|
|||
|
|
|||
|
[HAST88] J. Hastad, "Solving simultaneous modular equations of low
|
|||
|
degree," SIAM Journal on Computing, Vol. 17, No. 2, April 1988, pp.
|
|||
|
336-341.
|
|||
|
|
|||
|
[HAWK87] S. Hawkinson, "The FPS T Series: a parallel vector
|
|||
|
supercomputer," in W. J. Karplus, Ed., Multiprocessors and Array
|
|||
|
Processors, pp. 147-155. San Diego: Simulation Councils Inc., 1987.
|
|||
|
|
|||
|
[HAYE86] J. P. Hayes, T. Mudge, Q. F. Stout, S. Colley, and J.
|
|||
|
Palmer, "A microprocessor-based hypercube supercomputer," IEEE
|
|||
|
Micro, Vol. 6, No. 5, October 1986, pp. 6-17.
|
|||
|
|
|||
|
[HAYK88] M. E. Haykin and R. B. J. Warnar, "Smart card technology:
|
|||
|
new methods for computer access control," NIST Special Publication
|
|||
|
500-157, September 1988.
|
|||
|
|
|||
|
[HENR81] P. S. Henry, "Fast decryption algorithm for the knapsack
|
|||
|
cryptographic system," Bell System Technical Journal, Vol. 60, No.
|
|||
|
5, May-June 1981, pp. 767-773.
|
|||
|
|
|||
|
[HERS64] I. N. Herstein, Topics in Algebra. Waltham: Blaisdell,
|
|||
|
1964.
|
|||
|
|
|||
|
[HILL85] D. Hillis, The Connection Machine. Cambridge, MA: MIT
|
|||
|
Press, 1985.
|
|||
|
|
|||
|
[HOCK81] R. W. Hockney and C. R. Jesshope, Parallel Computers:
|
|||
|
Architecture, Programming and Algorithms. Bristol: Adam Hilger,
|
|||
|
1981.
|
|||
|
|
|||
|
[HORO78] E. Horowitz and S. Sahni, Fundamentals of Computer
|
|||
|
Algorithms. Rockville: Computer Science Press, 1978.
|
|||
|
|
|||
|
[HWAN84] K. Hwang and F. A. Briggs, Computer Architecture and
|
|||
|
Parallel Processing. New York: McGraw-Hill, 1984.
|
|||
|
|
|||
|
[IAB-90] IAB Privacy and Security Research Group, "Privacy
|
|||
|
enhancement for Internet electronic mail: Part I: Message
|
|||
|
encipherment and authentication procedures," RFC 1113B, December
|
|||
|
18, 1990.
|
|||
|
|
|||
|
[ISO-87] International Organization for Standards, Draft
|
|||
|
International Standard ISO/DIS 7498-2, Information processing
|
|||
|
systems - Open Systems Interconnection Model - Part 2: Security
|
|||
|
Architecture, 1987.
|
|||
|
|
|||
|
[JUEN82] R. R. Jueneman, "Analysis of certain aspects of output
|
|||
|
feedback mode," in D. Chaum, R. L. Rivest, and A. T. Sherman, Eds.,
|
|||
|
Advances in Cryptology - proceedings of CRYPTO 82, a Workshop on
|
|||
|
the Theory and Application of Cryptographic Techniques, Santa
|
|||
|
Barbara, CA, August 23-25, 1982, pp. 99-127. New York: Plenum
|
|||
|
Press, 1983.
|
|||
|
|
|||
|
[JUEN86] R. R. Jueneman, "A high speed manipulation detection
|
|||
|
code," in A. M. Odlyzko, Ed., Lecture Notes in Computer Science
|
|||
|
Vol. 263: Advances in Cryptology - CRYPTO '86, proceedings of a
|
|||
|
Conference on Theory and Applications of Cryptographic Techniques,
|
|||
|
Santa Barbara, CA, August 11-15, 1986, pp. 327-346. Berlin/New
|
|||
|
York: Springer-Verlag, 1987.
|
|||
|
|
|||
|
[KHAC79] L. G. Khacian, "A polynomial algorithm in linear
|
|||
|
programming," Dokl. Akad. Nauk. SSSR 244, pp. 1093-1096. English
|
|||
|
translation in Soviet Math. Dokl. 20, pp. 191-194.
|
|||
|
|
|||
|
[KLIN79] C. S. Kline and G. J. Popek, "Public key vs. conventional
|
|||
|
key encryption," in R. E. Merwin, Ed., AFIPS Conference
|
|||
|
Proceedings Vol. 48: National Computer Conference, June 4-7, 1979,
|
|||
|
New York, NY, pp. 831-837. Montvale, NJ: AFIPS Press, 1979.
|
|||
|
|
|||
|
[KNUT81] D. E. Knuth, The Art of Computer Programming, Vol. 2:
|
|||
|
Seminumerical Algorithms. Reading, MA: Addison-Wesley, 1981.
|
|||
|
|
|||
|
[KOHN78b] L. M. Kohnfelder, "On the signature reblocking problem
|
|||
|
in public-key cryptosystems," Communications of the ACM, Vol. 21,
|
|||
|
No. 2, February 1978, p. 179.
|
|||
|
|
|||
|
[KOHN78] L. M. Kohnfelder, "A method for certification," MIT
|
|||
|
Laboratory for Computer Science, Cambridge, MA, May 1978.
|
|||
|
|
|||
|
[KONH81] A. G. Konheim, Cryptography: a Primer. New York: John
|
|||
|
Wiley & Sons, 1981.
|
|||
|
|
|||
|
[KOWA85] J. Kowalik, Ed., Parallel MIMD Computation: the HEP
|
|||
|
supercomputer and its Applications. Cambridge, MA: MIT Press, 1985.
|
|||
|
|
|||
|
[KRAN86] E. Kranakis, Primality and Cryptography. Chichester/New
|
|||
|
York: John Wiley & Sons, 1986.
|
|||
|
|
|||
|
[KUNG82] H. T. Kung, "Why systolic architectures," Computer, Vol.
|
|||
|
15, No. 1, January 1982, pp. 37-46.
|
|||
|
|
|||
|
[KUNG78] H. T. Kung and C. Leiserson, "Systolic arrays (for VLSI),"
|
|||
|
in I. S. Duff and G. W. Stewart, Eds., Sparse Matrix Proceedings,
|
|||
|
pp. 245-282. Philadelphia: SIAM, 1978.
|
|||
|
|
|||
|
[KUNG82b] S. Y. Kung, K. S. Arun, R. J. Gal-Ezer, and D. V. B. Rao,
|
|||
|
"Wavefront array processor: language, architecture, and
|
|||
|
applications," IEEE Transactions on Computers, Vol. C-31, No. 11,
|
|||
|
November 1982, pp. 1054-1066.
|
|||
|
|
|||
|
[LAGA84] J. C. Lagarias, "Performance analysis of Shamir's attack
|
|||
|
on the basic Merkle-Hellman knapsack system," in J. Paredaens, Ed.,
|
|||
|
Lecture Notes in Computer Science Vol. 172: Automata, Languages and
|
|||
|
Programming: 11th Colloquium, Antwerp, Belgium, July 16-20, 1984,
|
|||
|
pp. 312-323. Berlin/New York: Springer-Verlag, 1984.
|
|||
|
|
|||
|
[LAGA83] J. C. Lagarias and A. M. Odlyzko, "Solving low-density
|
|||
|
subset sum problems," in 24th Annual Symposium on Foundations of
|
|||
|
Computer Science, Tucson, AZ, November 7-9, 1983, pp. 1-10. Silver
|
|||
|
Spring, MD: IEEE Computer Society Press, 1983. Revised version in
|
|||
|
Journal of the Association for Computing Machinery, Vol. 32, No.
|
|||
|
1, January 1985, pp. 229-246.
|
|||
|
|
|||
|
[LAKS83] S. Lakshmivarahan, "Algorithms for public key
|
|||
|
cryptosystems: theory and application," Advances in Computers, Vol.
|
|||
|
22, 1983, pp. 45-108.
|
|||
|
|
|||
|
[LAWS71] B. A. Laws, Jr. and C. K. Rushforth, "A cellular-array
|
|||
|
multiplier for GF(2m)," IEEE Transactions on Computers, Vol. 20,
|
|||
|
No. 12, December 1971, pp. 1573-1578.
|
|||
|
|
|||
|
[LEHM82] D. J. Lehman, "On primality tests," SIAM Journal on
|
|||
|
Computing, Vol. 11, No. 2, May 1982, pp. 374-375.
|
|||
|
|
|||
|
[LEHM76] D. H. Lehmer, "Strong Carmichael numbers," Journal of the
|
|||
|
Australian Mathematical Society, Vol. 21 (Series A), 1976, pp. 508-
|
|||
|
510.
|
|||
|
|
|||
|
[LEMP79] A. Lempel, "Cryptology in transition," ACM Computing
|
|||
|
Surveys, Vol. 11, No. 4, December 1979, pp. 285-303.
|
|||
|
|
|||
|
[LENS82] A. K. Lenstra, H. W. Lenstra, Jr., and L. Lovasz,
|
|||
|
"Factoring polynomials with rational coefficients," Mathematische
|
|||
|
Annalen, Vol. 261, 1982, pp. 515-534.
|
|||
|
|
|||
|
[LENS90] A. K. Lenstra, H. W. Lenstra, Jr., M. S. Manasse, and J.
|
|||
|
M. Pollard, "The number field sieve."
|
|||
|
|
|||
|
[LENS89] A. K. Lenstra and M. S. Manasse, "Factoring by electronic
|
|||
|
mail," to appear in proceedings of EUROCRYPT '89.
|
|||
|
|
|||
|
[LENS83] H. W. Lenstra, Jr., "Integer programming with a fixed
|
|||
|
number of variables," Mathematics of Operations Research, Vol. 8,
|
|||
|
No. 4, November 1983, pp. 538-548.
|
|||
|
|
|||
|
[LENS86] H. W. Lenstra, Jr., "Primality testing," in J. W. de
|
|||
|
Bakker et al., Eds., Mathematics and Computer Science, CWI
|
|||
|
Monographs, I, pp. 269-287. Amsterdam/New York: North-Holland,
|
|||
|
1986.
|
|||
|
|
|||
|
[LENS87] H. W. Lenstra, Jr., "Factoring integers with elliptic
|
|||
|
curves," Annals of Mathematics, Vol. 126, 1987, pp. 649-673.
|
|||
|
|
|||
|
[LEWI81] H. R. Lewis and C. H. Papadimitriou, Elements of the
|
|||
|
Theory of Computation. Englewood Cliffs, NJ: Prentice-Hall, 1981.
|
|||
|
|
|||
|
[LINN89] J. Linn and S. T. Kent, "Privacy for DARPA-Internet mail,"
|
|||
|
in Proceedings of the 12th National Computer Security Conference,
|
|||
|
Baltimore, MD, October 10-13, 1989, pp. 215-229.
|
|||
|
|
|||
|
[MACM81] D. MacMillan, "Single chip encrypts data at 14 Mb/s,"
|
|||
|
Electronics, Vol. 54, No. 12, June 16, 1981, pp. 161-165.
|
|||
|
|
|||
|
[MASS88] J. L. Massey, "An introduction to contemporary
|
|||
|
cryptology," Proceedings of the IEEE, Vol. 76, No. 5, May 1988,
|
|||
|
pp. 533-549.
|
|||
|
|
|||
|
[MATY78] S. M. Matyas and C. H. Meyer, "Generation, distribution,
|
|||
|
and installation of cryptographic keys," IBM Systems Journal, Vol.
|
|||
|
17, No. 2, 1978, pp. 126-137.
|
|||
|
|
|||
|
[MCCU89] K. S. McCurley, "The discrete logarithm problem,"
|
|||
|
preprint.
|
|||
|
|
|||
|
[MCEL78] R. J. McEliece, "A public-key cryptosystem based on
|
|||
|
algebraic coding theory," DSN Progress Report 42-44, Jet Propulsion
|
|||
|
Laboratory, 1978, pp. 114-116.
|
|||
|
|
|||
|
[MERK78] R. C. Merkle, "Secure communications over insecure
|
|||
|
channels," Communications of the ACM, Vol. 21, No. 4, April 1978,
|
|||
|
pp. 294-299.
|
|||
|
|
|||
|
[MERK82] R. C. Merkle, Secrecy, Authentication, and Public Key
|
|||
|
Systems. Ann Arbor: UMI Research Press, 1982.
|
|||
|
|
|||
|
[MERK82b] R. C. Merkle, "Protocols for public key cryptosystems,"
|
|||
|
in G. J. Simmons, Ed., Secure Communications and Asymmetric
|
|||
|
Cryptosystems, pp. 73-104. Boulder, CO: Westview Press, 1982.
|
|||
|
|
|||
|
[MERK89] R. C. Merkle, "One way hash functions and DES," preprint.
|
|||
|
|
|||
|
[MERK78b] R. C. Merkle and M. E. Hellman, "Hiding information and
|
|||
|
signatures in trapdoor knapsacks," IEEE Transactions on Information
|
|||
|
Theory, Vol. 24, No. 5, September 1978, pp. 525-530.
|
|||
|
|
|||
|
[MILL76] G. L. Miller, "Riemann's hypothesis and tests for
|
|||
|
primality," Journal of Computer and System Sciences, Vol. 13, No.
|
|||
|
3, December 1976, pp. 300-317.
|
|||
|
|
|||
|
[MILU88] V. M. Milutinovic, Computer Architecture: Concepts and
|
|||
|
Systems. New York: North-Holland, 1988.
|
|||
|
|
|||
|
[MONT85] P. L. Montgomery, "Modular multiplication without trial
|
|||
|
division," Mathematics of Computation, Vol. 44, No. 170, April
|
|||
|
1985, pp. 519-521.
|
|||
|
|
|||
|
[MOOR88] J. H. Moore, "Protocol failures in cryptosystems,"
|
|||
|
Proceedings of the IEEE, Vol. 76, No. 5, May 1988, pp. 594-602.
|
|||
|
|
|||
|
[MORR75] M. A. Morrison and J. Brillhart, "A method of factoring
|
|||
|
and the factorization of F7," Mathematics of Computation, Vol. 29,
|
|||
|
No. 129, January 1975, pp. 183-205.
|
|||
|
|
|||
|
[NATI77] National Bureau of Standards, Federal Information
|
|||
|
Processing Standards Publication 46: Data Encryption Standard,
|
|||
|
January 15, 1977.
|
|||
|
|
|||
|
[NATI80] National Bureau of Standards, Federal Information
|
|||
|
Processing Standards Publication 81: DES Modes of Operation,
|
|||
|
December 2, 1980.
|
|||
|
|
|||
|
[NATI81] National Bureau of Standards, Federal Information
|
|||
|
Processing Standards Publication 74: Guidelines for Implementing
|
|||
|
and Using the NBS Data Encryption Standard, April 1, 1981.
|
|||
|
|
|||
|
[NEED78] R. M. Needham and M. D. Schroeder, "Using encryption for
|
|||
|
authentication in large networks of computers," Communications of
|
|||
|
the ACM, Vol. 21, No. 12, December 1978, pp. 993-999.
|
|||
|
|
|||
|
[ODLY84] A. M. Odlyzko, "Cryptanalytic attacks on the
|
|||
|
multiplicative knapsack cryptosystem and on Shamir's fast signature
|
|||
|
scheme," IEEE Transactions on Information Theory, Vol. IT-30, No.
|
|||
|
4, July 1984, pp. 594-601.
|
|||
|
|
|||
|
[ODLY84b] A. M. Odlyzko, "Discrete logarithms in finite fields and
|
|||
|
their cryptographic significance," in T. Beth, N. Cot, and I.
|
|||
|
Ingemarsson, Eds., Lecture Notes in Computer Science Vol. 209:
|
|||
|
Advances in Cryptology: Proceedings of EUROCRYPT 84, a Workshop on
|
|||
|
the Theory and Application of Cryptographic Techniques, Paris,
|
|||
|
France, April 9-11, 1984, pp. 224-314. Berlin/New York: Springer-
|
|||
|
Verlag, 1985.
|
|||
|
|
|||
|
[ORTO86] G. A. Orton, M. P. Roy, P. A. Scott, L. E. Peppard, and
|
|||
|
S. E. Tavares, "VLSI implementation of public-key encryption
|
|||
|
algorithms," in A. M. Odlyzko, Ed., Lecture Notes in Computer
|
|||
|
Science Vol. 263: Advances in Cryptology - CRYPTO '86, proceedings
|
|||
|
of a Conference on the Theory and Applications of Cryptographic
|
|||
|
Techniques, Santa Barbara, CA, August 11-15, 1986, pp. 277-301.
|
|||
|
Berlin/New York: Springer-Verlag, 1987.
|
|||
|
|
|||
|
[PATT87] W. Patterson, Mathematical Cryptology for Computer
|
|||
|
Scientists and Mathematicians. Totowa, NJ: Rowman & Littlefield,
|
|||
|
1987.
|
|||
|
|
|||
|
[PERA86] R. C. Peralta, "A simple and fast probabilistic algorithm
|
|||
|
for computing square roots modulo a prime number," IEEE
|
|||
|
Transactions on Information Theory, Vol. 32, No. 6, November 1986,
|
|||
|
pp. 846-847.
|
|||
|
|
|||
|
[POHL78] S. C. Pohlig and M. E. Hellman, "An improved algorithm for
|
|||
|
computing logarithms over GF(p) and its cryptographic
|
|||
|
significance," IEEE Transactions on Information Theory, Vol. IT-24,
|
|||
|
No. 1, January 1978, pp. 106-110.
|
|||
|
|
|||
|
[POME84] C. Pomerance, "The quadratic sieve factoring algorithm,"
|
|||
|
in T. Beth, N. Cot, and I. Ingemarsson, Eds., Lecture Notes in
|
|||
|
Computer Science Vol. 209: Advances in Cryptology: proceedings of
|
|||
|
EUROCRYPT 84, a Workshop on the Theory and Application of
|
|||
|
Cryptographic Techniques, Paris, France, April 9-11, 1984, pp. 169-
|
|||
|
182. Berlin/New York: Springer-Verlag, 1985.
|
|||
|
|
|||
|
[POME86] C. Pomerance, "Fast, rigorous factorization and discrete
|
|||
|
logarithm algorithms," in D. S. Johnson, T. Nishizeki, A. Nozaki,
|
|||
|
and H. S. Wilf, Eds., Discrete Algorithms and Complexity,
|
|||
|
proceedings of the Japan-US Joint Seminar, Kyoto, Japan, June 4-
|
|||
|
6, 1986, pp. 119-143. Orlando, FL: Academic Press, 1987.
|
|||
|
|
|||
|
[POME88] C. Pomerance, J. W. Smith, and R. Tuler, "A pipeline
|
|||
|
architecture for factoring large integers with the quadratic sieve
|
|||
|
algorithm," SIAM Journal on Computing, Vol. 17, No. 2, April 1988,
|
|||
|
pp. 387-403.
|
|||
|
|
|||
|
[POPE78] G. J. Popek and C. S. Kline, "Encryption protocols, public
|
|||
|
key algorithms and digital signatures in computer networks," in R.
|
|||
|
A. DeMillo, D. P. Dobkin, A. K. Jones, and R. J. Lipton, Eds.,
|
|||
|
Foundations of Secure Computation, pp. 133-153. New York: Academic
|
|||
|
Press, 1978.
|
|||
|
|
|||
|
[POPE79] G. L. Popek and C. S. Kline, "Encryption and secure
|
|||
|
computer networks," ACM Computing Surveys, Vol. 11, No. 4, December
|
|||
|
1979, pp. 331-356.
|
|||
|
|
|||
|
[QUIN87] M. J. Quinn, Designing Efficient Algorithms for Parallel
|
|||
|
Computers. New York: McGraw-Hill, 1987.
|
|||
|
|
|||
|
[QUIS82] J.-J. Quisquater and C. Couvreur, "Fast decipherment
|
|||
|
algorithm for RSA public-key cryptosystem," Electronics Letters,
|
|||
|
Vol. 18, No. 21, October 14, 1982, pp. 905-907.
|
|||
|
|
|||
|
[RABI76] M. O. Rabin, "Probabilistic algorithms," in J. F. Traub,
|
|||
|
Ed., Algorithms and Complexity: New Directions and Recent Results,
|
|||
|
proceedings of a Symposium, Pittsburgh, PA, April 7-9, 1976, pp.
|
|||
|
21-39. New York: Academic Press, 1976.
|
|||
|
|
|||
|
[RABI78] M. O. Rabin, "Digitalized signatures," in R. A. DeMillo,
|
|||
|
D. P. Dobkin, A. K. Jones, and R. J. Lipton, Eds., Foundations of
|
|||
|
Secure Computation, pp. 155-168. New York: Academic Press, 1978.
|
|||
|
|
|||
|
[RABI79] M. O. Rabin, "Digitalized signatures and public-key
|
|||
|
functions as intractable as factorization," MIT Laboratory for
|
|||
|
Computer Science, Technical Report LCS/TR-212, January 1979.
|
|||
|
|
|||
|
[RABI80] M. O. Rabin, "Probabilistic algorithms for testing
|
|||
|
primality," Journal of Number Theory, Vol. 12, 1980, pp. 128-138.
|
|||
|
|
|||
|
[RADE64] H. Rademacher, Lectures on Elementary Number Theory. New
|
|||
|
York: Blaisdell, 1964.
|
|||
|
|
|||
|
[RIVE84] R. L. Rivest, "RSA chips (past/present/future)," in T.
|
|||
|
Beth, N. Cot, and I. Ingemarsson, Eds., Lecture Notes in Computer
|
|||
|
Science Vol. 209: Advances in Cryptology: proceedings of EUROCRYPT
|
|||
|
84, a Workshop on the Theory and Application of Cryptographic
|
|||
|
Techniques, Paris, France, April 9-11, 1984, pp. 159-165.
|
|||
|
Berlin/New York: Springer-Verlag, 1985.
|
|||
|
|
|||
|
[RIVE90] R. L. Rivest, "The MD4 message digest algorithm," February
|
|||
|
1990.
|
|||
|
|
|||
|
[RIVE78] R. L. Rivest, A. Shamir, and L. Adleman, "A method for
|
|||
|
obtaining digital signatures and public-key cryptosystems,"
|
|||
|
Communications of the ACM, Vol. 21, No. 2, February 1978, pp.
|
|||
|
120-127.
|
|||
|
|
|||
|
[RIVE82] R. L. Rivest and A. T. Sherman, "Randomized encryption
|
|||
|
techniques," in D. Chaum, R. L. Rivest, and A. T. Sherman, Eds.,
|
|||
|
Advances in Cryptology: Proceedings of CRYPTO 82, a Workshop on the
|
|||
|
Theory and Application of Cryptographic Techniques, Santa Barbara,
|
|||
|
CA, August 23-25, 1982, pp. 145-163. New York: Plenum Press, 1983.
|
|||
|
|
|||
|
[SIAM90] "Number field sieve produces factoring breakthrough," SIAM
|
|||
|
News, Vol. 23, No. 4, July 1990.
|
|||
|
|
|||
|
[SALO85] Salomaa, "Cryptography," in A. Salomaa, Encyclopedia of
|
|||
|
Mathematics and its Applications Vol. 25: Computation and Automata,
|
|||
|
pp. 186-230. Cambridge, UK: Cambridge University Press, 1985.
|
|||
|
|
|||
|
[SCHA82] B. P. Schanning, "Applying public key distribution to
|
|||
|
local area networks," Computers & Security, Vol. 1, No. 3, November
|
|||
|
1982, pp. 268-274.
|
|||
|
|
|||
|
[SCHA80] B. P. Schanning, S. A. Powers, and J. Kowalchuk, "MEMO:
|
|||
|
privacy and authentication for the automated office," in
|
|||
|
proceedings of the 5th Conference on Local Computer Networks,
|
|||
|
Minneapolis, MN, October 6-7, 1980, pp. 21-30. Silver Spring, MD:
|
|||
|
IEEE Computer Society Press, 1980.
|
|||
|
|
|||
|
[SCHN84] C. P. Schnorr and H. W. Lenstra, Jr., "A Monte Carlo
|
|||
|
factoring algorithm with linear storage," Mathematics of
|
|||
|
Computation, Vol. 43, No. 167, July 1984, pp. 289-311.
|
|||
|
|
|||
|
[SEDL87] H. Sedlak, "The RSA Cryptography Processor," in D. Chaum
|
|||
|
and W. L. Price, Eds., Lecture Notes in Computer Science Vol. 304:
|
|||
|
Advances in Cryptology - EUROCRYPT '87, a Workshop on the Theory
|
|||
|
and Applications of Cryptographic Techniques, Amsterdam, The
|
|||
|
Netherlands, April 13-15, 1987, pp. 95-105. Berlin/New York:
|
|||
|
Springer-Verlag, 1988.
|
|||
|
|
|||
|
[SEIT85] C. L. Seitz, "The Cosmic Cube," Communications of the ACM,
|
|||
|
Vol. 28, No. 1, January 1985, pp. 22-33.
|
|||
|
|
|||
|
[SHAM79] A. Shamir, "On the cryptocomplexity of knapsack systems,"
|
|||
|
in proceedings of the Eleventh Annual ACM Symposium on Theory of
|
|||
|
Computing, Atlanta, GA, April 30 - May 2, 1979, pp. 118-129. New
|
|||
|
York: ACM, 1979.
|
|||
|
|
|||
|
[SHAM84b] A. Shamir, "Identity-based cryptosystems and signature
|
|||
|
schemes," in G. R. Blakley and D. Chaum, Eds., Lecture Notes in
|
|||
|
Computer Science Vol. 196: Advances in Cryptology: Proceedings of
|
|||
|
CRYPTO 84, a Workshop on the Theory and Application of
|
|||
|
Cryptographic Techniques, Santa Barbara, CA, August 19-22, 1984,
|
|||
|
pp. 47-53. Berlin/New York: Springer-Verlag, 1985.
|
|||
|
|
|||
|
[SHAM84] A. Shamir, "A polynomial-time algorithm for breaking the
|
|||
|
basic Merkle-Hellman cryptosystem," IEEE Transactions on
|
|||
|
Information Theory, Vol. IT-30, No. 5, September 1984, pp. 699-704.
|
|||
|
|
|||
|
[SHAN90] M. Shand, P. Bertin, and J. Vuillemin, "Hardware speedups
|
|||
|
in long integer multiplication," presented at the Second ACM
|
|||
|
Symposium on Parallel Algorithms and Architectures, Crete, July 2-
|
|||
|
6, 1990.
|
|||
|
|
|||
|
[SILV87] R. D. Silverman, "The multiple polynomial quadratic
|
|||
|
sieve," Mathematics of Computation, Vol. 48, No. 177, January 1987,
|
|||
|
pp. 329-339.
|
|||
|
|
|||
|
[SIMM79] G. J. Simmons, "Symmetric and asymmetric encryption," ACM
|
|||
|
Computing Surveys, Vol. 11, No. 4, December 1979, pp. 305-330.
|
|||
|
|
|||
|
[SIMM88] G. J. Simmons, "How to ensure that data acquired to verify
|
|||
|
treaty compliance are trustworthy," Proceedings of the IEEE, Vol.
|
|||
|
76, No. 5, May 1988, pp. 621-627.
|
|||
|
|
|||
|
[SMID81] M. E. Smid, "Integrating the data encryption standard into
|
|||
|
computer networks," IEEE Transactions on Computers, Vol. COM-29,
|
|||
|
No. 6, June 1981, pp. 762-772.
|
|||
|
|
|||
|
[SMID88b] M. E. Smid and D. K. Branstad, "The Data Encryption
|
|||
|
Standard: past and future," Proceedings of the IEEE, Vol. 76, No.
|
|||
|
5, May 1988, pp. 550-559.
|
|||
|
|
|||
|
[SOLO77] R. Solovay and V. Strassen, "A fast Monte-Carlo test for
|
|||
|
primality," SIAM Journal on Computing, Vol. 6, No. 1, March 1977,
|
|||
|
pp. 84-85. Erratum: Ibid., Vol. 7, No. 1, February 1978, p. 118.
|
|||
|
|
|||
|
[STEI86] L. K. Steiner, "The ETA-10 supercomputer system," in
|
|||
|
Proceedings of the 1986 IEEE International Conference on Computer
|
|||
|
Design, Port Chester, NY, October 6-9, p. 42. Washington, DC: IEEE
|
|||
|
Computer Society Press, 1986.
|
|||
|
|
|||
|
[TANE81] A. S. Tanenbaum, Computer Networks. Englewood Cliffs, NJ:
|
|||
|
Prentice-Hall, 1981.
|
|||
|
|
|||
|
[WAGN84] N. R. Wagner and M. R. Magyarik, "A public-key
|
|||
|
cryptosystem based on the word problem," in G. R. Blakley and D.
|
|||
|
Chaum, Eds., Lecture Notes in Computer Science Vol. 196: Advances
|
|||
|
in Cryptology - Proceedings of CRYPTO 84, a Workshop on the Theory
|
|||
|
and Applications of Cryptographic Techniques, Santa Barbara, CA,
|
|||
|
August 19-22, 1984, pp. 19-36. Berlin/New York: Springer-Verlag,
|
|||
|
1985.
|
|||
|
|
|||
|
[WANG85] C. C. Wang, T. K. Truong, H. M. Shao, L. J. Deutsch, J.
|
|||
|
K. Omura, and I. S. Reed, "VLSI architectures for computing
|
|||
|
multiplications and inverses in GF(2m)," IEEE Transactions on
|
|||
|
Computers, Vol. C-34, No. 8, August 1985, pp. 709-717.
|
|||
|
|
|||
|
[WILK68] M. V. Wilkes, Time-Sharing Computer Systems. New York:
|
|||
|
Elsevier, 1968.
|
|||
|
|
|||
|
[WILL80] H. C. Williams, "A modification of the RSA public-key
|
|||
|
encryption procedure," IEEE Transactions on Information Theory,
|
|||
|
Vol. IT-26, No. 6, November 1980, pp. 726-729.
|
|||
|
|
|||
|
[WILL87] H. C. Williams and M. C. Wunderlich, "On the parallel
|
|||
|
generation of the residues for the continued fraction factoring
|
|||
|
algorithm," Mathematics of Computation, Vol. 48, No. 177, January
|
|||
|
1987, pp. 405-423.
|
|||
|
|
|||
|
[WUND83] M. C. Wunderlich, "Factoring numbers on the Massively
|
|||
|
Parallel computer," in D. Chaum, Ed., Advances in Cryptology -
|
|||
|
proceedings of CRYPTO 83, a Workshop on the Theory and Applications
|
|||
|
of Cryptographic Techniques, Santa Barbara, CA, August 22-24, 1983,
|
|||
|
pp. 87-102. New York: Plenum Press, 1984.
|
|||
|
|
|||
|
[WUND85] M. C. Wunderlich, "Implementing the continued fraction
|
|||
|
factoring algorithm on parallel machines," Mathematics of
|
|||
|
Computation, Vol. 44, No. 169, January 1985, pp. 251-260.
|
|||
|
|
|||
|
[YAO-82] A. C. Yao, "Theory and applications of trapdoor
|
|||
|
functions," in 23rd Annual Symposium on Foundations of Computer
|
|||
|
Science, Chicago, IL, November 3-5, 1982, pp. 80-91. IEEE Computer
|
|||
|
Society Press, 1982.
|