Security in a Public World: A Survey

by DCE Team at Stanford

Security in a Public World: A Survey

DCE team at Stanford University

Distributed Computing Group
Stanford University
Stanford, CA 94305

February 29, 1996

Abstract

As the computing environment became more distributed, moving from several centralized time-sharing machines to hundreds of decentralized workstations, it became clear that the security of the network could not be enforced by simple techniques relying on host- based authentication, since the hosts on the network could not be trusted anymore. It became clear that some techniques would be required on the network, and that steps would have to be taken to secure privileged information traveling across the network. There are two techniques developed to deal with the issue: cryptography and authentication. Cryptography allows users to disguise data do that attackers gain no information from listening to the information as transmitted. Authentication allows clients and servers to securely determine each other*s identities. In this paper, we are going to discuss two cryptography techniques: RC4, and MD5, as well as one authentication technique: Kerberos. Finally, we are going to discuss the security system used in DCE.

1. Introduction

In an open network computing environment, a workstation cannot be trusted to identify its users correctly to network services. Many techniques have been developed to provide the different services necessary to operate large groups of computers in an efficient and secure manner. Cryptography provides that ability to send information between participants in a way that prevents others from reading it. Authentication is the process of reliably verifying the identity of someone (or something). In this paper, we are going to discuss two cryptography techniques: RC4, and MD5, as well as one authentication technique: Kerberos. After that, we are going to discuss DCE security.

2 Authentication

Authentication is the process of reliably verifying the identity of someone (or something). Authentication basically establishes who you are. There are two cases of authenticating a device across a network. One case is when a computer is authenticating another computer, such as when a print spooler wants to authenticate a printer; another case will be when a computer performs operations for a user when the user supplies a password. We are going to focus here on Kerberos, which is one of the authentication technique.

2.1 Kerberos Introduction

Kerberos was originally designed at MIT. It is based on the work by Needham and Schroeder. The first three versions of Kerberos are no longer in use and hence are not of much interest. Version 4 and Version 5, although conceptually similar, are substantially different from one another. Basically, Version 4 has a greater installed base, is simpler, and has better performance, but works only with TCP/IP networks, while Version 5 has greater functionality. Kerberos is a trusted third-party authentication service. It is trusted in the sense that each of its clients believes Kerberos* judgment as to the identity of each of its other clients to be accurate. Kerberos consists of a Key Distribution Center (KDC) that runs on a physically secure node somewhere on the network, and a library of subroutines that are used by distributed applications which want to authenticate their users. Kerberos was designed so that once the user logs into a workstation by providing the name and password, then the workstation is able to obtain information from the KDC for any process to access remote resources on behalf of the user. Because Kerberos knows these private keys, it can create messages which convince one client that another is really who it claims to be. Kerberos also generates temporary private keys, called session keys, which are given to two clients and no one else. A session key can be used to encrypt messages between two parties. Applications, including telnet and NFS, have been modified to call subroutines in the Kerberos library as part of their startup.

2.2 How Kerberos Works

Getting the Initial Ticket-Granting Ticket

* When a user walks up to a workstation, she/he is prompted for her/his username. Once it has been entered, a request is sent to the authentication server containing the user*s name requesting the ticket-granting service.

* The authentication server checks whether it knows about the user. If so, it generates a random session key and put it together with a ticket for the ticket-granting server containing the client*s name, the name of the ticket-granting server, the current time, the lifetime of the ticket, the client*s IP address all inside a new ticket. This new ticket, known as the ticket-granting ticket, is encrypted in a key known only to the ticket-granting server and the authentication server.

* The authentication server then sends the ticket, along with another copy of the random session key, and some other information, back to the client. This response is known only to Kerberos authentication server and the client, which is actually derived from the user*s password.

* The user is asked for her/his password once the response is received by the client. The password is converted to a DES key and used to decrypt the response. The user*s password and the DES key are erased from memory after this.

* Now, the workstation has all the information it needs to prove the identity of the user for the lifetime of the ticket-granting ticket.

Requesting Service Server Ticket

* In order to gain access to a service server, the application needs to build an authenticator which contains the client*s name and IP address, and the current time. The authenticator is then encrypted in the session key received with the ticket-granting ticket. The client workstation then sends the authenticator to the KDC proving that the client knows the session key.

* The KDC decrypts the ticket and checks the expiration time in the TGT. If the TGT is valid, the KDC constructs a new session key to be shared by the client and the service server. The KDC then constructs a new ticket that contains this new session key, the name of the client, and an expiration time, all encrypted in the service server*s key. The KDC then sends this ticket, together with a copy of the new session key, and the service server*s name back to the client. As you can imagine, the whole thing is encrypted with the original session key know to the client so that only the client can decrypt this message.

* The client decrypts the ticket and discovers the new session key and the service server name. The client now assumes that anyone with knowledge of the new session key is acting on the service server*s behalf.

* The client will still save the original session key received with the ticket-granting ticket so that it can use it later again to request a ticket that has not already been requested. If it is the case, it simply repeats the steps of this section.

Mutual Authentication

* If the client specifies that it wants the server to prove its identity too, the server adds one to the timestamp it decrypted from the authenticator, encrypts the result in the new session key, and sends the result back to the client. It is assumed that clocks are synchronized to within several minutes. If the time in the request in the decrypted authenticator is close to current (say, within 5 minutes), then it is ensured that this is not a replay of some earlier request. In order to make sure that it is not a replay, the service server should keep all timestamps it receives recently (in the last five minutes) that are still valid. In this way, the service server will discard any request with the same ticket and timestamp because this maybe sent by an attacker. Any request older than five minutes (or whatever the value of the maximum allowable timestamp) would be rejected anyway. At the end of all these, the service is certain that, according to Kerberos, the client is who it says it is. If mutual authentication occurs, the client is also convinced that the server is authentic. Moreover, the client and server share a key which no one else knows, and can safely assume that a reasonably recent message (less than the maximum allowable timestamp) encrypted in that key originated with the other party.

2.1.2 Differences between V4 and V5

Kerberos V5 represents a major overhaul of Version 4. While the basic philosophy remains the same, there are major changes to the encoding and major extensions to the functionality. The basic motivation behind the changes in Kerberos V5 is to allow greater flexibility. The followings are some of the differences between V4 and V5.

Names

In Kerberos V4, a principal is named by the three fields NAME, INSTANCE. and REALM, which must each be a null-terminated text string up to 40 characters long (including the null). The size of these fields is too short for some environments, and certain character (e.g. *.*_ are illegal inside the strings but required for account names on some systems. In V5, there are two components: the REALM and the NAME. The NAME component contains a type and a varying number of arbitrary strings, so the purpose served by the V4 INSTANCE field is accomplished by using an extra string in the NAME component. In V4, REALMs are DNS standard names, whereas in V5 they can be DNS standard names or X.500 names, and the syntax allows for other name types as well.

Delegation

Delegation of rights is the ability to give someone else access to things you are authorized to access. Delegation can be limited in time, or limited in scope. Of course, one way delegation could be possible is for a principal (principal A) to send another user (principal B) the master key, allowing that B to obtain tickets to whatever resources B needs on A*s behalf. That is clearly not desirable, even if they key is encrypted when A sent to B, because it will allow B to forever be able to impersonate A. Other options include if A knows what particular resources B will need to access, A can obtain tickets for those resources in advance and send B the tickets and keys. Or if A can give B the TGT and session key, which B can use to obtain specific tickets on A*s behalf as necessary. These mechanisms are inconvenient and insecure. Moreover, they wouldn*t work with Kerberos because the ticket contains a network layer address, and Kerberos insists that a ticket must be used from the specified network layer address. Kerberos V5 explicitly allows delegation by allowing A to ask for a TGT with a different network layer address, while in V4, the network layer address in the ticket is the address from which the ticket was requested. As a result, V5 allows A to specify multiple addresses to include (in which case the ticket can be used from any of the specified addresses), or allows A to request that no address be included (in which case the ticket can be used from any address). In V4, a client can specifically request a new TGT from the KDC for B so that B*s network layer address is in the TGT instead. But then, the new TGT is not useable by A directly. So, V5 solves the problem, but not everyone agrees that the KDC can issue tickets with no specified address and a server can accept such tickets are necessary a good thing to do. Because it is not universal agreement that allowing delegation is always a good idea, Kerberos V5 makes it optional by a bit in the TGT. Both the KDC and applications can turn that bit off if they do not want to have delegation.

Ticket Lifetimes

In V4, the maximum lifetime of a ticket was about 21 hours. This was too short for some applications. In V5, tickets can be issued with virtually unlimited lifetimes the farthest in the future that can be specified with a V5 timestamp is Dec 31, 9999. Long-lived tickets pose very serious security risks, because once created they cannot be revoked (except invalidating the master key of the service to which the ticket was granted). Therefore V5 provides other mechanisms to implement revocable long-lived tickets. These mechanisms include renewable tickets, and postdated tickets. However, in order to support renewable ticket and postdated tickets, the KDC needs to keep track of multiple keys for service servers in V5, while in V4, the KDC did not keep track of more than one key for each service server. If a client has a renewable ticket to a server, and the server changed the key since the ticket was originally issued, the KDC needs to be able to decrypt the ticket, and when it renews the ticket, it will renew it with the most recent key for the server.

Master Keys in Different Realms

In V5, the password-to-key conversion hash function uses the realm name. This means that the function, given the same password, will come up with a different master key if the name of the realm is different. This can help in the case when a user has chosen a good password and an intruder manages to steal a KDC database from some realm. stealing that database will allow the intruder to impersonate A in that realm, but not to impersonate A in any other realms for which she is using the same password. Note that this does not protect against an intruder if the intruder can manage to obtain A*s password. In that case, the intruder can impersonate A in other realms for which A is using the same password.

Cryptographic algorithm

Kerberos V4 assumes DES is the encryption algorithm. While DES is not secure enough for high-security environments, on the other hand, it is considered by the U.S. government to be too secure to export. Kerberos V5 is designed in a modular way which allows insertion of different encryption algorithms. Since different encryption systems use different-length keys, and some encryption systems allow variable-length keys, in V5 keys are tagged with a type and length.

Hierarchy of Realms

In Kerberos V4, in order for principals in realm A to be authenticated by principals in realm B, it was necessary for B*s KDC to be registered as a principal in A*s KDC. For full connectivity, this means that if there are n realms, the KDC in each realm has to be registered as a principal in each of the other n-1 realms. In Kerberos V5, it is allowable to go through a series of realms in order to authenticate. For example, a principal in realm A might wish to be authenticated by a principal in realm C. However, realm C might not be registered in A. But perhaps realm B is registered in A, and realm C is registered in B. A principal in A can get a ticket for something in C by first getting a ticket for B, and then asking B for a ticket to the KDC in C.

Preventing Password-Guessing Attacks

With Kerberos V4, there is no authentication of the request to the KDC for a TGT. Anyone can send a clear text message to the KDC requesting a TGT for user A, and the KDC will send back a ticket, encrypted according to A*s master key. Since the function that maps a password sting to a DES key is publicly known, an intruder can use the encrypted credentials for an off-line password-guessing attack to find A*s password. To avoid this attack, a mechanism has been added to Kerberos V5 information known as preauthentication data, which proves that the requester knew the user's master key. The preauthentication data consists of a current timestamp encrypted with the user's master key. There's another opportunity for password guessing. An attacker can use her/his own TGT or master key to ask for a ticket to another principal. She/he will get back the ticket which is encrypted according to the principal's master key. Then she/he can use an off- line password-guessing attack to find the principal's password. Kerberos prevents this attack by marking database entries for human users, with a flag indicating that the KDC should not issue a ticket to this principal.

ASN.1

Kerberos V5 uses ASN.1 syntax, which is a data representation language standardized by ISO. It gives people a way to precisely define data structures without worrying about different data representations, such as bit and byte order, on different machines. However, this flexibility also leads to a lot of overhead in bytes on the wire, and increases the complexity of the code.

Other Optimizations There were some fields in Kerberos V4 that were not necessary and were taken out in V5 because encryption is expensive especially when done in software), so it is undesirable to unnecessarily encrypt information. One example of such fields is the target ticket name.

3 DCE Security

DCE stands for Distributed Computing Environment. It is an OSF product. DCE security has been incorporated into a number of products from a variety of vendors. DCE security is conceptually similar to Kerberos, and indeed uses Kerberos V5 as one of its components. DCE has a modular design. Kerberos V5 is used for authentication although alternative mechanisms can in principle be substituted. Authentication, authorization, and encryption mechanisms are architecturally separate. Recall that Kerberos uses KDCs and Ticket Granting Servers, and they share the same database and same keys. DCE adds Privilege Servers and Registration Servers. Privilege Servers and Registration servers are on-line trusted entities, like KDCs. The purpose of a Privilege Server is to get the principal*s UUID (universal unique ID), and the groups to which that principal belongs, to be included in a Kerberos ticket in a secure way. The purpose of a Registration Server is to provide a combined database for a KDC and corresponding Privilege Server. The KDC uses a master key for each principal while the Privilege Server uses, for each principal, a UUID and the set of groups to which that principal belongs. In Kerberos the principal's name is in a ticket, and Kerberos gives no help in translating from name to UID or in looking up the set of GIDs associated with a principal. Furthermore, Kerberos does not standardize UIDs and GIDs. Different platforms have different forms of UID and GID. DCE standardizes group and user UUIDs at 128 bits long and standardizes DCE ACLs containing those UUIDs. Additionally, DCE does the translation from name to UUID, which is convenient for the applications but makes it difficult for them to use the native ACL format with DCE. A UUID in an ACL can belong to either a principal or a group.

3.1 How DCE Security Works

Getting the Initial Ticket-Granting Ticket

* With DCE, a user logs in just like in Kerberos. The user's workstation gets an ordinary Kerberos TGT with the user's name inside. The workstation then requests a ticket to the Privilege Server, which to the KDC is just another principal in the realm. The Privilege Server extracts the user's name from the ticket, looks up the user's UUID and group membership, and requests a Privilege Ticket Granting Ticket (PTGT) which has the Privilege Server's name, the user's UUID and group membership. The Privilege Server then sends to the user's workstation the PTGT, and the corresponding session key (the one encrypted inside the PTGT) in an encrypted message. Note that the above description is architectural * since the Privilege Server and KDC are packaged together, the messages between them may not actually occur.

Requesting Service Server Ticket

* When the user asks to talk to a server. The workstation sends the PTGT to the KDC, along with the request for a ticket to the server. The KDC will return to the user a ticket to the server with the user's UUID and group membership (obtained from the PTGT), as well as the Privilege Server's name. Note that the ticket does not contain the user's name since ACLs list the user's UUID or group UUIDs. The user will then send this ticket to the application server. The privilege information of the client in the PTGT is also known as the Privilege Attribute Certificate (PAC).

* The DCE application server will check if the Privilege Server's name is in the ticket. If not, it will refuse to honor this ticket. If the Privilege's name is in the ticket, the server can assure that the UUID and group information for the user in the ticket is correct. The server then checks the UUID and group information against the ACL of the resource the user is asking to use.

* Now, the server knows that the client is a properly authenticated principal whose authorization is described by the PAC. Furthermore, both the client and the server now have a conversation key that they can use for further communications.

Mutual Authentication

* If the client specifies that it wants the server to prove its identity too, the server will sends back a message encrypted with the session key. Since this key was in the ticket that was encrypted using the server's secret key, the fact that the server possesses the right session key is proof that the server is the intended principal. Once the user and the server have mutually authenticated, DCE does not use the Kerberos integrity-protected or encrypted data exchanges. Instead, DCE has its own mechanisms for integrity protection, or integrity together with security within the RPC protocol, using the session key Kerberos provides. As with Kerberos V5, DCE allows multiple different cryptographic algorithms, but today DCE uses MD5 and DES.

4 RSA

RSA is named after its inventors, Rivest, Shamir, and Adleman. It is a public key cryptographic algorithm. One feature of RSA is that the key length can be variable. Anyone using RSA can choose a long key for enhanced security, or a short key for efficiency. The block size in RSA is also variable. Block size is the size of the chunk of data to be encrypted. The plaintext block must be smaller than the key length. The ciphertext block will be the length of the key. Therefore, RSA is much slower to compute than other secret key algorithms, such as DES. As a result, RSA does not tend to get used for encrypting long messages Mostly it is used to encrypt a secret key, which is used to actually encrypt the message. The basic algorithm is to generate two large primes p and q. Multiply them together, and get the result n. The factors p and q will remin secret. A private key and a public key will be generated from p, q, and n. We don't know for sure that RSA is secure. However, a lot of people have been trying to figure out how to break RSA, and they haven't come up with anything yet. The real premise behind RSA's security is the assumption that factoring a big number is hard. The best known factoring methods are really slow. To factor a 512-bit number with the best known techniques would take about a half million MIPS- years. However, we do not know that factoring is the only way of breaking RSA. We know that breaking RSA is no more difficult than factoring, but there might be some other means of breaking RSA.

5.1 Introduction to Hashes and Message Digests

A hash or a message digest is a one-way function. It is a one- way function because it takes an input message and produces an output and it is not practical to figure out the what input resulted in what ouptut. Also the function may produce a one-to-many mapping between the input and the ouput, hence given the output, it may not be possible to determine the input. A hash of a message m is h(m) if it satisfies the following properties:

* For any message m, it is relatively easy to compute h(m) . This just means that in order to be practical it can't take a lot of processing time to compute the hash.

* Given h(m) , there is no way to find an m that hashes to h(m) in a way that is substantially easier than going through all possible values of m and computing h(m) for each one.

* Even though it's obvious that many different values of m will be transformed to the same value h(m) (because there are many possible values of m ), it is computationally infeasible to find two values that hash to the same thing. [Kaufman, p.53]

5.2 MD4

MD4 is an example of a message digest. MD4 was designed to be 32- bit word-oriented so that it can be computed faster on 32-bit CPUs. MD4 can handle messges with an arbitrary number of bits. It can be computed in a single-pass over the data.

5.2.1 MD4 Padding

The message to be fed into the message digest computation must be a multiple of 512-bytes (sixteen 32-bit words). The original message is padded by adding a 1 bit, followed by enough 0 bits to leave the message 64 bits less than a multiple of 512 bits. Then a 64-bit quantity representing number of bits in the unpadded message, mod 264, is appended to the message.

5.2.2 MD4 Message Digest Computation

The message digest to be computed is a 128-bit quantity (32-bit words). The message is processed in 512-bit (sixteen 32-bit words) blocks. The message digest is initialized to a fixed value, and then each stage of the message digest computation takes the current value of the message digest and modifies it using the next block of the message. The final result is the message digest for the entire message. Each stage makes three passes over the message block. Each pass has a slightly different method of mangling the message digest. At the end of the stage, each word of the mangled message digest is added to its pre-stage value to produce the post-stage value (which becomes the pre-stage value for the next stage). Therefore, the current value of the message digest must be saved at the beginning of the stage so that it can be added in at the end of the stage.

5.3 MD5

MD5 is more conservative than MD4 in the sense that MD5 is more concerned with security than speed. It is very similar to MD4, the differences are as follows:

1. MD4 makes three passes over each 16-byte chunk of the message. MD5 on the other hand makes 4 passes instead of 3 over the 16-byte chunk.

2. The functions are slightly different and also the number of bit shifts is different. 3. MD4 has one constant that is used for each message word in pass 2, and a different constant used for for all the 16 message words in pass

3. No constant is used in pass 1. MD5 uses a different constant for each message word on each pass. Since there are 4 passes, each of which deals with 16 message words, there are 64 32-bit constants used in MD-5.

5.3.1 MD5 Message Padding

The padding in MD5 is the same as the padding in MD4 MD5 Message Digest Computation The message digest processing is done the same way it is done in MD4 that is the message is processed in 512-bit (sixteen 32-bit words). The message digest is a 128-bit quantity. Each stage computes a function based on the 512-bit message chunk and the message digest which results in a value which is passed onto the next stage. The value resulting from the final stage is the final message digest. Each stage in MD5 makes 4 passes over the message block (compared with 3 for MD4). As in MD4, the value resulting from the function applied to the 512-bit chunk is added to the message digest value obtained from the last stage with there being an intial starting value.

6 RC 5

RC5 is an encryption algorithm which provides fast symmetric block ciphering suitable for hardware or software implemtation. RC5 has a variable word size, a variable number of rounds, and a variable- length secret key.

6.1 RC5 Algorithm The RC5 algorithm consists of three components: a key expansion alogritm, an encryption algorithm, and a decryption algorithm. The plaintext input to RC5 consists of two w-bit words, which we denote A and B. RC5 uses an expanded key table, S[0...t-1], consisting of t = 2(r+1) w-bit words. The key-expansion algorithm initalizes S from the user's given secret key parameter K. The algorithm assumes standard little-endian conventions for packing bytes into input / output blocks: the first byte occupies the low-order bit positions of register A, and so on, so that the fourth byte occupies the high-order bit positions in A, the fifth byte occupies the low-order bit positions in B, and the eighth (last) byte occupies the high-order bit positions in B.

6.1.2 Encryption

The algorithm assumes that the input given in two w-bit registers A and B. It also assumes that the key-expansion has already been performed, so that the array S[0...t-1] has been computed. The pseudo-code is as follows: A = A + S[0]; B = B + S[1]; for i = 1 to r do A = ((A XOR B) <<< B) + S[2 * i]; B = ((B XOR A) <<< A) + S[2*i +1]; The output is in registers A and B.

6.1.2 Decryption

The decryption routine can be derived from the encryption routine for i = r downto 1 do B = ((B - S[2*i + 1]) >>> A) XOR A; A = ((A - S[2*i]) >>> B) XOR B; B = B - S[1]; A = A - S[0];

6.1.3 Key Expansion The key expansion routine expands the user's secret key K to fill the expanded key array S, so that S resembles an array of t = 2(r+1) random binary words determined by K. The key expansion algorithm uses two "magic constants", and consists of three simple algorithmic parts. Definition of the Magic Constants The key-expansion algorithm uses two word-sized binary constants Pw and Qw. They are defined for arbitrary w as follows: Pw = Odd((e-2)2w) Qw = Odd((p - 1)2w) where e = 2.718281828459 ... (base of natural logarithms) p = 1.618033988749... (golden ratio), and where Odd(x) is the odd integer nearest to x (rounded up if x is an even integer) Converting the Secret Key from Bytes to Words. The first algorithmic step of key expansion is to copy the secret key K[0...b-1] into an array L[0...c-1] of c = ceiling(b/u) words, where u = w/8 is the number of bytes/word. This operation is done in a natural manner, using u consecutive key bytes of K to fill up each successive word in L, low-order byte to high-order byte. Any unfilled positions of L are zeroed out. Initializing the Array S. The second algorithmic step of key expansion is to initialize array S to a particular fixed (key- independent) pseudo-random bit pattern, using an arithmetic progression modulo 2w determined by the "magic constants" Pw and Qw . Since Qw is odd, the arithmetic progression has period 2w. Mixing in the Secret Key. The third step of key expansion is to mix the user's secret key in three passes over the arrays S and L. More precisely, due to the potentially different sizes of S and L, the larger array will be processed three times, and the other may be handled more times. The key-expansion function has a certain amount of "one-wayness": it is not so easy to determine K from S.

7 DES

DES is based on the on an algorithm known as Lucifer cipher designed by IBM. DES uses a 56-bit key, and maps a 64-bit input block into a 64-bit output block. Although the key looks like a 64- bit, only 7-bit in each of the 8 bytes is used since 1-bit is used for odd parity on each byte. The issue of key length is a very important one since advances in chip speeds have made key breaking by a bit of cleverness and exhaustive search easier.

7.1.1 Principle behind DES The 64-bit input is subjected to an intial permutation to obtain a 64- bit result (which is just the input bits shuffled). The 56-bit key is used to generate sixteen 48-bit per-round keys, by taking a different 48-bit subset of the 56 bits for each of the keys. Each round takes as input the 64-bit output of the previous round, and the 48-bit per- round key, and produces a 64-bit output. After the 16th round, the 64-bit output is subjected to another permutation, which happens to be the inverse of the intial permutation Decryption works by running DES backwards. To decrypt a block, you'd first run it through the intial permutation to undo the final permutation (the intial and the final permutations are inverses of each other). You'd do the same key generation, though you'd use the keys in the opposite order. After 16 rounds of decryption, the output will be subjected to the final permutation (to undo the intial permutation).

8 Diffie-Hellman

The Diffie-Hellman public key cryptosystem predates RSA and is in fact the oldest public key system still in use. It is less general than RSA (it does neither encryption nor signatures) but offers better performance for what it does. Diffie-Hellman allows two-individuals to agree on a shared key, even though they can exchange messages in public. Let us say that A and B want to have a secret number that they can start encrypting messages to each other and the only way they can do this is in public. The Diffie-Hellman algorithm has limited functionality since only outcome of it is that A and B get a secret number which they can use to encrpt messages using conventional cryptography. Neither A nor B start out with any secrets, yet after the exchange of two messages that may even be public, they will know a secret key. To start out there are numbers p , a prime which is about 512-bits and g which is a number less than p. p and g are known beforehand and can be publicly known. Once there is a mutually agreed upon p and g, both A and B choose a 512-bit number at random and keeps it a secret. Let A's secret number be As and B's secret number be Bs. Each raises g to their secret number, mod p. The result is that A computes some number Ta and B computes Tb. They exchange their respective values of T. Each raises the recieved T to their secret number. They will come up with the same number.

9 Acknowledgments

We would like to thank Brian Schimpf and David Ortmeyer of Gradient Technologies for recommending reference sources.

11 References

[1] J. G. Steiner, "Kerberos: An Authentication Service for Open Network Systems", March, 1988.

[2] C. Kaufman, R. Perlman, M. Speciner, "Network Security: Private Communication in a Public World", PTR Prentice Hall, 1995.

[3] "OSF DCE Application Development Guide Core Components, Revision 1.1", Open Software Foundation, 1994.

[4] J. Shirley, W. Hu, and D. Magid, "Guide to Writing DCE Applications", Second Edition, O'Reilly & Associates, Inc., 1994.