1. Chapter 1: Basic Terminology
Encryption is the process of turning a clear-text message (Plaintext) into a data stream which looks like
a meaningless and random sequence of bits (ciphertext). The process of turning ciphertext back into
plaintext is called decryption.
Cryptography deals with making communications secure. Cryptoanalysis deals with breaking
ciphertext, that is, recovering plaintext without knowing the key. Cryptology is a branch of mathematics
which deals with both cryptography and cryptoanalysis.
A cryptographic algorithm, also known as a cipher, is a mathematical function which uses plaintext as
the input and produces ciphertext as the output and vice versa.
All modern ciphers use keys together with plaintext as the input to produce ciphertext. The same or a
different key is supplied to the decryption function to recover plaintext from ciphertext. The details of a
cryptographic algorithm are usually made public. It is the key that the security of a modern cipher lies in,
not the details of the cipher.
Symmetric algorithms use the same key for encryption and decryption. These algorithms require that
both the sender and receiver agree on a key before they can exchange messages securely.
Some symmetric algorithms operate on 1 bit (or sometimes 1 byte) of plaintext at a time. They are called
stream ciphers. Other algorithms operate on blocks of bits at a time. They are called block ciphers.
Most modern block ciphers use the block size of 64 bits.
Public-key algorithms (also known as asymmetric algorithms) use two different keys (a key pair) for
encryption and decryption. The keys in a key pair are mathematically related, but it is computationally
infeasible to deduce one key from the other. These algorithms are called "public-key" because the
encryption key can be made public. Anyone can use the public key to encrypt a message, but only the
owner of the corresponding private key can decrypt it.
Some public-key algorithms such as RSA allow the process to work in the opposite direction as well: a
message can be encrypted with a private key and decrypted with the corresponding public key. If Alice (or
anyone else) can decrypt a message with Bob's public key she knows that the message must have come
from Bob because no one else has Bob's private key. Digital signatures work this way.
Chapter 2: Symmetric Cryptography
Symmetric encryption is the backbone of any secure communication system. Dozens of symmetric
algorithms have been invented and impemented, both in hardware and software. This chapter briefly
describes those relevant to the Microsoft impementation of cryptography.
Block Ciphers
Block ciphers are cryptographic algorithms which operate on 64-bit blocks of plaintext. The encryption
procedure usually consists of multiple and complex rounds of bit shifts, XORs, permutations and
substitutions of plaintext and key bits. Decryption is similar to encryption except that some operations may
be performed in the reverse order. Some algorithms use fix-length keys, for others the key length may
vary.
DES
Data Encryption Standard (DES) is a block cipher invented over 20 years ago by IBM in response to a
public request from the National Bureau of Standards. It has been a worldwide cryptographic standard
since 1976 [1].
DES is a fixed-key-length algorithm. It uses 56-bit keys. Any 56-bit number can be a key.

2. DES has been remarkably resistant to cryptanalysis, but its short key length makes it vulnerable to a
brute-force attack where all possible keys are tried one by one until the correct key in found.
Bruce Schneier writes:
"A brute-force DES-cracking machine that can find a key in an average of 3.5 hours cost only $1 million in
1993. DES is so widespread that it is naive to pretend that NSA <National Security Agency> ... haven't
built such a machine. ... DES will only become less secure as time goes on." [1].
DES is implemented by the Microsoft Enhanced Cryptographic Provider.
RC2
RC2 was invented by Ron Rivest for RSA Data Security, Inc. Its details have not been published.
RC2 is a variable-key-length cipher. However, when using the Microsoft Base Cryptographic Provider, the
key length is hard-coded to 40 bits. When using the Microsoft Enhanced Cryptographic Provider, the key
length is 128 bits by default and can be in the range of 40 to 128 bits in 8-bit increments.
Triple DES
The idea behind Triple DES is to improve the security of DES by applying DES encryption three times
using three different keys. This way the effective key length becomes 56 x 3 = 168 bits which makes
brute-force attacks virtually impossible.
Triple DES is implemented by the Microsoft Enhanced Cryptographic Provider.
Triple DES with 2 Keys
In this variation, DES encryption is still applied three times but using only 2 keys: first key 1 is applied,
then key 2 and then key 1 again. The effective key length is 56 x 2 = 112 bits.
Triple DES with 2 keys is implemented by the Microsoft Enhanced Cryptographic Provider.
Advanced Encryption Standard (AES) aka Rijndael
Rijndael is a block cipher, designed by Joan Daemen and Vincent Rijmen as a candidate algorithm for the
AES. Rijndael became the AES after the FIPS approval by the U.S. government in 2001. The cipher
currently supports key lengths of 128, 192, and 256 bits. AES is implemented by the "Microsoft Enhanced
RSA and AES Cryptographic Provider (Prototype)" on Windows XP and "Microsoft Enhanced RSA and
AES Cryptographic Provider" on Windows 2003. Windows NT and 2000 do not support this cipher.
AspEncrypt offers support for AES starting with version 2.3.
Stream Ciphers
Stream ciphers encrypt plaintext one bit (or sometimes byte) at a time. The stream of plaintext bits are
XORed with the output of a keystream generator which produces a stream of bits based on a seed
value. This seed value is the key for a stream cipher.
The decryption process is identical: the ciphertext bits are XORed with the same keystream (which is the
function of the key).
RC4

3. RC4 was developed by Ron Rivest in 1987. It is a variable-key-size stream cipher. The details of the
algorithm have not been officially published. However, the algorithm's internals have been posted on the
Internet, and the book Applied Cryptography contains its detailed description. The algorithm is
extremely easy to describe and program.
Just like RC2, 40-bit RC4 is supported by the Microsoft Base Cryptographic provider, and the Enhanced
provider allows keys in the range of 40 to 128 bits in 8-bit increments.
Chapter 3: One-way Hash Function
A one-way hash function, also known as a message digest, fingerprint or compression function, is a
mathematical function which takes a variable-length input string and converts it into a fixed-length binary
sequence. Furthermore, a one-way hash function is designed in such a way that it is hard to reverse the
process, that is, to find a string that hashes to a given value (hence the name one-way.) A good hash
function also makes it hard to find two strings that would produce the same hash value.
All modern hash algorithms produce hash values of 128 bits and higher.
Even a slight change in an input string should cause the hash value to change drastically. Even if 1 bit is
flipped in the input string, at least half of the bits in the hash value will flip as a result. This is called an
avalanche effect.
Since it is computationally infeasible to produce a document that would hash to a given value or find two
documents that hash to the same value, a document's hash can serve as a cryptographic equivalent of
the document. This makes a one-way hash function a central notion in public-key cryptography. When
producing a digital signature for a document, we no longer need to encrypt the entire document with a
sender's private key (which can be extremely slow). It is sufficient to encrypt the document's hash value
instead.
Although a one-way hash function is used mostly for generating digital signatures, it can have other
practical applications as well, such as storing passwords in a user database securely or creating a file
identification system. See the Tasks section for some examples.
Hash Algorithms
The Microsoft cryptographic providers support three hash algorithms: MD4, MD5 and SHA.
MD4 & MD5
Both MD4 and MD5 were invented by Ron Rivest. MD stands for Message Digest. Both algorithms
produce 128-bit hash values. MD5 is an improved version of MD4.
SHA
SHA stands for Secure Hash Algorithm. It was designed by NIST and NSA. SHA produces 160-bit hash
values, longer than MD4 and MD5. SHA is generally considered more secure that other algorithms and is
the recommended hash algorithm.
Chapter 4: Public-Key Cryptography
Unlike symmetric cryptography, public key cryptography uses two different keys - one public and one
private. The keys are mathematically related, yet it is computationally infeasible to deduce one from the
other. Anyone with the public key can encrypt a message but not decrypt it. Only the person with the
private key can decrypt the message.

4. Bruce Schneier compares public-key cryptography with a mailbox. He writes:
"Putting mail in the mailbox is analogous to encrypting with the public key; anyone can do it. Just open
the slot and drop it in. Getting mail out of a mailbox is analogous to decrypting with the private key.
Generally it's hard; you need welding torches. However, if you have the secret (the physical key to the
mailbox), it's easy to get mail out of a mailbox." [1]
Secure Communications using Public-Key Cryptography
Using public-key cryptography, Alice and Bob can communicate securely using the following simple
protocol:
• Alice and Bob agree on a public key algorithm.
• Bob sends Alice his public key.
• Alice encrypts her message with Bob's public key and sends it to Bob.
• Bob decrypts Alice's message with his private key.
Notice that this protocol does not require any prior arrangements (such as agreeing on a key) for Alice
and Bob to communicate securely.
In real-world implementations, public keys are rarely used to encrypt actual messages as public-key
cryptography is very slow, about 1000 times slower that conventional cryptography [1]. Instead, public-key
cryptography is used to distribute symmetric keys which are then used to encrypt and decrypt actual
messages, as follows:
• Bob sends Alice his public key.
• Alice generates a random symmetric key (usually called a session key), encrypts it with
Bob's public key and sends it to Bob.
• Bob decrypts the session key with his private key.
• Alice and Bob exchange messages using the session key.
Systems that use both symmetric and public-key cryptography in this manner are called hybrid.
Digital Signatures
Certain public-key algorithms such as RSA allow both the public and private key to be used for
encryption. If a message is encrypted with someone's private key it can only be decrypted with the
corresponding public key. This feature can be used to create digital signatures, as follows:
• Alice encrypts the document with her private key. The encrypted document becomes her
digital signature.
• Alice sends the signature to Bob.
• Bob decrypts the document with Alice's public key thereby verifying the signature.
Once again, encrypting an actual message with a private key is very inefficient. Instead of signing the
entire document, the document's hash can be signed, as follows:
• Alice computes a one-way hash of a document.
• Alice encrypts the hash with her private key. The encrypted hash becomes the
document's signature.
• Alice sends the document along with the signature to Bob.
• Bob produces a one-way hash function of the document received from Alice, decrypts the
signature with Alice's public key and compares the two values. If they match, Bob knows
that: (1) the document really came from Alice and (2) the document was not tampered
with during transmission.

5. RSA
RSA is by far the most popular public-key cryptography algorithm. It supports both encryption and digital
signatures. It is also the easiest one to describe and implement. RSA has withstood years of extensive
cryptoanalysis and is a de facto standard in much of the World [1]. RSA is named after the three inventors
- Ron Rivest, Adi Shamir and Leonard Adleman.
In RSA, a public key is based on the product of two large prime numbers. These two numbers must be
kept secret as they are used to compute the private key. The product of the two prime numbers is referred
to as modulus. The security of RSA lies in the difficulty of factoring large numbers.
The Microsoft Base Cryptographic Provider implements RSA with a 512-bit modulus. With the Microsoft
Enhanced Provider, the default modulus is 1024 bits, and valid moduli can be in the range of 384 bits to
16,384 bits in 8 bit increments.
Man-in-the Middle Attack
The hybrid communication protocol described above is vulnerable to a man-in-the-middle attack. Let's
assume that Mallory, an enemy hacker, not only can listen to the traffic between Alice and Bob, but also
can modify, delete, and substitute Alice's and Bob's messages, as well as introduce new ones.
Mallory can impersonate Alice when talking to Bob and impersonate Bob when talking to Alice. Here is
how the attack goes:
• Bob sends Alice his public key. Mallory intercepts the key and sends his own public key
to Alice.
• Alice generates a random session key, encrypts it with "Bob"'s public key (which is really
Mallory's) and sends it to Bob.
• Mallory intercepts the message. He decrypts the session key with his private key,
encrypts it with Bob's public key and sends it to Bob.
• Bob receives the message thinking it came from Alice. He decrypts it with his private key
and obtains the session key.
• Alice and Bob start exchanging messages using the session key. Mallory, who also has
that key, can now read the entire conversation.
A man-in-the-middle attack works because Alice and Bob have no way to verify they are talking to each
other. An independent third party that everyone trusts is needed to foil the attack. This third party could
bundle the name "Bob" with Bob's public key and sign the package with its own private key. When Alice
receives the signed public key from Bob, she can verify the third party's signature. This way she knows
that the public key really belongs to Bob, and not Mallory.
A signed package containing a person's name (and possibly some other information such as an email
address and company name) and his/her public key is called a digital certificate (or digital ID). An
independent third party that everyone trusts whose responsibility is to issue certificates is called a
Certification Authority (CA). Digital certificates are the topic of the next chapter.
Chapter 5: Digital Certificates
A certificate is a data package that completely identifies an entity, and is issued by a Certification
Authority (CA) only after that authority has verified the entity's identity. The data package includes the
public key that belongs to the entity. When the sender of a message signs the message with its private
key, the recipient of the message can use the sender's public key (retrieved from the certificate either
sent with the message or available elsewhere on the network) to verify that the sender is legitimate.
X.509 Certificates
The X.509 protocol defines the following structure for public-key certificates:
Version

6. Serial Number
Signature Algorithm
Issuer Name
Period of Validity
• Not Before Date
• Not After Date
Subject Name
Subject's Public Key
• Algorithm
• Public Key
Extensions
Signature
The version field identifies the certificate format. The serial number is unique within the CA. The Signature
Algorithm identifies the algorithm used to sign the certificate. Issuer is the name of the CA. The period of
validity is a pair of dates; the certificate is valid during the time period between the two. Subject is the
name of the user to whom the certificate is issued. The subject's public key field includes the algorithm
name and the public key itself. The last field is the CA's signature.
Certification Hierarchy
In order for digital certificates to be effective, the users of the network must have a high level of trust in
the certificate. But what happens if someone doesn't trust the CA - perhaps the person has never heard
of the CA before. This problem is addressed in the certifying process by something called the hierarchy of
trust.
The concept of hierarchy of trust is simply that the process must begin with some certifying authority that
everyone agrees is trustworthy. This ultimate authority is called the root authority. The root authority then
can certify other CAs below it, who can then certify CAs below them, etc. This is illustrated on the
following diagram:

7. When someone receives a certificate that has been issued by a first- or second-tier CA, he or she can
verify that the CA that signed the certificate has been certified by a CA at the tier above it and that, in turn,
that CA has been certified by the one above it, and so on until a chain of trust exists between the lower
level CA (or a user certificate) and the root CA. For example, in the preceding diagram, it can be verified
that CA #4 was certified by CA #1 and that CA #1 was certified by the root CA. This means that when a
certificate from a lower-level CA is passed along with the encrypted message, all of the certificates in its
chain of trust up to the root should be passed along with it.
Certificate Requests
A certificate request is a signed data package that contains a person's information such as name, email
address, company name etc, and his/her public key. A certificate request is generated by a person
wishing to obtain a certificate from the CA. Certificate requests are signed by the person's private key to
prevent tampering with during transmission.
When the CA receives a certificate request it extracts a person's name and public key information and
performs a certain procedure aimed at verifying that the public key really belongs to the person whose
name is included in the certificate request. If the verification process is successful, the CA issues the
certificate and sends it to the requestor.
Certificate Revocation Lists
Certificates can also be revoked, either because the user's key has been compromised, the CA's key has
been compromised, or because the CA no longer wants to certify the user. Each CA maintains a list of all
revoked but not expired certificates. When Alice receives a new certificate she should check to see if it
has been revoked. She can check a database of revoked keys on the network or locally cached list or
revoked certificates.
Chapter 6: Secure Mail and S/MIME
Secure Multipurpose Internet Mail Extensions (S/MIME) is a de facto standard developed by RSA Data
Security, Inc, for sending secure mail based on public-key cryptography. MIME is the industry standard
format for electronic mail, which defines the structure of the message's body. S/MIME-supporting e-mail
applications add digital signatures and encryption capabilities to that format to ensure message integrity,
data origin authentication and confidentiality of electronic mail.
Signed Mail
When a signed message is sent, a detached signature in the PKCS #7 format is sent along with the
message as an attachment. The signature attachment contains the hash of the original message signed
with the sender's private key, as well as the signer certificate.
Enveloped Mail
Enveloped (encrypted) mail is generated using a recipient's public key. The message is actually
encrypted using a random symmetric key, and it is that symmetric key that is encrypted using the

8. recipient's public key and sent along with the message. If a message is being sent to multiple recipients,
the symmetric key is encrypted separately by every recipient's public key. The enveloped message and
all encrypted symmetric keys are packaged together using the PKCS#7 format.
Signed & Enveloped Mail
S/MIME also supports messages that are first signed with the sender's private key and then enveloped
using the recipients' public keys.
S/MIME-Enabled Status of AspEmail
The AspEmail component, when used in conjunction with AspEncrypt, is
capable of sending S/MIME-compliant mail. The S/MIME Enabled logo
indicates that the component has passed RSA's S/MIME Interoperability
Test and is included into the S/MIME Interoperability Master Matrix.
For more information on the S/MIME Enabled logo, visit RSA at
http://www.rsasecurity.com/standards/smime/about.html.
S/MIME Central at RSA
For a complete set of S/MIME specifications, visit RSA's S/MIME Central at http://www.rsa.com/smime.