**Cryptographic Terminology 101**

Pages: 1, **2**

### Integrity

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:

Cryptographic Checksum | Checksum length | Known flaws |
---|---|---|

MD4 | 128 | yes |

MD5 | 128 | theoretical |

SHA | 160 | theoretical |

SHA-1 | 160 | not 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
- HMAC-SHA-1

### Authenticity

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 http://www.rsasecurity.com/rsalabs/pkcs
or http://ftp.isi.edu/in-notes/rfc2985.txt.

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 Name | Bit Size |
---|---|

1 | 768 |

2 | 1024 |

5 | 1536 |

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.

- 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.
- Once the recipient is verified, the DH algorithm is used to create the information that will be used to create the session key.
- 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.
- 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.