Basics of Cryptography and
Applications for Windows NT

Cryptography is the science of writing in secret code and its use dates back at least 3900 years. Cryptography is required for data and telecommunications, especially distributed network applications and electronic commerce (e-commerce), when communicating over any untrusted medium, which includes just about any network, ranging from simple NT domains to the Internet.

Cryptography provides a set of specific security requirements necessary for client/server and application-to-application communication, namely:

• Authentication: The process of proving one's identity.
• Privacy/confidentiality: Ensuring that no one can read the message except the intended receiver.
• Message integrity: Assuring the receiver that the received message has not been altered in any way from the original.
• Non-repudiation: A mechanism to prove that the sender really sent this message.

This article will present the different general types of cryptographic methods. Specific crypto algorithms, in a context of the Windows NT operating system family (NT 4.0, and 5.0/2000) will also be described.

Cryptography can be used for many applications, such as user authentication and protecting data from theft or alteration. One way of classifying cryptographic algorithms is by the number of keys employed for encryption and decryption (Figure 1):

• Secret Key Cryptography: Uses a single key for both encryption and decryption
• Public Key Cryptography: Uses two keys; one for encryption and another for decryption
• Hash Functions: Uses a mathematical transformation to irreversibly "encrypt" information

FIGURE 1. Three types of cryptography. A) secret key, B) public-key, and C) hash function.

In SKC, a single key is used for both encryption and decryption (Figure 1A). The sender uses the key to encrypt some plaintext and sends the ciphertext to the receiver. The receiver applies the same key to decrypt the ciphertext and recover the original message. This method is also called symmetric encryption.

In SKC, the key must be known by both the sender and the receiver; that, in fact, is the secret implied by the name. The biggest challenge with SKC is the secure distribution of the key.

Assuming that the algorithm itself is good, the real strength of a SKC system lies in the length of the key. When compute power was relatively limited, the only reasonable way to attack a cryptosystem was by breaking the algorithm. As computers continue to get fast and cheap, brute force attacks — where an attacker tests every possible key combination — become increasingly affordable even to the hacker on a budget (not to mention a corporation or a government with significant resources). The only way, then, to stave off a brute force attack is by using large keys that make these computational attacks infeasible. It is generally believed that a 90-100 bit key for SKC will be adequate for at least the next 10 years or so.

The most commonly used SKC scheme today is the Data Encryption Standard (DES), designed by IBM in the 1970s and subsequently adopted by the U.S. Government. DES uses a 56-bit key and encrypts 64-bit blocks of data at one time, using a complex set of rules and transformations that were designed specifically to yield fast hardware implementations and slow software implementations (although this latter point is becoming less significant today). It has always been of interest that IBM also proposed a 128-bit key for DES, which was rejected at the time by the government.

Many experts in the crypto community have claimed for years that DES was no longer sufficient to protect government, financial, medical, and other critical information. And in July 1998, the Electronic Frontier Foundation (EFF) announced the construction of a $220,000 hardware device that could find a DES key in an average of 4.5 days using brute force methods. Soon thereafter, the U.S. Government recommended that new DES implementations use a called Triple DES (3DES), which employs three DES encryption/decryption steps and one, two, or three 56-bit keys (for a possible effective key length of 168 bits).

There are many other SKC algorithms in use today, including a series of algorithms developed by Ron Rivest and called Rivest Ciphers (or Ron's Code, but abbreviated "RC" in either case). RC2, designed to replace DES, operates on 64-bit blocks and uses a variable-size key. Although it's code has not been made public, many companies — including Microsoft — have licensed RC2 for use in their products. RC4, which also uses variable-sized keys, is called a stream cipher because a feedback mechanism in the algorithm ensures that a given block of data that appears in two different bit streams will be encrypted differently. RC4 is widely used in commercial cryptography products, although it can only be exported from North America using keys that are relatively short, such as 40 or 56 bits in length.

The U.S. Government has been looking for an official successor to DES since 1997. This process will result in adoption of the Advanced Encryption Standard (AES) and a selection should be made by the end of 2000.

Public-Key Cryptography (PKC)

PKC was first described publicly in 1976 by Stanford University professor Martin Hellman and graduate student Whitfield Diffie. The Diffie-Hellman scheme solves the key exchange problem inherent with SKC and employs two keys, one to encrypt the plaintext and the other to decrypt the ciphertext (Figure 1B). RSA, the first implementation of this scheme, came a year later from MIT mathematicians Ronald Rivest, Adi Shamir, and Leonard Adleman.

There are two important points to note about the two keys in PKC. First, it does not matter which key is applied first; one key encrypts and the other key is needed to decrypt. Second, although the two keys are mathematically related, it is infeasible to determine the second key merely by knowing the first. Because a pair of keys are required, this approach is also called asymmetric cryptography.

In PKC, one of the keys is designated the public key and is advertised as widely as the owner wants. The other key is designated the private key and is kept secret. When sending a message, the sender encrypts information using the receiver's public key; the receiver then decrypts the ciphertext using their private key.

RSA, still the most common PKC implementation today, is used in hundreds of software products primarily for key exchange. RSA uses a variable size encryption block and a variable size key, usually up to 1024 or 2048 bits in length. The key-pair is derived from a very large number, n, that is the product of two prime numbers chosen according to special rules; these primes may be 100 or more digits in length each, yielding an n with roughly twice as many digits as the prime factors. This is important; as computers get better and better at finding the prime factors of large numbers, the safety of RSA is maintained by merely staying ahead of the curve and choosing a very large number of digits in n. The public key information includes n and a derivative of one of the factors of n; an attacker cannot determine the prime factors of n (and, therefore, the private key) from this information alone and that is what makes RSA so secure.

Hash Functions

Hash functions, also called message digests and one-way encryption, are algorithms that, in essence, use no key (Figure 1C). Instead, they operate on the plaintext mathematically so that the content and length of the original message are not recoverable. Furthermore, it is unlikely that two different plaintext strings will yield the same hash value.

Hash algorithms are typically used to provide a digital fingerprint of a file's contents, often used to ensure that the file has not been altered by an intruder or virus. Hash functions are also commonly employed by many operating systems to encrypt passwords.

Among the most common hash functions in use today in commercial cryptographic applications are a family of Message Digest (MD) algorithms, all of which are byte-oriented schemes that produce a 128-bit hash value from an arbitrary-length message. Two MD algorithms are of particular importance, both developed by Rivest. MD4, described in Request for Comments (RFC) 1320, was designed specifically for fast processing in software and to use a small amount of memory. MD5 (RFC 1321) was developed after potential weaknesses were reported in MD4; this scheme is similar to MD4 but is slower because more manipulation is made to the original data. (MD5 itself was shown to have several weaknesses in 1996.)

Another hash code seeing increased use in commercial products is the Secure Hash Algorithm (SHA), developed by the U.S. National Institute for Standards and Technology (NIST). SHA produces a 160-bit hash value.

A side comment about terminology is in order here. Hashes originated in computer science as an efficient way of sorting and performing table lookups in compilers and operating systems. Note then, that all references to "hashes" are not necessarily references to cryptography. Consider, for example, Microsoft's Proxy Server, which employs the Cache Array Routing Protocol (CARP) to determine which proxy server in an array has cached a particular Web page. The description of CARP says that a Web page is stored by performing a hash of the proxy server array machine names, the protocol, and the domain name of the URL, followed by some relatively trivial mathematical operations. This use of a hash is to quickly locate the page and is, therefore, built for speed rather than irreversibility and cryptography.

Why Do We Need Three Encryption Techniques?

The fact that there are so many methods for cryptography is often a point of confusion. Why not just do all the cryptography that we need with just one method? The answer lies in the fact that each scheme is optimized for some specific application(s):

• Hash functions are well-suited for ensuring data integrity because any change made to the contents of a message will result in the receiver calculating a different hash value than the one placed in the transmission by the sender.
• Secret key cryptography is ideally suited for encrypting messages. The sender can generate a session key on a per-message basis to encrypt the message; the receiver, of course, needs the same session key to decrypt the message.
• Key exchange, of course, is the primary application of public-key cryptography. Asymmetric schemes can also be used for non-repudiation; if the receiver can obtain the session key encrypted with the sender's private key, then only this sender could have sent the message. PKC could, theoretically, also be used to encrypt data although this is rarely done because SKC encryption is about 1000 times faster than PKC.

FIGURE 2. Sample application of the three cryptographic techniques for secure communication.

Figure 2 puts all of this together and shows, conceptually, how all of these cryptographic functions can be combined for secure, private, authenticated communication between two users, Alice and Bob. Alice uses SKC to encrypt her message using her randomly generated session key. She then encrypts the session key using Bob's public key. The encrypted message and encrypted session key together form the digital envelope. Upon receipt, Bob recovers the session secret key using his private key and then decrypts the encrypted message.

The digital signature assures Bob that Alice really sent this message and that the message wasn't changed. Alice computes the hash value of her message and then encrypts the hash value with her private key. Upon receipt of the digital signature, Bob recovers the hash value calculated by Alice by decrypting the digital signature with Alice's public key. Bob then calculates the hash value of the message. If Bob's calculated hash value is different than the value supplied by Alice, then Bob knows that the message has been altered; if the hash values are the same, Bob will believe that this message is identical to the one that Alice sent. The matching hash value also proves that Alice must have sent this message because only she could have encrypted a value with her private key.

Key Distribution and Trust

The cryptographic methods described above do not exist in a vacuum but within a somewhat larger framework of secure communicating systems. Two such frameworks are particularly relevant to Windows NT, namely Kerberos and public-key certificates. Both rely on trusted third-parties.

The first framework, Kerberos, was developed at MIT and is a commonly used authentication scheme on the Internet. Named for the three-headed dog who, according to Greek mythology, guards the entrance of Hades (rather than the exit!), Kerberos uses a client/server architecture to provide user-to-server authentication, where every host on the network has its own secret key. Since it would be impossible and unmanageable for every host to have a list of the keys of all other hosts, a trusted third-party known as a Key Distribution Center (KDC) is given the task of managing the keys for all of the hosts within a given realm. In this way, when a new node comes online, only the KDC and the new node need to be configured with the node's key.

FIGURE 3: Kerberos architecture.

Kerberos works via two servers known as the Authentication Server (AS) and Ticket-Granting Server (TGS), as shown in Figure 3. When an application client establishes an authenticated session to a server, the lines of communication run as follows:

1. The client's Kerberos software establishes a connection with the Kerberos AS, which authenticates the client. The AS then provides the client with a secret key for this login session and a ticket-granting ticket (TGT), which gives the client permission to talk to the TGS. The ticket has a finite lifetime so that the authentication process is repeated periodically.
   
   
2. The client communicates with the TGS to obtain the Application Server's key so that a connection to the service can be established. The client supplies the TGS with the login session key and TGT; the TGS responds with an application session key and an encrypted form of the Application Server's secret key; this secret key is never sent on the network in any other form.
   
   
3. The client has now authenticated itself and can prove its identity to the Application Server by supplying the Kerberos ticket, application session key, and encrypted Application Server secret key. The Application Server responds with similarly encrypted information to authenticate itself to the client. At this point, the client can connect to the intended service (e.g., e-mail, HTTP, or e-commerce transaction).

Kerberos version 5 (V5), described in RFC 1510, is the most common version used today. Kerberos is a very effective key sharing/distribution scheme and it is very scalable. One limitation, though, is that the Kerberos server must have prior knowledge of all client systems before any transactions can occur, which makes it potentially infeasible for the client/server relationships commonly seen in e-commerce.

The second framework uses public-key certificates to support the use of PKC and to provide a more global method so that users can prove their identity. PKC is ideal for e-commerce applications because a user merely shows up at a Web site and can obtain the server's public key, which can now be used to SKC key exchange for secure communication. But how do we build the trust relationship between a client and server who may have never had any a priori contact? How does a recipient determine if a public key really belongs to the sender? How does the recipient know that the sender is using the public key for a legitimate purpose for which there is appropriate authorization? When does a public key expire? How can a key be revoked in case of compromise or loss?

A certificate is a digital document containing a user's public key, authentication for that key, and other information about the user. A certificate is issued by a certification authority (CA). The recipient of the certificate has to trust the issuing CA, of course, before accepting the public key and that trust is aided because CAs themselves have certificates, eventually leading back to a trusted root CA. This is called a certificate chain.

The basic concepts of certificates and certificate chains are familiar to all of us. My driver's license, for example, was issued by the state of Vermont and says that I am allowed to drive certain types of motor vehicles, need corrective lenses, and am an organ donor. All states in the U.S. accept my license because they recognize Vermont's authority to issue driver's licenses. When I go to another country, they may also accept my license, not because it was issued by Vermont but because they accept licenses recognized as valid in the U.S.

The primary role of certificates is to establish identity and define what actions the certificate holder may or may not take. Most certificates used today comply with International Telecommunication Union Telecommunication Standardization Sector (ITU-T) Recommendation X.509 Version 3, and contain such information as a serial number, digital signature algorithm identifier, issuer's name, validity period, and the subject's name and public key information.

Any organization that issues certificates can be a CA, such as a company that issues certificates to its employees or a university that issues certificates to its students. For e-commerce applications, it is particularly important that the CA is known to be reputable; some well-known commercial CAs include AT&T, GTE Cybertrust, Nortel EnTrust, and VeriSign.

FIGURE 4: GTE Cybertrust-issued certificate as viewed by Internet Explorer.

Figure 4 shows a sample certificate as shipped with Internet Explorer 4 (IE4); this particular one is issued by GTE Cybertrust and is one of the many so-called root-level certificates that are shipped with common browsers. When the user connects to a secure Web site, the server sends its certificate to the user's system, containing the Web site's public key and a signature using the private key of the issuing CA. The browser then checks the certificate issuer's signature against the CA's public key that it has stored; if there is a match, the certificate is accepted as valid and the Web site can be trusted. Certificates and the collection of CAs will form a Public Key Infrastructure (PKI).

In the early 1990s as public-key cryptography usage increased, RSA Laboratories (www.rsalabs.com) recognized that effective use of the technology in a multi-vendor environment could only succeed if interoperable standards were in place. To that end, they created a set of Public-Key Cryptography Standards (PKCS), including:

• PKCS #1 (also published as RFC 2437) describes the RSA encryption standard, the construction of digital signatures and envelopes, and the syntax of public and private keys. The PKCS #1 public-key syntax is identical to that of X.509.
• PKCS #7 (also published as RFC 2315) describes the syntax of data which may have cryptography applied to it and some aspects of certificate-based key management.
• PKCS #10 (also published as RFC 2314) describes the syntax of certificate-request messages to certificate authorities.

All of the different cryptographic schemes mentioned in the paragraphs above — and more — are employed somewhere in the Windows NT operating system or server applications. The paragraphs below provide some specific examples of where and how some of these methods are used, and it is by no means an exhaustive discussion.

Passwords and Network Login

Like almost every other operating system, Windows NT does not store passwords on the system in plaintext (although there are some applications that store passwords in memory in plaintext, but that's another problem). All user-related authentication information, such as usernames and passwords, are stored in the Security Accounts Manager (SAM) portion of the NT registry on the domain controllers. NT passwords can be up to 14 characters in length and are case-sensitive. The SAM stores not the password, but two 16-byte hash values of the password.

The native-NT hash function is obtained using MD4. The second hash value uses a scheme first employed in LAN Manager and considered to be weak by most NT security experts, which is why system administrators are warned to disable the LANMAN hash unless it is absolutely needed for backward compatibility. LAN Manager uses a 14-byte password (112 bits) to form two 56-bit values, each of which are used to encrypt a fixed (known) 8-byte number using DES; the two DES encrypted values are concatenated to form the 16-byte hash. Support for both hashes will continue in Windows 2000.

When clients login to an NT network, the passwords are never exchanged between the workstation and domain controller. Instead, NT uses a challenge/response scheme called the Challenge-Handshake Authentication Protocol (CHAP). Figure 5 shows the general sequence of events. When the user logs onto the client system, the 16-byte hash value of the password is calculated. When the client connects to a server, the username is sent across the network in plaintext. The server generates an 8-byte random value (called a nonce) to send back to the client; this is the challenge.

FIGURE 5: The Challenge-Handshake Authentication Protocol.

The client system then encrypts the 64-bit challenge using DES. The client actually generates three different DES keys: the first key contains the first seven bytes (56 bits) of the password's hash value, the second key contains the next seven bytes in the password's hash, and the third key contains the remaining two bytes of the password's hash appended with five zero-filled bytes. Each key is applied to the random number so that the 8-byte challenge results in three 64-bit outputs, which is the 24-byte response. Actually, two 24-byte responses are returned, one based on the LANMAN hash value and the other using the NT hash.

The server, for its part, looks up the user's password hash values from the SAM database. It then performs the same calculation with the nonce and hash value to create an expected response. If the expected and actual responses match, the server authenticates the user.

This login model will expand somewhat in Windows NT 2000. NT servers up to NT 4.0 cannot forward user identification and capabilities information to other, remote servers. NT 2000's Distributed Security Model will provide this capability using Kerberos (V5) and X.509 public key certificates.

Tunneling and VPNs

The Point-to-Point Tunneling Protocol (PPTP) is used to build "tunnels" between clients and an NT server running the Remote Access Service (RAS) to form virtual private networks (VPNs). PPTP tunnels allow a user to transport and encrypt such protocols as IP (Internet Protocol) and IPX (Internetwork Packet Exchange) over IP on the Internet.

PPTP uses cryptography for both user authentication and data encryption. If the client is a Windows 3.1 or later system and the server uses NT, Microsoft's CHAP (MS-CHAP) implementation will be used for authentication.

For data encryption, PPTP uses the Microsoft Point-to-Point Encryption (MPPE) protocol. If either the server or client is using the exportable version of PPTP software, a 40-bit key is employed; if both use the domestic version, a 128-bit key is used.

But PPTP does not fully utilize the strength inherent with a 128-bit key space because the key is derived from the password. This has two potential weaknesses; passwords are not truly random and the characters used in most people's passwords do not come anywhere near to fully use the 256 possibilities of each byte. This key derivation severely weakens the key choice.

MPPE uses RC4 secret-key encryption. The key is used to seed a string of bytes that are exclusively-ORed (XORed) with the user data; the resulting encrypted byte stream is sent to the receiver where the data can be recovered.

Microsoft's implementation of PPTP has come under significant criticism by renown cryptographer Bruce Schneier (www.counterpane.com). As he publicized in 1998, the original version of MPPE was vulnerable to attack because as long as the user's password was unchanged, MPPE would encrypt every message using the same key. Output-feedback stream ciphers, such as RC4, should never use the same key to encrypt two or more different messages because the key can be recovered if an attacker gets any two of those messages. This particular weakness was fixed when the algorithm was modified so that a unique nonce is added to the password prior to key generation. If you use PPTP, be sure that you have the latest version. An analysis of the current version of PPTP can be found on the Internet at http://www.counterpane.com/pptp.html.

Secure Communication and Transactions on the World Wide Web

The Secure Sockets Layer (SSL) protocol was developed by Netscape Communications to provide application-independent security over the Internet, primarily for the Hypertext Transfer Protocol (HTTP) although SSL support is also available for the File Transfer Protocol (FTP), telnet, Post Office Protocol (POP), and Simple Mail Transfer Protocol (SMTP). SSL employs RSA during an initial handshake used to authenticate the server (client authentication is optional), identify the SKC algorithm for the session, and distribute the session secret key. Once the session encryption scheme is agreed upon, both client and server switch to it. Figure 6 shows a simplified SSL message exchange:

1. When a user enters a Web addresses specifying the https:// protocol, the client establishes a connection to the SSL server listening on TCP port 443. The SSL clients initiates the connection by sending a ClientHello message indicating the SSL version number and the list of SKC schemes that it supports (choices include DES, RC2, RC4, and 3DES).
2. The server responds with a ServerHello indicating the SKC scheme that should be used for this session. The server then sends its X.509 public-key certificate to the client, which contains the server's RSA public key (E_S).
3. The client verifies that the certificate is valid and then extracts the server's public key from the certificate. The client then generates a session secret key (K), sending it to the server encrypted in the server's public key. The client now indicates to the server that it will start using the specified SKC algorithm, ending with a Finished message.
4. The server indicates its use of the encryption scheme and sends a Finished message of its own.
5. Both client and server exchange encrypted data.

FIGURE 6: SSL message exchange.

SSL 3.0 is the commonly available version today, although some implementations of SSL 2.0 are still in use. Both versions are supported by IE4, as well as Microsoft's Internet Information Server (IIS) 4.0 and Proxy Server.

In 1997, a number of weaknesses in SSL 3.0 were reported. The Internet Engineering Task Force (IETF) had already started work on a new version called Transport Layer Security (TLS), described in RFC 2246 (although most references to TLS that I have found in Microsoft documents refer to this as Transport Level Security). TLS extends SSL and, among other things, adds supports 3DES secret key cryptography, SHA hashes, and Diffie-Hellman key exchange. Microsoft supports TLS in both IE and IIS.

Microsoft's Server Gated Cryptography (SGC) is another extension to SSL/TLS. Export from the U.S. of products that employ SKC with keys longer than 40 bits was tightly regulated until recently, and even now general export of crypto products is limited to 56-bit keys. This is why products using SSL — including IE — require an exportable version with weak (40- or 56-bit) keys and only the domestic (North American) version can employ strong (128-bit) keys. Export of products using SKC with keys of any length, however, is allowed for the worldwide financial community, including on-line merchants. SGC is an extension to SSL that supports international use of strong cryptography. Both the client and server must implement SGC and the server must have a valid SGC certificate. During the initial handshake, the bank's server indicates the SGC capability and supplies its certificate; if the certificate is validated, the client can request use of 128-bit RC2 or RC4, 56-bit DES, or 168-bit 3DES. Microsoft supports SGC in the Windows versions of IE 4.0, IIS 4.0, and Money 98.

Microsoft also implements several other protocols and mechanisms for secure Internet financial transactions:

• Microsoft and Visa developed Private Communication Technology (PCT) in the mid-1990s, primarily for credit card validation. PCT supports Diffie-Hellman and RSA for key exchange, and DES, RC2, RC4, and 3DES for encryption. Microsoft supports PCT in IIS 4.0.
• The Secure Electronic Transaction (SET) specification, a companion to PCT, uses DES and RC4 for encryption, and RSA for key exchange, and public-key encryption of bank card numbers. Microsoft supports SET in IIS 4.0.
• The protocols and servers above are used for secure communication and rely on certificates. Microsoft's Certificate Server can be used to create and verify certificates, employing X.509 V1 and V3, PKCS #7, and PKCS #10.

Software Authentication

The Internet has been a boon for software distributors — and for virus and Trojan horse distributors, as well. A major concern whenever someone downloads an executable file from the Internet has to be, "Do I trust the author? And if so, how do I know for sure that this is the code that the author has written?"

Microsoft developed Authenticode for just this purpose. A software publisher will obtain a certificate and assign an identifier and digital signature to their software. Upon downloading the file, users can confirm the author's identity and the file's integrity before installation. Authenticode employs X.509 certificates, the SHA hash scheme, and MD5 encryption.

Local File Encryption

Windows NT 5.0 will introduce the encrypting file system (EFS), an addition to the NT File System (NTFS) that automatically encrypts individual files and/or directories on the local hard drive much the same way that NTFS today can automatically compress files. EFS uses public-key methods so that it is easy to manage and transparent to the user.

EFS also provides a data recovery process so that files can be decrypted without revealing the user's private key. The recovery process will be part of the security policy pertaining to the individual system (or domain). A domain administrator or someone else will be assigned the role of recovery agent and a public-private key pair for recovery purposes will be generated for the domain or individual systems within the domain.

EFS uses DES for file encryption and RSA for key exchange. The basic EFS operation is as follows:

1. When the user saves a file to disk, a random file encryption key (FEK) is created and the file contents are encrypted with that key using DES. The FEK is then encrypted with RSA using the user's public key and placed in a Data Decryption Field. If the user chooses to employ the recovery option, a Data Recovery Field will contain the FEK encrypted with RSA using the recovery agent's public key. The encrypted data, Data Decryption Field, and Data Recovery Field are all stored together.
2. When the user opens the encrypted file, the FEK is recovered from the Data Decryption Field using RSA with the user's private key; the private key can be stored anywhere, such as on an external floppy disk or a smart card. File decryption can proceed with the FEK using DES.
3. If the private key is lost, the encrypted file(s) can be forwarded to the domain's recovery agent. The FEK will be recovered from the Data Recovery Field using the recovery agent' private key. The file(s) can then be decrypted using with the FEK using DES, and the resulting plaintext can be sent back to the user.

[[LATE NOTE FROM THE AUTHOR (8/31/1999): On July 25, J.J. Grace and T.S.V. Bartlett III released a description of a Windows 2000 Encrypting File System (EFS) Vulnerability. Microsoft's comments and Bartlett's response came out within a few days.]]

Other Crypto Applications...

Microsoft uses cryptography with many other applications and products than the ones listed above. In particular, Windows 2000 will provide support for the IP Security (IPsec) protocol. IPsec uses a host of crypto schemes to provide authentication or encryption of IP packets.

Microsoft has made its cryptography and certificate management capabilities available to other vendors' products for Windows 95/98/NT via the Cryptographic Application Programming Interface (CryptoAPI), which allows programmers to access cryptographic functions by simple procedure calls rather than requiring them to write code that has already been developed and debugged. CryptoAPI-supported functions include allowing application developers to easily encrypt/decrypt data, sign messages, calculate hash values, and manage certificates and public keys while ensuring interoperability with MicrosoftWin32 applications. The CryptoAPI started shipping with IE 3.0 and Windows NT 4.0.

This article introduces basic terms and concepts relating to cryptography. The goal is that the reader can read documentation about any cryptographic application from Microsoft and other vendors and make some sense of what the product or service is doing and how. Consumers should be particularly wary of products based upon proprietary cryptographic algorithms. It is ironic that so much of the work on cryptography is done in secret yet secrecy is not the key (no pun intended) to the goodness of a cryptographic algorithm. The best algorithms are those that are well-known and well-documented because they are also well-tested and well-studied; time, in fact, is the best test of good cryptography. The strength of a particular cryptographic scheme lies in the choice and management of the keys.

There are many informative Web sites for cryptographic information, including:

• Counterpane Systems (www.counterpane.com)
• Cryptography Research Inc.'s cryptography.com Site (www.cryptography.com)
• Ron Rivest's "Cryptography and Security" Page (theory.lcs.mit.edu/~rivest/crypto-security.html)
• RSA's Cryptography FAQ (www.rsa.com/rsalabs/newfaq/home.html)

For more general information on cryptography, check out Applied Cryptography, 2nd ed. by Bruce Schneier (John Wiley & Sons) or Cryptography and Network Security: Principles and Practice by Bill Stallings (Prentice Hall). Microsoft-specific crypto-related information can be found on Microsoft's Security Advisor Web (www.microsoft.com/security/Resources/whitepapers.asp).

About the Author: Gary C. Kessler is a senior network security analyst at SymQuest Group (www.symquest.com), a network integration consulting company with headquarters in South Burlington, VT. His e-mail addresses is kumquat@sover.net. Secure e-mail can be sent to him using his PGP public key (http://www.garykessler.net/kumquat_pubkey.html).