Cryptography With Java 2 SDK 1.4
- Cryptography Basics
- SSL—Secure Sockets Layer
- Encrypting and Decrypting Data
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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).