J. Cryptology (1988) 1:65-75
The Dining Cryptographers Problem:
Unconditional Sender and Recipient Untraceability
David Chaum
Centre for Mathematics and Computer Science, Kruislan 413, 1098 SJ
Amsterdam, The Netherlands
Abstract. Keeping confidential who sends which messages, in a
world where any physical transmission can be traced to its
origin, seems impossible. The solution presented here is
unconditionally or cryptographically secure, depending on whether
it is based on one-time-use keys or on public keys, respectively.
It can be adapted to address efficiently a wide variety of
practical considerations.
Key words. Untraceability, Unconditional Security, Pseudonymity.
Introduction
Three cryptographers are sitting down to dinner at their favorite
three-star restaurant. Their waiter informs them that arrangements
have been made with the maitre d'hotel for the bill to be paid
anonymously. One of the cryptographers might be paying for the dinner,
or it might have been NSA (U.S. National Security Agency). The three
cryptographers respect each other's right to make an anonymous
payment, but they wonder if NSA is paying. They resolve their
uncertainty fairly by carrying out the following protocol:
Each cryptographer flips an unbiased coin behind his menu, between
him and the cryptographer on his right, so that only the two of them can
see the outcome. Each cryptographer then states aloud whether the two
coins he can see--the one he flipped and the one his left-hand neighbor
flipped--fell on the same side or on different sides. If one of the
cryptographers is the payer, he states the opposite of what he sees. An
odd number of differences uttered at the table indicates that a
cryptographer is paying; an even number indicates that NSA is paying
(assuming that the dinner was paid for only once). Yet if a
cryptographer is paying, neither of the other two learns anything from
the utterances about which cryptographer it is.
To see why the protocol is unconditionally secure if carried out
faithfully, consider the dilemma of a cryptographer who is not the
payer and wishes to find out which cryptographer is. (If NSA pays, there
is no anonymity problem.) There are two cases. In case (1) the two
coins he sees are the same, one of the other cryptographers said
"different," and the other one said "same." If the hidden outcome was
the same as the two outcomes he sees, the cryptographer who said
"different" is the payer; if the outcome was different, the one who said
"same" is the payer. But since the hidden coin is fair, both possibilities
are equally likely. In case (2) the coins he sees are different; if both
other cryptographers said "different," then the payer is closest to the
coin that is the same as the hidden coin; if both said "same," then the
payer is closest to the coin that differs from the hidden coin. Thus, in
each subcase, a nonpaying cryptographer learns nothing about which of
the other two is paying.
The cryptographers become intrigued with the ability to make
messages public untraceably. They devise a way to do this at the table
for a statement of arbitrary length: the basic protocol is repeated over
and over; when one cryptographer wishes to make a message public, he
merely begins inverting his statements in those rounds corresponding
to 1 's in a binary coded version of his message. If he notices that his
message would collide with some other message, he may for example
wait a number of rounds chosen at random from a suitable distribution
before trying to transmit again.
1. Generalizing the Approach
During dinner, the cryptographers also consider how any number of
participants greater than one can carry out a version of the protocol.
(With two participants, only nonparticipant listeners are unable to
distinguish between the two potential senders.) Each participant has a
secret key bit in common with, say, every other participant. Each
participant outputs the sum, modulo two, of all the key bits he shares,
and if he wishes to transmit, he inverts his output. If no participant
transmits, the modulo two sum of the outputs must be zero, since every
key bit enters exactly twice; if one participant transmits, the sum
must be one. (In fact, any even number of transmitting participants
yields zero, and any odd number yields one.) For j rounds, each
participant could have a j-bit key in common with every other
participant, and the ith bit of each such key would be used only in the
ith round. Detected collision of messages leads to attempted
retransmission as described above; undetected collision results only
>from an odd number of synchronized identical message segments.
(Generalization to fields other than GF(2) is possible, but seems to
offer little practical advantage.)
Other generalizations are also considered during dinner. The
underlying assumptions are first made explicit, including modeling
key-sharing arrangements as graphs. Next, the model is illustrated
with some simple examples. The potential for cooperations of
participants to violate the security of others is then looked at. Finally,
a proof of security based on systems of linear equations is given.
1.1. Model
Each participant is assumed to have two kinds of secret: (a) the keys
shared with other participants for each round; and (b) the inversion
used in each round (i.e., a 1 if the participant inverts in that round and a
0 if not). Some or all of a participant's secrets may be given to other
participants in various forms of collusion, discussion of which is
postponed until Section 1.3. (For simplicity in exposition, the
possibility of secrets being stolen is ignored throughout.)
The remaining information about the system may be described as: (a)
who shares keys with whom; and (b) what each participant outputs
during each round (the modulo two sum of that participant's keys and
inversion). This information need not be secret to ensure
untraceability. If it is publicly known and agreed, it allows various
extensions discussed in Sections 2.5 and 2.6. The sum of all the
outputs will, of course, usually become known to all participants.
In the terminology of graphs, each participant corresponds to a
vertex and each key corresponds to an edge. An edge is incident on the
vertices corresponding to the pair of participants that shares the
corresponding key. From here on, the graph and dinner-table
terminologies will be used interchangeably. Also, without loss of
generality, it will be assumed that the graph is connected (i.e., that a
path exists between every pair of vertices), since each connected
component (i.e., each maximal connected subgraph) could be considered
a separate untraceable-sender system.
An anonymity set seen by a set of keys is the set of vertices in a
connected component of the graph formed from the original graph by
removing the edges concerned. Thus a set of keys sees one anonymity
set for each connected partition induced by removing the keys. The main
theorem of Section 1.4 is essentially that those having only the public
information and a set of keys seeing some anonymity set can learn
nothing about the members of that anonymity set except the overall
parity of their inversions. Thus, for example, any two participants
connected by at least one chain of keys unknown to an observer are both
in the same anonymity set seen by the observer's keys, and the observer
gains nothing that would help distinguish between their messages.
1.2. Some Examples
A few simple consequences of the above model may be illustrative. The
anonymity set seen by the empty set (i.e., by a nonparticipant observer)
is the set of all vertices, since the graph is assumed connected and
remains so after zero edges are removed. Also, the anonymity sets seen
by the full set of edges are all singleton sets, since each vertex's
inversion is just the sum of its output and the corresponding key bits.
If all other participants cooperate fully against one, of course no
protocol can keep that singleton's messages untraceable, since
untraceability exists only among a set of possible actors, and if the set
has only one member, its messages are traceable. For similar reasons,
if a participant believes that some subset of other participants will
fully cooperate against him, there is no need for him to have keys in
common with them.
A biconnected graph (i.e., a graph with at least two vertex-disjoint
paths between every pair of vertices) has no cut-vertices (i.e., a single
vertex whose removal partitions the graph into disjoint subgraphs). In
such a graph, the set of edges incident on a vertex v sees (apart from v)
one anonymity set containing all other vertices, since there is a path
not containing v between every pair of vertices, and thus they form a
connected subgraph excluding v; each participant acting alone learns
nothing about the contribution of other participants.
1.3. Collusion of Participants
Some participants may cooperate by pooling their keys in efforts to
trace the messages of others; such cooperation will be called collusion.
For simplicity, the possibilities for multiple collusions or for pooling
of information other than full edges will be ignored. Colluders who lie
to each other are only touched on briefly, in Section 2.6.
Consider collusion in a complete graph. A vertex is only seen as a
singleton anonymity set by the collection of all edges incident on it; all
other participants must supply the key they share with a participant in
order to determine that participant's inversions. But since a collusion
of all but one participant can always trace that participant merely by
pooling its members' inversions as already mentioned, it gains nothing
more by pooling its keys. The nonsingleton anonymity set seen by all
edges incident on a colluding set of vertices in a complete graph is the
set of all other vertices; again, a collusion yields nothing more from
pooling all its keys than from pooling all its inversions.
Now consider noncomplete graphs. A full collusion is a subset of
participants pooling all of their keys. The pooled keys see each colluder
as a singleton anonymity set; the colluders completely sacrifice the
untraceability of their own messages. If a full collusion includes a cut-
set of vertices (i.e., one whose removal partitions the graph), the
collusion becomes nontrivial because it can learn something about the
origin of messages originating outside the collusion; the noncolluding
vertices are partitioned into disjoint subgraphs, which are the
anonymity sets seen by the pooled keys.
Members of a partial collusion pool some but not all of their keys.
Unlike the members of a full collusion, each member of a partial
collusion in general has a different set of keys. For it to be nontrivial,
a partial collusion's pooled keys must include the bridges or separating
edges of a segregation or splitting of the graph (i.e., those edges whose
removal would partition the graph). Settings are easily constructed in
which the pooled keys see anonymity sets that partition the graph and
yet leave each colluder in a nonsingleton partition seen by any other
participant. Thus, colluders can join a collusion without having to make
themselves completely traceable to the collusion's other members.
1.4. Proof of Security
Consider, without loss of generality, a single round in which say some
full collusion knows some set of keys. Remove the edges known to the
collusion from the key-sharing graph and consider any particular
connected component C of the remaining graph. The vertices of C thus
form an anonymity set seen by the pooled keys.
Informally, what remains to be shown is that the only thing the
collusion learns about the members of C is the parity sum of their
inversions. This is intuitively apparent, since the inversions of the
members of C are each in effect hidden from the collusion by one or
more unknown key bits, and only the parity of the sum of these key bits
is known (to be zero). Thus the inversions are hidden by a one-time pad,
and only their parity is revealed, because only the parity of the pad is
known.
The setting is formalized as follows: the connected component C is
comprised of rn vertices and n edges. The incidence matrix M of C is
defined as usual, with the vertices labeling the rows and the edges
labeling the columns. Let K, I, and A be stochastic variables defined on
GF(2)^n, GF(2)^m, and GF(2)^m, respectively, such that
K is uniformly distributed over GF(2)^n, K and I are mutually
independent, and A = (MK) cross I. In terms of the protocol, K comprises
the keys corresponding to the edges, I consists of the inversions
corresponding to the vertices, and A is formed by the outputs of the
vertices. Notice that the parity of A (i.e., the modulo two sum of its
components) is always equal to the parity of I, since the columns of M
each have zero parity. The desired result is essentially that A reveals
no more information about I than the parity of 1. More formally:
Theorem. Let a be in GF(2)^n. For each i in GF(2)^n, which is assumed by
I with nonzero probability and which has the same parity as a, the
conditional probability that A = a given that I = i is 2^(1 - m). Hence,
the conditional probability that I = i given that A = a is the a priori
probability that I = i.
Proof. Let i be an element of GF(2)^n have the same parity as a.
Consider the system of linear equations (MK) cross i = a, in k an
element of GF(2)^n. Since the columns of M each have even parity, as
mentioned above, its rows are linearly dependent over GF(2)^m. But as a
consequence of the connectedness of the graph, every proper subset of
rows of M is linearly independent. Thus, the rank of M is m - 1, and so
each vector with zero parity can be written as a linear combination of
the columns of M. This implies that the system is solvable because i
cross a has even parity. Since the set of n column vectors of M has rank
m - 1, the system has exactly 2^(n - m + 1) solutions.
Together with the fact that K and I are mutually independent and
that K is uniformly distributed, the theorem follows easily.
2. Some Practical Considerations
After dinner, while discussing how they can continue to make
untraceable statements from this respective homes, the cryptographers
take up a variety of other topics. In particular, they consider different
ways to establish the needed keys; debate adapting the approach to
various kinds of communication networks; examine the traditional
problems of secrecy and authentication in the context of a system that
can provide essentially optimal untraceability; address denial of
service caused by malicious and devious participants; and propose
means to discourage socially undesirable messages from being sent.
2.1. Establishing Keys
One way to provide the keys needed for longer messages is for one
member of each pair to toss many coins in advance. Two identical
copies of the resulting bits are made, say each on a separate optical
disk. Supplying one such disk (which today can hold on the order of
10^10 bits) to a partner provides enough key bits to allow people to
type messages at full speed for years. If participants are not
transmitting all the time, the keys can be made to last even longer by
using a substantially slower rate when no message is being sent; the
full rate would be invoked automatically only when a 1 bit indicated
the beginning of a message. (This can also reduce the bandwidth
requirements discussed in Section 2.2.)
Another possibility is for a pair to establish a short key and use a
cryptographic pseudorandom-sequence generator to expand it as needed.
Of course this system might be broken if the generator were broken.
Cryptanalysis may be made more difficult, however, by lack of access
to the output of individual generators. Even when the cryptographers do
not exchange keys at dinner, they can safely do so later using a public-
key distribution system (first proposed by [4] and [3]).
2.2 Underlying Communication Techniques
A variety of underlying communication networks can be used, and their
topology need not be related to that of the key-sharing graph.
Communication systems based on simple cycles, called rings, are
common in local area networks. In a typical ring, each node receives
each bit and passes it round-robin to the next node. This technology is
readily adapted to the present protocols. Consider a single-bit message
like the "I paid" message originally sent at the dinner table. Each
participant exclusive-or's the bit he receives with his own output
before forwarding it to the next participant. When the bit has traveled
full circle, it is the exclusive-or sum of all the participants' outputs,
which is the desired result of the protocol. To provide these messages
to all participants, each bit is sent around a second time by the
participant at the end of the loop.
Such an adapted ring requires, on average, a fourfold increase in
bandwidth over the obvious traceable protocols in which messages
travel only halfway around on average before being taken off the ring by
their recipients. Rings differ from the dinner table in that several bit-
transmission delays may be required before all the outputs of a
particular round are known to all participants; collisions are detected
only after such delays.
Efficient use of many other practical communication techniques
requires participants to group output bits into blocks. For example, in
high-capacity broadcast systems, such as those based on coaxial cable,
surface radio, or satellites, more efficient use of channel capacity is
obtained by grouping a participant's contribution into a block about the
size of a single message (see, e.g., [5]). Use of such communication
techniques could require an increase in bandwidth on the order of the
number of participants.
In a network with one message per block, the well-known contention
protocols can be used: time is divided evenly into frames; a participant
transmits a block during one frame; if the block was garbled by
collision (presumably with another transmitted block), the participant
waits a number of frames chosen at random from some distribution
before attempting to retransmit; the participants' waiting intervals
may be adjusted on the basis of the collision rate and possibly of other
heuristics [5].
In a network with many messages per block, a first block may be
used by various anonymous senders to request a "slot reservation" in a
second block. A simple scheme would be for each anonymous sender to
invert one randomly selected bit in the first block for each slot they
wish to reserve in the second block. After the result of the first block
becomes known, the participant who caused the ith 1 bit in the first
block sends in the ith slot of the second block.
2.3. Example Key-Sharing Graphs
In large systems it may be desirable to use fewer than the m(m - 1)/2
keys required by a complete graph. If the graph is merely a cycle, then
individuals acting alone learn nothing, but any two colluders can
partition the graph, perhaps fully compromising a participant
immediately between them. Such a topology might nevertheless be
adequate in an application in which nearby participants are not likely
to collude against one another.
A different topology assumes the existence of a subset of
participants who each participant believes are sufficiently unlikely to
collude, such as participants with conflicting interests. This subset
constitutes a fully connected subgraph, and the other participants each
share a key with every member of it. Every participant is then
untraceable among all the others, unless all members of the completely
connected subset cooperate. (Such a situation is mentioned again in
Section 3.)
If many people wish to participate in an untraceable communication
system, hierarchical arrangements may offer further economy of keys.
Consider an example in which a representative from each local fully
connected subgraph is also a member of the fully connected central
subgraph. The nonrepresentative members of a local subgraph provide
the sum of their outputs to their representative. Representatives would
then add their own contributions before providing the sum to the
central subgraph. Only a local subgraph's representative, or a collusion
of representatives from all other local subgraphs, can recognize
messages as coming from the local subgraph. A collusion comprising
the representative and all but one nonrepresentative member of a local
subgraph is needed for messages to be recognized as coming from the
remaining member.
2.4. Secrecy and Authentication
What about the usual cryptologic problems of secrecy and
authentication?
A cryptographer can ensure the secrecy of an anonymous message by
encrypting the message with the intended recipient's public key. (The
message should include a hundred or so random bits to foil attempts to
confirm a guess at its content [1].) The sender can even keep the
identity of the intended recipient secret by leaving it to each recipient
to try to decrypt every message. Alternatively, a prearranged prefix
could be attached to each message so that the recipient need only
decrypt messages with recognized prefixes. To keep even the
multiplicity of a prefix's use from being revealed, a different prefix
might be used each time. New prefixes could be agreed in advance,
generated cryptographically as needed, or supplied in earlier messages.
Authentication is also quite useful in systems without identification.
Even though the messages are untraceable, they might still bear
digital signatures corresponding to public-key "digital pseudonyms"
[1]; only the untraceable owner of such a pseudonym would be able to
sign subsequent messages with it. Secure payment protocols have
elsewhere been proposed in which the payer and/or the payee might be
untraceable [2]. Other protocols have been proposed that allow
individuals known only by pseudonyms to transfer securely information
about themselves between organizations [2]. All these systems require
solutions to the sender untraceability problem, such as the solution
presented here, if they are to protect the unlinkability of pseudonyms
used to conduct transactions from home.
2.5. Disruption
Another question is how to stop participants who, accidentally or even
intentionally, disrupt the system by preventing others from sending
messages. In a sense, this problem has no solution, since any
participant can send messages continuously, thereby clogging the
channel. But nondisupters can ultimately stop disruption in a system
meeting the following requirements: (1) the key-sharing graph is
publicly agreed on; (2) each participant's outputs are publicly agreed on
in such a way that participants cannot change their output for a round
on the basis of other participants' outputs for that round; and (3) some
rounds contain inversions that would not compromise the
untraceability of any nondisrupter.
The first requirement has already been mentioned in Section 1.1,
where it was said that this information need not be secret; now it is
required that this information actually be made known to all
participants and that the participants agree on it.
The second requirement is in part that disrupters be unable (at least
with some significant probability) to change their output after hearing
other participants' outputs. Some actual channels would automatically
ensure this, such as broadcast systems in which all broadcasts are
made simultaneously on different frequencies. The remainder of the
second requirement, that the outputs be publicly agreed on, might also
be met by broadcasting. Having only channels that do not provide it
automatically, an effective way to meet the full second requirement
would be for participants to "commit" to their outputs before making
them. One way to do this is for participants to make public and agree on
some (possibly compressing and hierarchical, see Section 2.6) one-way
function of their outputs, before the outputs are made public.
The third requirement is that at least some rounds can be contested
(i.e., that all inversions can be made public) without compromising the
untraceability of non-disrupting senders. The feasibility of this will be
demonstrated here by a simple example protocol based on the slot
reservation technique already described in Section 2.2.
Suppose that each participant is always to make a single reservation
in each reserving block, whether or not he actually intends to send a
message. (Notice that, because of the "birthday paradox," the number of
bits per reserving block must be quadratic in the number of
participants.) A disrupted reserving block would then with very high
probability have Hamming weight unequal to the number of participants.
All bits of such a disrupted reserving block could be contested without
loss of untraceability for nondisrupters.
The reserved blocks can also be made to have such safely contestable
bits if participants send trap messages. To lay a trap, a participant
first chooses the index of a bit in some reserving block, a random
message, and a secret key. Then the trapper makes public an
encryption, using the secret key, of both the bit index and the random
message. Later, the trapper reserves by inverting in the round
corresponding to the bit index, and sends the random message in the
resulting reserved slot. If a disrupter is unlucky enough to have
damaged a trap message, then release of the secret key by the trapper
would cause at least one bit of the reserved slot to be contested.
With the three requirements satisfied, it remains to be shown how
if enough disrupted rounds are contested, the disrupters will be
excluded from the network.
Consider first the case of a single participant's mail computer
disrupting the network. If it tells the truth about contested key bits it
shares (or lies about an even number of bits), the disrupter implicates
itself, because its contribution to the sum is unequal to the sum of
these bits (apart from any allowed inversion). If, on the other hand, the
single disrupter lies about some odd number of shared bits, the values
it claims will differ from those claimed for the same shared bits by
the other participants sharing them. The disrupter thereby casts
suspicion on all participants, including itself, that share the disputed
bits. (It may be difficult for a disrupter to cast substantial suspicion
on a large set of participants, since all the disputed bits will be in
common with the disrupter.) Notice, however, that participants who
have been falsely accused will know that they have been--and by
whom--and should at least refuse to share bits with the disrupter in
the future.
Even with colluding multiple disrupters, at least one inversion must
be revealed as illegitimate or at least one key bit disputed, since the
parity of the outputs does not correspond to the number of legitimate
inversions. The result of such a contested round will be the removal of
at least one edge or at least one vertex from the agreed graph. Thus, if
every disruptive action has a nonzero probability of being contested,
only a bounded amount of disruption is possible before the disrupters
share no keys with anyone in the network, or before they are revealed,
and are in either case excluded from the network.
The extension presented next can demonstrate the true value of
disputed bits, and hence allows direct incrimination of disrupters.
2.6. Tracing by Consent
Antisocial use of a network can be deterred if the cooperation of most
participants makes it possible, albeit expensive, to trace any message.
If, for example, a threatening message is sent, a court might order all
participants to reveal their shared key bits for a round of the message.
The sender of the offending message might try to spread the blame,
however, by lying about some odd number of shared bits. Digital
signatures can be used to stop such blame-spreading altogether. In
principle, each party sharing a key could insist on a signature, made by
the other party sharing, for the value. of each shared bit.
Such signatures would allow for contested rounds to be fully resolved,
for accused senders to exonerate themselves, and even for colluders to
convince each other that they are pooling true keys. Unfortunately,
cooperating participants able to trace a message to its sender could
convince others of the message's origin by revealing the sender's own
signatures. A variation can prevent a participant's signatures from
being used against him in this way: instead of each member of a pair
of participants signing the same shared key bit, each signs a separate
bit, such that the sum of the signed bits is the actual shared key
bit. Signatures on such "split" key bits would still be useful in
resolving contested rounds, since if one contester of a bit shows a
signature made by the second contester, then the second would have to
reveal the corresponding signature made by the first or be thought to
be a disrupter.
In many applications it may be impractical to obtain a separate
signature on every key bit or split key bit. The overhead involved could
be greatly reduced, however, by digitally signing cryptographic
compressions of large numbers of key bits. This might of course require
that a whole block of key bits be exposed in showing a signature, but
such blocks could be padded with cryptographically generated
pseudorandom (or truly random) bits, to allow the exposure of fewer
bits per signature. The number of bits and amount of time required to
verify a signature for a single bit can be reduced further by using a
rooted tree in which each node is the one-way compression function of
all its direct descendants; only a digital signature of each participant's
root need be agreed on before use of the keys comprising the leaves.
3. Relation to Previous Work
There is another multiparty-secure sender-untraceability protocol in
the literature [1]. To facilitate comparison, it will be called a mix-net
here, while the protocol of the present work is called a dc-net. The
mix-net approach relies on the security of a true public-key system
(and possibly also of a conventional cryptosystem), and is thus at best
computationally secure; the dc-net approach can use unconditional
secrecy channels to provide an unconditionally secure untraceable-
sender system, or can use public-key distribution to provide a
computationally secure system (as described in Section 2.1).
Under some trust assumptions and channel limitations, however,
mix-nets can operate where dc-nets cannot. Suppose that a subset of
participants is trusted by every other participant not to collude and
that the bandwidth of at least some participants' channels to the
trusted subset is incapable of handling the total message traffic. Then
mix-nets may operate quite satisfactorily, but dc-nets will be unable
to protect fully each participant's untraceability. Mix-nets can also
provide recipient untraceability in this communication environment,
even though there is insufficient bandwidth for use of the broadcast
approach (mentioned in Section 2.4).
If optimal protection against collusion is to be provided and the
crypto-security of mix-nets is acceptable, a choice between mix-nets
and dc-nets may depend on the nature of the traffic. With a mail-like
system that requires only periodic deliveries, and where the average
number of messages per interval is relatively large, mix-nets may be
suitable. When messages must be delivered continually and there is no
time for batching large numbers of them, dc-nets appear preferable.
4. Conclusion
This solution to the dining cryptographers problem demonstrates that
unconditional secrecy channels can be used to construct an
unconditional sender-untraceability channel. It also shows that a
public-key distribution system can be used to construct a
computationally secure sender-untraceability channel. The approach
appears able to satisfy a wide range of practical concerns.
Acknowledgments
I am pleased to thank Jurjen Bos, Gilles Brassard, Jan-Hendrik Evertse,
and the untraceable referees for all their help in revising this article.
It is also a pleasure to thank, as in the original version that was
distributed at Crypto 84, Whitfield Diffie, Ron Rivest, and Gus Simmons
for some stimulating dinner-table conversations.
References
[1] Chaum, D., Untraceable Electronic Mail, Return Addresses, and
Digital Pseudonyms, Communications of the ACM, vol. 24, no. 2,
February 1981, pp. 84-88.
[2] Chaum, D., Security Without Identification: Transaction Systems
to Make Big Brother Obsolete, Communications of the ACM, vol. 28,
no. 10, October 1985, pp. 1030-1044.
[3] Diffie, W., and Hellman, M.E., New Directions in Cryptography, IEEE
Transactions on Information Theory, vol. 22, no. 6, November 1976,
pp. 644-654.
[4] Merkle, R.C., Secure Communication over Insecure Channels,
Communications of the ACM, vol. 21, no. 4, 1978, pp. 294-299.
[5] Tanenbaum, A.S., Computer Networks, Prentice Hall, Englewood
Cliffs, New Jersey, 1981.