It seems every security book contains the obligatory chapter with an overview of cryptography. Personally we never read them and wanted to avoid writing one. But cryptography is such an important part of building web applications that a referenceable overview section in the document seemed appropriate.

Cryptography is no silver bullet. A common phrase of "Sure, we'll encrypt it then, that'll solve the problem" is all too easy to apply to common scenarios. But cryptography is hard to get right in the real world. To encrypt a piece of data typically requires the system to have established out of band trust relationships or have exchanged keys securely. The cryptography industry has recently been swamped with snake-oil vendors pushing fantastical claims about their products when a cursory glance often highlights significant weaknesses. If a vendor mentions "military grade" or "unbreakable" start to run! A great FAQ is available on snake oil cryptography at: http://www.interhack.net/people/cmcurtin/snake-oil-faq.html

Good cryptography is based on being reliant on the secrecy of the key and not the algorithm for security. This is an important point. A good algorithm is one which can be publicly scrutinized and proven to be secure. If a vendor says "trust us, we've had experts look at this", chances are they weren't experts!

Cryptography can be used to provide:

A cryptographic system (or a cipher system) is a method of hiding data so that only certain people can view it. Cryptography is the practice of creating and using cryptographic systems. Cryptanalysis is the science of analyzing and reverse engineering cryptographic systems. The original data is called plaintext. The protected data is called ciphertext. Encryption is a procedure to convert plaintext into ciphertext. Decryption is a procedure to convert ciphertext into plaintext. A cryptographic system typically consists of algorithms, keys, and key management facilities.

There are two basic types of cryptographic systems: symmetric ("private key") and asymmetric ("public key").

Symmetric key systems require both the sender and the recipient to have the same key. This key is used by the sender to encrypt the data, and again by the recipient to decrypt the data. Key exchange is clearly a problem. How do you securely send a key that will enable you to send other data securely? If a private key is intercepted or stolen, the adversary can act as either party and view all data and communications. You can think of the symmetric crypto system as akin to the Chubb type of door locks. You must be in possession of a key to both open and lock the door.

Asymmetric cryptographic systems are considered much more flexible. Each user has both a public key and a private key. Messages are encrypted with one key and can be decrypted only by the other key. The public key can be published widely while the private key is kept secret. If Alice wishes to send Bob a secret, she finds and verifies Bob's public key, encrypts her message with it, and mails it off to Bob. When Bob gets the message, he uses his private key to decrypt it. Verification of public keys is an important step. Failure to verify that the public key really does belong to Bob leaves open the possibility that Alice is using a key whose associated private key is in the hands of an enemy. Public Key Infrastructures or PKI's deal with this problem by providing certification authorities that sign keys by a supposedly trusted party and make them available for download or verification. Asymmetric ciphers are much slower than their symmetric counterparts and key sizes are generally much larger. You can think of a public key system as akin to a Yale type door lock. Anyone can push the door locked, but you must be in possession of the correct key to open the door.