Chapter 5: Dissecting Asymmetric Encryption

Symmetric algorithms offer fast, efficient encryption while ensuring data confidentiality. However, both parties must share the same secret key. In this chapter, we'll discuss the other main form of encryption: asymmetric (or public-key) encryption. We'll learn how asymmetric encryption was developed to solve the problem of securely exchanging the shared secret key, but then evolved to provide other benefits. You'll understand the two ways to obtain a shared secret key, by using encryption or using a key agreement protocol, such as Diffie-Hellman. We'll also outline how using Diffie-Hellman helps provide perfect forward secrecy.

We'll then cover other uses for public-key encryption, such as securing email and creating a digital signature. We'll discover how using standards, such as the Public Key Cryptography Standards (PKCS), helps provide interoperability among vendors. To understand what is necessary to provide a secure algorithm, we'll cover some of the cryptographic requirements for asymmetric encryption. We'll then dive into an overview of some public-key algorithms, such as Rivest, Shamir, Adleman (RSA) encryption, and Elliptic Curve Cryptography (ECC). We'll discuss how one man's passion for privacy, Phil Zimmermann, led to the development of Pretty Good Privacy (PGP). Although there is a cost involved when using PGP, we'll see how GNU Privacy Guard (GPG) can provide a free alternative. We'll finish with an overview of how digital signatures work and learn how they ensure message authenticity, integrity, and non-repudiation.

In this chapter, we're going to cover the following main topics:

  • Realizing the need for asymmetric encryption
  • Understanding cryptographic requirements
  • Comparing public-key algorithms
  • Working with digital signatures

Realizing the need for asymmetric encryption

We use symmetric encryption to secure our data transactions using a single shared secret key. When using symmetric encryption, it's best practice to change the key often to prevent it from being compromised. As a result, we need to generate and distribute the secret key securely to both parties when needed.

Because symmetric encryption uses a shared secret key, the question remains: how do both parties securely obtain the same key? The answer is to use a hybrid system that employs both symmetric and asymmetric encryption.

The components for asymmetric encryption, such as plaintext, ciphertext, and the encryption algorithm are similar to those used in symmetric encryption. However, instead of using the same shared key, asymmetric encryption uses two keys, a public and a private key, as shown in the following diagram:

Figure 5.1 – Asymmetric key pair

Figure 5.1 – Asymmetric key pair

The two keys are mathematically related and are generated using an asymmetric encryption algorithm, such as RSA or ECC.

In this section, we'll step through the process of exchanging the same shared key using asymmetric encryption. However, we'll also learn how Diffie-Hellman, a key agreement protocol, allows two parties to generate the same shared secret key and helps ensure perfect forward secrecy. Finally, we'll review the PKCS, which is a set of standards derived to promote interoperability among vendors.

Let's start with how we use asymmetric encryption when exchanging a shared secret key.

Securely exchanging a key

When two parties need to communicate securely across a network, such as the internet, they will generally use some form of encryption. For example, if exchanging transactional data such as the contents of a web page using Transport Layer Security (TLS), both parties will use a symmetric stream cipher. Before any data is transmitted, they will need to exchange the shared secret key that is used when encrypting data.

There are two main ways to exchange a key, outlined as follows:

  • Using encryption, with an asymmetric algorithm, such as RSA or ECC
  • Using key agreement, via the Diffie-Hellman process

Both parties will agree on the method to be used prior to the transaction. For example, during a TLS session, the process is determined during the handshake.

Let's take a look at each of these methods, starting with using public-key encryption.

Using public-key encryption to exchange a key

Alice and Bob need to securely communicate with one another. In order to share the secret key, they will use an asymmetric encryption algorithm.

Before beginning the process, Bob will first need to generate a key pair, and then send the public key to Alice.

To illustrate this process, we'll imagine Alice placing the shared secret key in a tennis ball. Alice will then lock the contents and send the ball over the internet to Bob, who will extract the key that is used when transacting data.

The process is shown in the following diagram:

Figure 5.2 – Exchanging the shared secret key

Figure 5.2 – Exchanging the shared secret key

Let's step through the process, as follows:

  1. We begin with the shared secret key on Alice's (the sender) side.
  2. The shared secret key is placed in the tennis ball.
  3. The tennis ball is encrypted using Bob's public key and the encryption algorithm.
  4. The shared secret key is sent to Bob (the recipient).
  5. The ciphertext is decrypted using Bob's private key and the decryption algorithm.
  6. The shared secret key is extracted from the tennis ball.
  7. The resultant shared secret key is presented to Bob (the receiver).

The two parties can now communicate securely using symmetric encryption.

Next, let's look at how two parties can generate a shared secret key, by using the Diffie-Hellman protocol.

Summarizing Diffie-Hellman

Mathematicians Whitfield Diffie and Martin Hellman were two scientists who worked on the development of public-key technology in the 1970s. They published the Diffie-Hellman protocol in 1976, which continues to be used in several applications today.

Unlike using asymmetric encryption to exchange a shared secret key, Diffie-Hellman is a key agreement protocol. The protocol is designed to have each party generate the same shared secret key (denoted by SS in the diagram that follows) that will be used in a session between two parties. To generate the shared secret key, there are private and public variables used in the process, as shown in the following diagram:

Figure 5.3 – Using the Diffie-Hellman protocol

Figure 5.3 – Using the Diffie-Hellman protocol

Let's step through the process of generating a shared secret.

Important note

In a real-life situation, the numbers selected would be significantly larger. However, for this example, we'll use smaller numbers so that you can follow along.

To start the process, we'll need some variables.

Selecting the variables

Each party will need to select some public variables and some private variables.

Public variables

Alice and Bob first agree on two prime numbers P and g, which are not secret. These are outlined here:

  • Prime value P: In practice, the value of P is a large prime number for security reasons. Today, it's common to see P using >2,000 bits.
  • Prime value g: The value of the base g is small and must be less than P.

For the purpose of this example, we'll select the following public variables:

  • P: 23
  • g: 7

Private variables

Alice and Bob then each privately pick two random integers (a whole number), which must be less than P. These are outlined as follows:

  • Alice's private integer, identified as a
  • Bob's private integer, identified as b

For the purpose of this example, we'll select the following private variables:

  • Alice a: 5
  • Bob b: 4

Once the variables are selected, the shared secret key is calculated using the variables. The Diffie-Hellman process uses modulo arithmetic, where the modulo is the remainder after division.

Calculating the shared secret key

Using the variables, the following will generate the shared secret:

  1. Alice calculates A = g^a mod P and sends Bob the value A =16,807.
  2. Bob calculates B = g^b mod N and sends Alice B =2,401.
  3. Alice computes B^a mod P = 8.
  4. Bob computes A^b mod P = 8.

The shared secret key is 8.

Now that the two parties have the same shared secret key, both parties can use the shared secret to securely exchange data using symmetric encryption.

Using the Diffie-Hellman protocol helps ensure perfect forward secrecy. One main reason is that new keys can be generated on demand for each session, without the need to preserve a public-private key pair. This powerful feature helps improve the data-security process, as it provides assurances that no one can compromise the session keys, even if someone obtains the server's private key. We'll learn more about perfect forward secrecy in Chapter 9, Exploring IPsec and TLS.

It's important to understand that the Diffie-Hellman algorithm is not used for encryption; it's used so that each party generates the same shared key. To read more, visit https://tools.ietf.org/html/rfc2631.

Once public-key cryptography made it possible to obtain a shared secret key, scientists felt it was important to create standards, to ensure interoperability between applications. Next, let's take a look at how the PKCS helps bridge the gap among vendors and applications.

Outlining the PKCS

Once industry fully embraced public-key cryptography and began to see the potential uses across applications, the need for consistency became apparent.

In the early 1990s, RSA Security, along with several industry leaders, crafted a set of standards. If implemented, the standards would allow interoperability among various vendors.

The PKCS began with 15 standards. However, as time has passed, several have either been merged with other standards or have been deprecated and are no longer in use.

Some of the standards include the following:

  • PKCS #1 defines the rules and construct of the RSA encryption standard, which includes generating public and private keys, digital certificates, and the digital signature scheme.
  • PKCS #3 provides the methodology to use the Diffie-Hellman key agreement protocol, and specific instructions for some of the parameters in order to generate an appropriate key length.
  • PKCS #10 defines the construct of an X.509 certificate from the certificate authority (CA). The certificate must include components such as the public key and distinguished name of the subject, verified with a digital signature of the CA.

    Important note

    We'll learn more about X.509 certificates in Chapter 8, Using a Public Key Infrastructure.

The PKCS is constantly updated to keep apace with current technologies in data security standards. When researching a standard, make sure you have the latest Request for Comments (RFC).

For example, when looking at the current PKCS #1 RFC: 8017, at https://tools.ietf.org/html/rfc8017, in the upper-left corner you will see the following statement: Obsoletes: 3447.

When a new standard is written, the RFC will then indicate what the next version is by the statement Obsoleted by: XXX, where X indicates the next standard.

Now that we can see how we use asymmetric encryption to securely exchange a shared secret key, let's take a look at what is required when generating a public and private key pair.

Understanding cryptographic requirements

When using asymmetric encryption, we need an algorithm that can generate a mathematically related key pair. In this section, we'll take a look at some of the cryptographic requirements of using an asymmetric algorithm, and we'll see an example of generating a key pair. We'll then discuss the importance of managing the public and private key, and finish with ways we can use asymmetric encryption.

Let's start with some requirements when generating a key pair.

Designing a strong algorithm

When something is strong it is resistant to being broken, such as an impenetrable fortress. An encryption algorithm is no exception, in that we want one that is able to withstand a brute-force attack and continue to provide data confidentiality and integrity. Some of the considerations when designing a strong asymmetric algorithm include the following:

  • It must be effortless to generate a mathematically related public and private key pair.
  • Even with knowledge of the public key, it is infeasible to determine the private key.
  • Even with knowledge of the public key, it is infeasible to determine the plaintext without the private key.
  • Either key can be used for encryption, with the other used for decryption and vice versa.

Now that you understand the parameters of a strong algorithm, let's see an example of generating a key pair.

Generating a key pair

There are several apps that you can use to generate a key pair. However, so that you can see what a public and private key actually looks like, we'll generate a key pair using PGP on the iGolder website. If you would like to follow along, go to https://www.igolder.com/pgp/.

Once at the iGolder website you will see some choices, such as the PGP Key Generator, along with the PGP Encryption Tool and PGP Decryption Tool.

For this exercise, select the PGP Key Generator. On that page, you will need to add some variables to create your key pair, as follows:

  • Email Address: Enter a fictitious email address, as this will not affect the process. For this exercise, we'll use [email protected].
  • PGP-Key Password / Passphrase: Enter a fictitious passphrase. For this exercise, we'll use orangetigerkittens.

Once the two variables are entered, select Generate PGP keys. You will then see your private and public key pair. The following is the public key that you would share with everyone:

-----BEGIN PGP PUBLIC KEY BLOCK-----

Version: BCPG C# v1.6.1.0

mQENBGAF6Y8BCAC5FBW5nqat8bY/ThjjJ/T6o1rJzbM8zT47YqYQ/ga9ui+RH/

0yOeTdJn4aoB1oBpOrRz6g12b39JxB5ZA+AoD7WtgvZN5NjOjGxfY0J6PTPJBz

VR8gFZMto4jni7Cif1ex/9Vc6zeDA7v/Up9TcDeetMrO18HxF06QO55u8dT

pwuq0ZOWSwfCNS31MHAcOtInE7Mg7iKIMGeEOPKYWhCNcmxdi05ImWZo7vl

MgLWPge1daYkcWZAyw7kB9hZ63Mt4GEBKibhyE4enV2zboHkhYfB9YoZm2w

CiXkjAViQ4GWjc+XytgQtZSl6NASbI6KuGgZHJeeCFaJDNZG6iyWyClABEB

AAG0ElJveHlAS2lkZGlrYXR6LmNvbYkBHAQQAQIABgUCYAXpjwAKCRCHxe7

CKllVqzC2CACeXgEZo1SQR4C4HvbvzvRqkQQ/T/RBrNy4CtlDh1EVzfeu7

mdsnMakP28iktbnjdPIIamgUjbNUvjzgj/qACvvDEPmjHe+B7nqkMi+1VNP

lTuJnZWKMW2j3yTEx8Wie4WFSeWPF0i/7j/0UrzBPggk8TGons4fkrkZCi6

pKucpekXdl5F9Zqre16PTHXwTcgIbj/kH3A9D6SdnEHVb6XxPRnLp4FxAmLAOt

DBZu0XYvkk0fCigy2nWwSpgCiPscOmu0pmlpeydfWVgDVv6hLmSzZscODCOjXa

5nT63HDN6bRzKm2LNbefnd0EkC8y0H6HMpvs+7jX6VMtMm6Vn

2UTQ

=aF8z

-----END PGP PUBLIC KEY BLOCK-----

If you want to use the key pair to encrypt text, you will need to save it to your system. The iGolder website also has a location that you can use to encrypt a block of text, by going to https://www.igolder.com/pgp/encryption/.

As you can see, it's easy to generate a key pair and encrypt data. But what about saving and sharing your two keys? Managing keys is another important concept when dealing with asymmetric encryption.

Let's explore this concept, next.

Managing keys

One important concept in asymmetric encryption is that you have two keys. As outlined earlier, the following applies:

  • A public key is public for everyone to see.
  • A private key must be kept private.

For transactions on the web, key management is done by your operating system. For other purposes, such as using GPG email security or managing cryptocurrency in a Bitcoin wallet, it may be up to the individual to manage the keys.

Let's discuss some concepts when storing a private key.

Storing a private key

An individual should protect their private key from exposure or compromise. If someone's key is lost or stolen there can be serious consequences, such as the following:

  • The individual won't be able to decrypt email messages that use a public-key encryption application, such as PGP.
  • A malicious party may be able to access their data or, in some cases, the contents of a crypto wallet.

As a result, any private keys need to be securely stored. One option is to use a dedicated device, such as a Universal Serial Bus (USB) token. Another option is to store the key on a smart card and secure the card using a biometric, such as a fingerprint.

As opposed to a private key, which must be kept private, when using asymmetric encryption we freely share our public key with everyone. Let's outline what options we have for distributing, publishing, and storing a public key.

Publishing a public key

Public keys are designed so that anyone can obtain them. You can store your key on a key server, send via email, or even post on a blog or website. For example, Phil Zimmermann, the creator of PGP, posts his public keys here:

https://philzimmermann.com/text/PRZ_keys.txt

Sharing keys is easy; however, trusting that the keys are authentic is another concern. We'll explore the issue of trust later in this chapter, in the Trusting public keys section.

Let's cover some uses for asymmetric encryption.

Using asymmetric encryption

Scientists realized soon after the development of asymmetric encryption that having a pair of keys to work with is powerful. Over the years, symmetric encryption has evolved to be used in several different ways, including the following:

  • Exchanging the shared secret key
  • Securing our email
  • Producing a blockchain
  • Creating digital signatures

When we think about asymmetric encryption, we see that we can use it for many different applications. However, we do not use symmetric encryption to send and receive data across a network. The reason is that asymmetric encryption is not that efficient.

Some asymmetric algorithms have long key lengths—for example, RSA can use a key between 1,024 and 4,096 bits. Many feel the longer key length has an impact on processing when encrypting and decrypting data.

In addition, asymmetric encryption is resource-intensive as compared to symmetric encryption, which generally uses basic operations such as an exclusive OR (XOR) or a left circular shift. In contrast, asymmetric encryption uses multiplication and division, and can take up to 1,000 times as long to perform as symmetric encryption.

That is why most encryption systems are hybrid, using both symmetric and asymmetric encryption.

By now, you can see the value of using asymmetric encryption. Next, let's take a look at some public-key algorithms.

Comparing public-key algorithms

We understand what is required to create a strong algorithm and see the value in using a key pair. In this section, we'll take a look at a few public-key algorithms, such as RSA and ECC. We'll also see how PGP and GPG can secure our email with little or no effort. Finally, we'll discuss methods we use to ensure trust when using a public key.

Let's start with outlining how RSA is used to secure data.

Outlining RSA

In 1977, Ron Rivest, Adi Shamir, and Len Adleman developed RSA, a widely recognized cipher that is used in a number of different applications.

RSA uses a variety of encryption key lengths that include the following: 1,024-bit, 2,048-bit, and 4,096-bit lengths. The algorithm is used when sending a shared secret key in symmetric encryption. However, it can also be used to encrypt documents and create a digital signature.

Let's step through what is involved when calculating private and public keys using RSA.

Calculating the keys

We'll take a look at the RSA formula that is used to calculate our keys.

In the first step, the algorithm selects two large prime numbers, as follows:

  • Prime value: P
  • Prime value: g

Calculate N by multiplying the two primes, as follows:

  • N = P*g

Compute the (Euler) totient of N, which is the following:

  • Ø(N) = (P-1) * (g-1)

    Important note

    If p and q are two primes, the Euler totient of p*g is this value: (p-1) * (g-1).

Select e (public key) so that it is > coprime (or mutually prime) to Ø(N), e > 1 coprime to Ø(N).

Select d (private key) so that de mod Ø(N) = 1.

Important note

When selecting d, the algorithm will verify the value. This is done by multiplying the public key by the private key and dividing the product by the Euler totient, to ensure that there is a remainder of 1.

Now that we see the formula, let's calculate our keys using actual values, as follows:

  • Prime value P: 167
  • Prime value g: 173
  • N = P*g = 28,891
  • Euler totient of N = 28,552
  • Select e (public key) = 23
  • Select d (private key) = 6207

RSA is considered to be a secure algorithm. This is due to the fact that it is exceedingly difficult to break the encryption, as it requires being able to factor large prime numbers to obtain the key. It remains a solid algorithm that is widely used; however, another alternative is ECC. Let's see what's involved when using ECC, next.

Visualizing an elliptical curve

An elliptical curve is a mathematical function using the formula y^2 = x^3 + ax + b, where x and y are integers within a field. The parameters of the curve are a and b. When graphed in a standard two-dimensional x, y coordinate system, the values of a and b will create curves, as shown in the following screenshot:

Figure 5.4 – An elliptical curve

Figure 5.4 – An elliptical curve

In the preceding screenshot, we see a few key elements, as follows:

  • If you draw a line, it will intersect the curve in no more than three points.
  • When dealing with ECC, everything is kept within the finite field (or maximum value), which represents the key size.
  • An elliptical curve is symmetric at the x axis.

    Important note

    The shape of the curve will change, depending on the value of a and b. For an online elliptical curve generator, go to https://www.desmos.com/calculator/ialhd71we3.

Because of the symmetric nature of an elliptical curve, any point on one side will be equal to the other side. As shown in the following screenshot, b and c, along with d and e, are opposite one another:

Figure 5.5 – The symmetric nature of an elliptical curve

Figure 5.5 – The symmetric nature of an elliptical curve

Each point represents a coordinate on the graph. We will use these points, as the dominant operation in ECC cryptographic schemes is point multiplication. Let's take a look at how this works.

Connecting the dots

As illustrated, within the curve there are multiple points, such as b, c, d, and e. In a large elliptical curve, there will be many more points.

To begin, we'll need a starting point a (or generator), which will generate the value that will represent the private key. The generator will connect to another point (called dotting) and can be repeated multiple times. The algorithm will connect the generator (shown as a) with various points within the graph.

In the following screenshot, we see how a -> b, a -> c, and a -> d:

Figure 5.6 – Dotting the coordinates

Figure 5.6 – Dotting the coordinates

You can connect point a with any other points that exist in the graph any number of times; however, the connections must remain within the limit of the maximum value.

The private key in an ECC is the number of times (n) you dot the generator a with another point on the graph.

Because the maximum value represents the size of the key, if you increase the key size you will expand the space you are able to work with. An expanded space will increase the number of values and decrease the ability of anyone figuring out the private key.

Even with knowledge of where a resides, along with the function that created the graph, it's extremely difficult to find out the number for the private key. ECC is nearly impossible to crack because of the sheer number of possible points on the curve. As a result, ECC is a strong algorithm, as discussed next.

Offering a strong algorithm

ECC has been around since 1985, when mathematicians Neal Koblitz and Victor S. Miller outlined the use of using curves to encrypt data. However, ECC didn't really become a recognized algorithm for encryption until 2004.

Scientists have discovered that ECC has several benefits, one of which is that it can use a significantly smaller key size. As opposed to RSA, which can use a key length of up to 4096 bits, using a 384-bit key with ECC is felt to be exceptionally strong.

The smaller key translates into more efficiency and less storage needed overall. When the ECC is used in TLS certificates, it decreases the time it takes to perform handshakes. Ultimately, this can reduce processing, help websites load faster, and decrease bandwidth requirements.

Because of this efficiency, ECC is ideal for devices with a small form factor and limited processing and storage, such as mobile devices, Internet of Things (IoT), and smart cards.

ECC is a complex method to secure data and is gaining momentum, as it uses a much smaller key while providing robust security.

Now that we understand some of the asymmetric encryption algorithms, let's take a look at an application using public-key encryption, which is designed to secure our email.

Providing PGP

Over the years, there have been many laws written that require vendors to provide a method for government and law enforcement to gain access to encrypted data. Methods include building a backdoor or providing a decryption tool. In 1991, the US government developed several laws to allow access to encrypted data. In response, Phil Zimmermann, a technology leader and visionary, developed PGP so that individuals could control who is able to see their information.

PGP is an asymmetric encryption algorithm used to encrypt and secure emails and documents. PGP provides all the functions of an asymmetric encryption algorithm: key exchange, encryption, and digital signatures. When using PGP with an email client, it is transparent to the user. As long as both parties have exchanged their public keys, they can easily encrypt a message with a public key when sending an email, and the recipient can decrypt the message with their private key.

Stepping through the process

Alice needs to securely send a document to Bob. To accomplish this, Alice and Bob will use PGP encryption to secure the message, as shown in the following diagram:

Figure 5.7 – Encrypting mail using PGP

Figure 5.7 – Encrypting mail using PGP

Let's step through the process, as follows:

  1. We begin with the plaintext (data) input on Alice's (the sender) side.
  2. The plaintext is encrypted using Bob's public key and the encryption algorithm.
  3. The ciphertext is sent to Bob (the recipient).
  4. The ciphertext is decrypted using Bob's private key and the decryption algorithm.
  5. The resultant plaintext (or data) is presented to Bob (the receiver).

Originally, PGP was freely available; however, it is now a commercial product. There are alternatives, including the following:

Each of these can be used to secure your email. GPG includes applications such as Claws, a lightweight email client, so that you can start using GPG to securely send and receive emails.

When working with software such as PGP and GPG, you will generate a public and private key pair. You'll need to share your public key with someone else, as that will be used when sending and receiving emails.

A malicious actor can present another entity's key and spoof someone into thinking it belongs to someone else. We must be aware of this and understand that the one main concern when using a public key is the level of trust we assign in the key. Let's discuss this, next.

Trusting public keys

Once created, a public key isn't automatically authenticated, and no one really knows if a public key belongs to the person specified. Consequently, users must verify that their public keys belong to them.

As outlined, a public key is made available to everyone. However, there is no native way that you can be sure that the key belongs to the individual that has sent the key to you or shared it to a key server.

As a result, an important concept we must address while communicating with entities on the internet and dealing with public keys is the issue of trust. There are two ways to address trust: the Web of Trust and certificates.

Let's take a look at using the Web of Trust when using a public key.

Using the Web of Trust

Phil Zimmerman introduced the Web of Trust after developing PGP. The method is this: instead of a CA such as Go Daddy to decide whether or not a public key can be trusted, we look to a trusted introducer.

We will use this example: You work in the payroll department. Your manager tells everyone that your department is now going to use GPG for email communications. Once the software is installed, everyone creates their own key pair and sends their public key to the manager. The manager will then assign trust.

Generally, a public key will have one of the following levels of trust:

  • Unknown: Keys start at this level. It's up to someone to change this, depending on how comfortable they are in assigning a higher level of trust.
  • None: Don't trust this key as the owner has not signed keys correctly in the past.
  • Marginal: Set for people that you know remotely, perhaps a close acquaintance.
  • Full: You can trust this key, usually your own or someone you saw create the key.

The Web of Trust works in signing public keys in an intimate environment, but on a larger, untrusted environment we need another option. Let's discuss using certificates to assure trust during a transaction on the internet.

Employing certificates to provide trust

On the internet, we use the Public Key Infrastructure (PKI). In the PKI, the CA generates a digital certificate to securely distribute keys between a server (such as a web server) and a client. The signed certificate ensures the authentication of each entity in a digital transaction. We'll learn more about the PKI in Chapter 8, Using a Public Key Infrastructure.

As we have seen, there are a few common asymmetric encryption algorithms, and these include RSA, Diffie-Hellman, and ECC. There are also a few others. We'll most likely see the development of additional asymmetric algorithms in the next few years, to meet the needs of our ever-changing technology landscape.

As we have learned, there are several uses for asymmetric encryption, and that includes creating a digital signature. Let's take a look.

Working with digital signatures

A digital signature is a cryptographic technique that uses asymmetric encryption to provide several services for both sender and receiver. Instead of encrypting an entire document, a digital signature encrypts only a hash of the message, therefore using a smaller footprint.

In this section, we'll see how a digital signature can ensure message authentication, integrity, and non-repudiation. Then, we'll step through the process so that you can see how all of these are accomplished when creating a signature.

Let's start with how we can provide three core security services.

Providing core security services

Because of the vast anonymous nature of the internet, many felt that there needed to be a way of creating and signing a document, using a digital format. The method was to address the issue of being able to complete transactions on the internet without requiring a physical or wet signature, whereby someone physically marks a document.

In 2000, the US government signed into law the Electronic Signatures in Global and National Commerce (ESIGN) Act, which legalized the use of digital signatures on documents. The concept of a digital signature solves several issues. One is that it provides message authentication. Let's discuss this, next.

Ensuring authentication

When dealing with an entity on the internet, it's especially important to guarantee authenticity as this assures both parties that the message originated from an authorized source.

A digital signature assures authentication by using a Hashed Message Authentication Code (HMAC). To create a HMAC, we use a secure hash function (such as SHA-256) that takes a variable length input and creates a fixed-length output. This hash (also called a message digest) is then encrypted using the private key of the sender, to produce a digital signature.

Once the receiver obtains the message, the HMAC is decrypted using the sender's public key. This verifies that the message came from the sender and not an imposter.

Another service that is paramount is that of message integrity. Let's see how this is accomplished.

Guaranteeing integrity

Providing message integrity ensures that data is not modified, lost, or destroyed in either an accidental or unauthorized manner. A HMAC not only provides message authentication but is also used to ensure data integrity.

Prior to signing the message, a hash of the document is generated and then attached to the message. Once the receiver obtains the message, a new hash of the document is generated and then compared to the one attached to the message. If they are the same, this will verify that the message was not modified in any way.

One other service that a digital signature provides is non-repudiation. Let's review this concept.

Assuring non-repudiation

When two people are completing a transaction on the internet, it could be fairly easy to spoof an email or claim that you did not send a message.

The concept of non-repudiation prevents a party from denying participation in a communication. By using a digital signature, the sender must sign the message with their private key. This action ensures non-repudiation as the signature will provide proof that the message was sent by a specific entity.

Now that we have seen which services we can provide using a digital signature, let's see what's involved when generating one.

Creating a digital signature

To create a digital signature, the sender will use their private key, as shown in the following diagram:

Figure 5.8 – Using a digital signature

Figure 5.8 – Using a digital signature

Let's step through the process, as follows:

  1. We begin with the message on Alice's (the sender) side.
  2. The algorithm generates a hash of the message.
  3. The hash is encrypted using Alice's private key and the encryption algorithm.
  4. The message is sent to Bob (the recipient).
  5. The hash is removed and is decrypted using Alice's public key and the decryption algorithm, which assures message authentication.
  6. The algorithm generates a hash of the message.
  7. The two hash values are compared. If they match, we are assured there has been no violation in integrity.

A digital signature can provide assurance of authentication and integrity and prevent non-repudiation, but with a much smaller footprint than when encrypting an entire message.

Summary

In this chapter, we saw how asymmetric encryption solved the problem of securely sharing a secret key in a data transaction. We compared two methods to achieve this, by using encryption or Diffie-Hellman, a key agreement protocol. We also saw how standards such as the PKCS assure vendor interoperability.

By now, you understand some of the requirements needed to create a strong algorithm, along with the importance of effectively managing both public and private keys. We saw the many uses for asymmetric encryption, which include key exchange, securing our email, generating a blockchain, and creating digital signatures.

We then compared a few asymmetric algorithms, such as RSA, PGP, and ECC. We also recognized that there are two main methods to provide trust when using a public key. The two ways to assure trust are the CA in a large environment such as the internet, or the Web of Trust in a smaller environment, such as an office. Finally, we saw how public-key encryption is used to create a digital signature, which assures authentication, integrity, and non-repudiation.

In the next chapter, you'll learn how a hash algorithm is a one-way function that takes a variable-length input and produces a fixed-length output. We'll identify some of the optimal hash properties. We'll then review a few common hash algorithms that are in use today and discuss how they ensure integrity. Finally, you'll learn how a message digest is created to provide message authentication, along with the steps taken to ensure this goal.

Questions

Now, it's time to check your knowledge. Select the best response to the following questions and then check your answers, found in the Assessment section at the end of the book:

  1. _____is a key agreement protocol, designed to have each party generate the same shared secret key that will be used in the session.

    a. PGP

    b. Diffie-Hellman

    c. GPG

    d. Rivest, Shamir, Adleman

  2. PKCS _____defines the construct of an X.509 certificate from the CA, and includes components such as a public key, a distinguished name, and a digital signature of the CA.

    a. #1

    b. #5

    c. #7

    d. #10

  3. _____ uses a variety of encryption key lengths that include 1,024-bit, 2,048-bit, and 4,096-bit lengths.

    a. DES

    b. ECC

    c. RSA

    d. AES

  4. Most encryption systems are ____ and use both symmetric and asymmetric encryption.

    a. hybrid

    b. ElGamal

    c. public

    d. elliptical

  5. The dominant operation in ECC cryptographic schemes is _____multiplication.

    a. Diffie

    b. ElGamal

    c. point

    d. certificate

  6. The _____ works when assigning public keys a level of trust in an intimate environment.

    a. ocean of authentication

    b. ElGamal

    c. dotted system

    d. Web of Trust

  7. A digital signature assures authentication by using a(n) _____.

    a. dotted system

    b. HMAC

    c. RSA chip

    d. elliptical chip

Further reading

Please refer to the following links for more information:

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.91.11.30