**This article is part of the ****Communication** **Series: ** **The Cryptography Handbook**

*Members** can **download this article in PDF format.*

The security of cryptographic applications critically relies on symmetric keys and private keys that are continually kept secret. The method used to keep them secret is also protected.

Two basic types of algorithms are used in modern cryptography—asymmetric key and symmetric** **key. Asymmetric-key algorithms use a combination of private and public keys while symmetric algorithms use only private ones, commonly referred to as secret keys. The *table* provides a snapshot of the main features of each algorithmic method.

Now let’s investigate how to achieve each of the cryptographic goals using these two types of algorithms.

**Confidentiality Using Symmetric-Key Algorithms**

The main goal of confidentiality, as you recall, is to keep information secured from all who are not privy to it. In a symmetric-key cryptographic system, this is very straightforward and is achieved by encrypting the data that’s exchanged between the sender and the recipient. Both the sender and the recipient have access to the same secret key that’s used to encrypt and decrypt the exchanged message *(Fig. 1)*.

As long as the key is secured and only the sender and the recipient have access to the encryption/decryption key, no one else can receive the transmitted message even if it’s intercepted mid-transmission. Thus, the message stays “confidential.”

**Confidentiality Using Asymmetric-Key Algorithm**

In an asymmetric-key system, the recipient freely distributes her/his public key. The sender acquires the public key and verifies the authenticity of it. A few steps are required to accomplish this *(Fig. 2)*—we will explain the details of this process in our next article, “Cryptographic Algorithms.” But for simplicity’s sake, let’s assume that the sender has access to the verified public key of the recipient. The sender then uses that public key to encrypt the message and sends it to the recipient.

The recipient’s public key is mathematically related to the recipient’s private key. The sender, and anyone else for that matter, doesn’t have access to the recipient’s private key. Once the recipient receives the message, the private key is used to decrypt the message. The recipient’s private key is the only one that can be used to decrypt the message encrypted with the related public key. Since the private key only resides with the recipient, another person or organization can’t decrypt the sent message. Thus, the message stays “confidential.”

**Identification and Authentication Using Symmetric-Key Algorithm**

Recall that the goal for identification and authentication is to first identify an object or a user and then authenticate them so we know that we’re communicating with someone that we really mean to communicate with.

How is this achieved using a symmetric-key scheme?** ***Figure 3* shows a simple example of the symmetric-key identification and authentication process. Review Steps 1 to 6 to better understand the entire process.

Step 4 uses a concept called the “digest.” A digest or hash is a fixed-length value that’s computed over a large data set. We will discuss in detail how message digests are generated in the next article, “Cryptographic Algorithms.”

**Why Do We Need a “Nonce”?**

An imposter could gain possession of the last digest transmitted by the recipient and then issue an “authenticate me” with that digest. These types of attacks are called “replay attacks,” i.e., a resend of a previously used digest. The use of a “nonce” or a single-use random number for authentication prevents such attacks. In this case, the authentication will fail, since for each authentication, the sender requires a new digest with a brand-new nonce number. These numbers are usually generated using an approved random-number generator.

Now let’s investigate a real-life example of identification and authentication using the SHA3-256 algorithm.

**Identification and Authentication Using the SHA-3 Algorithm**

*Figure 4* shows a more complete example of the symmetric-key identification and authentication process. This uses the SHA-3 symmetric-key algorithm, which is the latest in the Secure Hash Algorithm (SHA) family. Maxim Integrated is the first to have a SHA3-256 secure authentication device in production. Review Steps 1 to 6 in the diagram to better understand the process.

The “random number” in *Figure 4* is basically the “nonce” needed to prevent replay attacks as discussed in the simple example given in the previous section.

**Identification and Authentication Using Asymmetric-Key Algorithm**

As mentioned, the goal for identification and authentication is to first identify an object or a user and then authenticate them so that we know we are communicating with someone that we really meant to communicate with.

How is this achieved using an asymmetric-key scheme? *Figure 5* shows a simple example of the symmetric key identification and authentication process. Review Steps 1 to 6 in the diagram to understand the process.

Now let’s investigate a real-life example of identification and authentication using the Elliptic Curve Digital Signature Algorithm (ECDSA).

**Identification and Authentication Using the ECDSA**

*Figure 6* shows a more complete example of the asymmetric-key identification and authentication process using the ECDSA asymmetric-key algorithm. See Steps 1 to 6 in the diagram to better understand the process.

Although this method completes the device authentication, it doesn’t cover the complete system authentication process. This includes verification that the recipient is part of the system, as well as the required verification of the device digital certificates. We’ll review digital certificates, in addition to more detailed descriptions of digital signatures, later in the *Non-Repudiation *section of this article.

**Comparing Cryptographic Algorithms**

*Figure 7* shows a side-by-side comparison of key usage for symmetric- and asymmetric-key algorithms.

Before we go into the next topic, we need to understand the differences between the following two concepts.

- Secure Hash
- HMAC (Hashed Message Authentication Code)

*Figure 8* illustrates the differences between HMAC and Secure Hash. Essentially, Secure Hash uses a hashing algorithm, such as SHA-3, to produce a fixed-length hash of the message regardless of the message length. HMAC is similar, but it uses a key as an additional input to the hashing engine. It also produces a fixed-length hash regardless of the input message length.

**Preserving Integrity Using Symmetric-Key Algorithms**

The goal of preserving the integrity of a message is to ensure that any message received, or any new device being connected, isn’t carrying unwanted code or information.

Let’s look at an example of how this can be achieved using a symmetric key algorithm such as SHA-3. Later, we’ll review the specifics of how these algorithms work.

In *Figure 9*, the sender calculates the digest of a message by using a specific key. As this is a symmetric-key scheme, this key is shared between the sender and the recipient. We will discuss secure methods of key sharing in a later article called “Cryptographic Algorithms.” The digest or hash that’s generated using a key is called an HMAC (Hash-based Message Authentication Code).

This is generated by feeding the message and key to the SHA-3 engine. The resultant HMAC and message is then sent to the recipient. The recipient subsequently generates her own HMAC using her key. The two HMACs are then compared and, if they match, the message hasn’t been tampered with.

In such a scenario, someone could intercept both the HMAC and the message, alter the message, generate a new HMAC, and send it to the recipient. This will not work, however, since the interceptor will not have the recipient’s secret key and the HMACs will not match.

**Preserving Integrity Using Asymmetric-Key Algorithms**

The goal of preserving the integrity of a message is to ensure that any message received, or any new device being connected, isn’t carrying unwanted code or information. Let’s look at an example of how this is achieved using an asymmetric-key algorithm such as ECDSA.

The basic idea behind this is that the sender signs a message with a digital signature and the recipient verifies the signature, to be assured of the received message’s integrity.

In *Figure 10*, the sender calculates the digest of a message by feeding the message to a SHA-2 hashing engine. As this is an asymmetric-key scheme, this key isn’t shared between the sender and the recipient. The sender has a private key that’s never shared, and the recipient has a public key that can be shared with many people and vice versa, unlike the symmetric-key algorithm, where the digest/hash that’s generated doesn’t use a key.

The generated digest is then fed to the ECDSA engine along with the sender’s private key to generate a digital signature of the message. This signature, along with the message, is sent to the recipient. This completes the signing process for the sent message.

Now that the recipient has received the message and the digital signature from the sender, she can start the verification process. This process consists of two distinct steps:

- The recipient computes a message digest from the received message.
- This newly computed digest, the received digital signature from the sender, along with the sender’s public key are then fed into the ECDSA engine for verification.

During the verification process, the ECDSA engine produces a “yes” or “no” result. If the result is a “yes,” then the message integrity has been preserved. If the result is a “no,” the message integrity has been compromised.

**Non-Repudiation Using Asymmetric-Key Algorithms**

A message signed by a digital signature from the sender can be used to prove that the message was sent by the sender and that the message was unaltered. However, a digital signature can’t prove the identity of the sender. Proof of identity is achieved by using a digital certificate.

*Figures 11 through 14* show the complete steps needed to achieve a complete public-key system where messages exchanged can’t be repudiated by either party.

The main idea is that both the sender and recipient need to prove their identity to one another, and their respective public keys need to be proven authentic by a trusted third party.

Why is it so important to use a digital certificate? Without it, someone pretending to be the sender (i.e., an imposter) could send a message encrypted with the recipient’s public key along with a digital signature signed with the imposter’s private key. The imposter would then send the recipient his/her made-up public key. Subsequently, the recipient would use that public key to verify the digital signature and everything would be validated. But the message from the imposter may have malicious information that the recipient will never suspect. This issue can be avoided by using a digital certificate that verifies the public key received did indeed belong to the sender and not some imposter.

**Read more from the ****Communication** **Series: The Cryptography Handbook**

*Zia A. Sardar is an Applications Engineer and a Principal Member of the Technical Staff at Maxim Integrated. *