BSD DevCenter
oreilly.comSafari Books Online.Conferences.


Cryptographic Terminology 101
Pages: 1, 2


Integrity is the second component found in cryptosystems. This component ensures that the data received is indeed the data that was sent and that the data wasn't tampered with during transit. It requires a different class of algorithms, known as cryptographic checksums or cryptographic hashes. You may already be familiar with checksums as they are used to ensure that all of the bits in a frame or a header arrived in the order they were sent. However, frame and header checksums use a very simple algorithm, meaning that it is mathematically possible to change the bits and still use the same checksum. Cryptographic checksums need to be more tamper-resistant.

Like encryption algorithms, cryptographic checksums vary in their effectiveness. The longer the checksum, the harder it is to change the data and recreate the same checksum. Also, some checksums have known flaws. The following table summarizes the cryptographic checksums:

Checksum lengthKnown flaws
SHA-1160not yet

The order in the above chart is intentional. When it comes to cryptographic checksums, MD4 is the least secure, and SHA-1 is the most secure. Always choose the most secure checksum available in your cryptosystem.

Another term to look for in a cryptographic checksum is HMAC or Hash-based Message Authentication Code. This indicates that the checksum algorithm uses a key as part of the checksum. This is good, as it's impossible to alter the checksum without access to the key. If a cryptographic checksum uses HMAC, you'll see that term before the name of the checksum. For example, HMAC-MD4 is more secure than MD4, HMAC-SHA is more secure than SHA. If we were to order the checksum algorithms from least secure to most secure, it would look like this:

  • MD4
  • MD5
  • SHA
  • SHA-1
  • HMAC-MD4
  • HMAC-MD5
  • HMAC-SHA-1


So far, we've ensured that the data has been encrypted and that the data hasn't been altered during transit. However, all of that work would be for naught if the data, and more importantly, the key, were mistakenly sent to the wrong recipient. This is where the third component, or authenticity, comes into play.

Before any encryption can occur, a key has to be created and exchanged. Since the same key is used to encrypt and to decrypt the data during the session, it is known as a symmetric or session key. How do we safely exchange that key in the first place? How can we be sure that we just exchanged that key with the intended recipient and no one else?

This requires yet another class of algorithms known as asymmetric or public key algorithms. These algorithms are called asymmetric as the sender and recipient do not share the same key. Instead, both the sender and the recipient separately generate a key pair which consists of two mathematically related keys. One key, known as the public key, is exchanged. This means that the recipient has a copy of the sender's public key and vice versa. The other key, known as the private key, must be kept private. The security depends upon the fact that no one else has a copy of a user's private key. If a user suspects that his private key has been compromised, he should immediately revoke that key pair and generate a new key pair.

When a key pair is generated, it is associated with a unique string of short nonsense words known as a fingerprint. The fingerprint is used to ensure that you are viewing the correct public key. (Remember, you never get to see anyone else's private key.) In order to verify a recipient, they first need to send you a copy of their public key. You then need to double-check the fingerprint with the other person to ensure you did indeed get their public key. This will make more sense in the next article when we generate a key pair and you see a fingerprint for yourself.

The most common key generation algorithm is RSA. You'll often see the term RSA associated with digital certificates or certificate authorities, also known as CAs. A digital certificate is a signed file that contains a recipient's public key, some information about the recipient, and an expiration date. The X.509 or PKCS #9 standard dictates the information found in a digital certificate. You can read the standard for yourself at or

Digital certificates are usually stored on a computer known as a Certificate Authority. This means that you don't have to exchange public keys with a recipient manually. Instead, your system will query the CA when it needs a copy of a recipient's public key. This provides for a scalable authentication system. A CA can store the digital certificates of many recipients, and those recipients can be either users or computers.

It is also possible to generate digital certificates using an algorithm known as DSA. However, this algorithm is patented and is slower than RSA. Here is a FAQ on the difference between RSA and DSA. (The entire RSA Laboratories' FAQ is very good reading if you would like a more in depth understanding of cryptography.)

There is one last point to make on the subject of digital certificates and CAs. A digital certificate contains an expiration date, and the certificate cannot be deleted from the CA before that date. What if a private key becomes compromised before that date? You'll obviously want to generate a new certificate containing the new public key. However, you can't delete the old certificate until it expires. To ensure that certificate won't inadvertently be used to authenticate a recipient, you can place it in the CRL or Certificate Revocation List. Whenever a certificate is requested, the CRL is read to ensure that the certificate is still valid.

Authenticating the recipient is one half of the authenticity component. The other half involves generating and exchanging the information that will be used to create the session key which in turn will be used to encrypt and decrypt the data. This again requires an asymmetric algorithm, but this time it is usually the Diffie Hellman, or DH, algorithm.

It is important to realize that Diffie Hellman doesn't make the actual session key itself, but the keying information used to generate that key. This involves a fair bit of fancy math which isn't for the faint of heart. The best explanation I've come across, in understandable language with diagrams, is Diffie-Hellman Key Exchange - A Non-Mathematician's Explanation by Keith Palmgren.

It is important that the keying information is kept as secure as possible, so the larger the bit size, the better. The possible Diffie Hellman bit sizes have been divided into groups. The following chart summarizes the possible Diffie Hellman Groups:

Group NameBit Size

When configuring a cryptosytem, you should use the largest Diffie Hellman Group size that it supports.

The other term you'll see associated with the keying information is PFS, or Perfect Forward Secrecy, which Diffie Hellman supports. PFS ensures that the new keying information is not mathematically related to the old keying information. This means that if someone sniffs an old session key, they won't be able to use that key to guess the new session key. PFS is always a good thing and you should use it if the cryptosytem supports it.

Putting It All Together

Let's do a quick recap and summarize how a cryptosytem protects the data transmitted onto a network.

  1. First, the recipient's public key is used to verify that you are sending the data to the correct recipient. That public key was created by the RSA algorithm and is typically stored in a digital certificate that resides on a CA.
  2. Once the recipient is verified, the DH algorithm is used to create the information that will be used to create the session key.
  3. Once the keying information is available, a key that is unique to that session is created. This key is used by both the sender and the receiver to encrypt and decrypt the data they send to each other. It is important that this key changes often.
  4. Before the data is encrypted, a cryptographic checksum is calculated. Once the data is decrypted, the cryptographic checksum is recalculated to ensure that the recipient has received the original message.

In next week's article, you'll have the opportunity to see many of these cryptographic terms in action as we'll be configuring a cryptosytem that comes built-in to your FreeBSD system: ssh.

Dru Lavigne is a network and systems administrator, IT instructor, author and international speaker. She has over a decade of experience administering and teaching Netware, Microsoft, Cisco, Checkpoint, SCO, Solaris, Linux, and BSD systems. A prolific author, she pens the popular FreeBSD Basics column for O'Reilly and is author of BSD Hacks and The Best of FreeBSD Basics.

Read more FreeBSD Basics columns.

Return to the BSD DevCenter.

Sponsored by: