- Cryptography Basics
- SSL—Secure Sockets Layer
- Encrypting and Decrypting Data

Although Java has had standard cryptography libraries for well over a year,
the libraries haven't been part of the Java 2 Standard Edition. The
installation procedure for these libraries was somewhat cumbersome, requiring
you to copy several JAR files and edit a configuration file (and that's
using the *easy* installation procedure!) With Java 2 SDK 1.4, however,
these libraries are already installed for you.

## Cryptography Basics

Cryptography can be intimidating for some developers. There are many new terms and strange techniques, and when you delve into the depths of cryptographic algorithms, you often encounter the kind of math you were happy to avoid in college. You don't really need to understand the math to use the Java 2 cryptography libraries, but you do need to learn some of the terminology.

An algorithm that encodes (encrypts) or decodes (decrypts) data is referred
to as a *cipher*. Most ciphers use one or more *encryption keys*,
which tell the cipher how to encrypt the data. For some ciphers, you use the
same key to encrypt and decrypt the data. These ciphers are called
*symmetric key ciphers*. Other ciphers use one key to encrypt and a
different key to decrypt. These ciphers are called *asymmetric key
ciphers*.

You can classify ciphers into two basic categories: *block ciphers* and
*stream ciphers*. A block cipher operates on fixed-size blocks of data at a
time. For example, the Data Encryption Standard (DES) cipher works with 64-bit
blocks of data. When you need to encrypt more than 64 bits, you must encrypt
several blocks. If you must encrypt fewer than 64 bits, you still encrypt 64
bits. You use various padding algorithms to fill out the rest of the 64 bits,
and keep track of how many bits are real data and how many are pad bits.

A stream cipher is sort of a magic box that spits out a seemingly random stream of numbers. To encrypt your data, you grab a byte from the stream cipher and combine it with a byte of your data, often using an exclusive-or operation. Because a stream cipher always generates the same sequence of numbers for a given encryption key, you can decrypt messages just as easily as you encrypt them. The cryptography libraries perform the step of combining the generated byte with your data, of course, but it helps to understand how the stream cipher works with your data.

When you use a symmetric key cipher, you must ensure that only you and the
recipient of your data have the correct key value. Anyone who has your key can
decrypt the data, so if you need to keep the data secret, you must keep the key
secret. With asymmetric keys, you may or may not need to keep both keys secret.
There is a special type of cipher called a *public key cipher* that allows
you to publish the encryption key to everyone. That is, anyone can know the
encryption key and can encrypt data with it, but no one can easily figure out
how to decrypt the data. The decryption key, however, must be kept secret.

In addition to ciphers, you occasionally need to use a *message
digest*, which is a summary of a large block of data—something
like a fingerprint. If the message digest of two blocks of data is the same,
there is a reasonably good chance that the blocks of data are identical. The
complex part of message digests, of course, is that it must be extremely
difficult to create an alternate block of data that has the same digest as
another block. For example, suppose you create a message digest for your credit
card payment. You don't want someone to be able to change the amount of
your payment and then manipulate your payment data so that the digest of the
phony data matches the digest of the original data. This is an important issue
because message digests help verify the authenticity of a message. Most message
algorithms are designed so that changing a single bit in a message causes the
digest to change drastically, making it difficult to falsify data and still have
the same digest.

A digital signature is actually an encrypted message digest, using a backward
public key encryption. When you use public key encryption, you usually encrypt
with the public key, and decrypt with the private key. Under some public key
encryption schemes, however, it turns out that you can encrypt with the private
key and decrypt with the public key. This technique is useless for hiding data
because everyone in the world can use the public key to decrypt your data. For
digitally signing data, however, it is perfect. You generate a message digest
for your data and then encrypt it with your private key. This encrypted digest
is called the *digital signature* of the data. It verifies both the
integrity of the data and its origin (that is, it verifies that you are the one
who sent the data). When someone receives your data, they generate the message
digest from the data and then decrypt your digital signature value. If the
signature digest matches the one the one generated from your data, no one has
tampered with your data—and you are the originator of the data. If the
digests don't match, then either the data has been tampered with, or the
digest wasn't encrypted with your private key (meaning you aren't the
originator of the data).