Unit IV

Public key cryptography

The most commonly used implementations of public key cryptography (also known as public-key
encryption and asymmetric encryption) are based on algorithms presented by Rivest-Shamir-
Adelman (RSA) Data Security.

Public key cryptography involves a pair of keys known as a public key and a private key (a public
key pair), which are associated with an entity that needs to authenticate its identity electronically or
to sign or encrypt data. Each public key is published and the corresponding private key is kept secret.
Data that is encrypted with the public key can be decrypted only with the corresponding private key.

RSA public key pairs can be any size. Typical sizes today are 1024 and 2048 bits.
Public key cryptography enables the following:
 Encryption and decryption, which allow two communicating parties to disguise data that they
send to each other. The sender encrypts, or scrambles, the data before sending it. The receiver
decrypts, or unscrambles, the data after receiving it. While in transit, the encrypted data is not
understood by an intruder.
 Nonrepudiation, which prevents:
o The sender of the data from claiming, at a later date, that the data was never sent
o The data from being altered.
Figure 1 shows you a simplified view of how public key cryptography works. Figure 1. Public-key
encryption

Figure 1 shows how you can freely distribute the public key so that only you (the owner of the
private key) can read data that was encrypted with the public key. In general, to send encrypted data
to someone, you must encrypt the data with that person's public key, and the person receiving the
data decrypts it with the corresponding private key.

If you compare symmetric-key encryption with public-key encryption, you will find that public-key
encryption requires more calculations. Therefore, public-key encryption is not always appropriate for
large amounts of data. However, it is possible to use public-key encryption to send a symmetric key,
which you can then use to encrypt additional data.

The reverse of what is shown in the previous figure also works. That is, data encrypted with your
private key can be decrypted only with your public key. However, this is not a desirable way to
encrypt sensitive data because it means that anyone with your public key, which is by definition
published, could decrypt the sensitive data. Despite this, private-key encryption is useful because it
enables you to use your private key to sign data with your digital signature; anyone with your public
key can be assured that only you sent the data. This is an important requirement for electronic
commerce and other commercial applications of cryptography.
Authentication
All security mechanisms are based on trust; that is, trust in some service to confirm the authenticity
of principals correctly, trust in security algorithms to perform as advertised, and trust in our own
judgements when used to evaluate whether the person in front of us is whom they claim to be.
This concept of trust is essential for striking the right level of protection for your information system.
To achieve this level you need to be able to answer the question, "Who can and should I trust?"

Authentication is the process of establishing that you are who you claim to be; that you are authentic.
Authenticity is established through public-key certificates. Certificates represent a possession-based
authentication scheme by which you are deemed authentic by virtue of possessing a certificate that
identifies you. On its own, this scheme would not be very secure because, presumably, anyone could
manufacture a set of data in the required format that identifies you and use that to masquerade as
you.

To prevent this from occurring, certificates must be digitally signed by a third party who vouches for
your authenticity. This is similar to what happens with passports. If you present your passport to a
custom's officer, that officer can use the passport to confirm that you are who you claim to be. The
officer is able to determine this, in part, because your passport has a picture of you that the officer
can compare to the person presenting the passport and, in part, because the passport itself is
embossed in an official package by the national passport office, which is a neutral third party.

Characteristics of public key pairs

The following characteristics of public key pairs define the primary benefits and drawbacks of public
key authentication:
 Communication can be protected in a public domain environment such as the Internet.
 The security of distributed communication relies heavily on you not losing possession of your
private key. The same can be said for any security system; however like all possession-based
security mechanisms, the only way to revoke a person's ability to enter into the system is to
change the locks.

One application of a public-key cipher is to exchange a symmetric key for use with a remote partner.
For example, if you want to exchange a symmetric key with Joe Smith, you can generate a public
key pair and publicly broadcast your public key to Joe Smith; it does not matter that anyone else sees
the public key. On receipt, Joe Smith could then generate a symmetric key, encrypt that key using
your public key, and send the encrypted result back to you. You can then decrypt that result with
your private key to reveal the symmetric key that Joe Smith generated. Joe Smith and you can then
begin to use the symmetric key to exchange other messages.
Public key pairs are valuable, especially for key exchange. However, they tend to be relatively
expensive to process, their keys tend to be relatively large for the protection they provide, and it is
generally expensive to produce a suitable public key pair.
Figure 1 uses an example of the public key pair.
What is a digital certificate
A certificate is an electronic document that is used to identify an individual, a server, a company, or
some other entity, and to associate that identity with a public key. Like a driver's license, a passport,
a student ID, a library card, or other commonly used personal IDs, a certificate provides generally
recognized proof of a person's identity. Certificates use public key cryptography to address the
problem of impersonation.

To obtain a driver's license, you typically apply to the Department of Motor Vehicles, which verifies
your identity, your ability to drive, your address, and other pertinent information before issuing you a
driver's license. To obtain a student ID, you apply to a school or college that, in turn, performs
different checks (such as whether you paid your tuition) before issuing the student ID. To obtain a
library card, you may only need to provide your name and a utility bill with your address on it.

Certificates work much the same way as any of the previously mentioned forms of identification.
Certificate authorities (CAs) are entities that validate identities and issue certificates. Clients and
servers use certificates issued by the CA to determine the other certificates that can be trusted. Just
like the methods to validate other forms of identification can vary depending on who is issuing the
ID and the purpose for which it is being used, the methods used to validate an identity can vary
depending on the policies of a given CA. In general, before issuing a certificate, the CA must use its
published verification procedures for that type of certificate to ensure that an entity requesting a
certificate is, in fact, who it claims to be.

The certificate issued by the CA binds a particular public key to the name of the entity that the
certificate identifies; for example, the name of an employee or a server. Certificates help to prevent
the use of false public keys for impersonation. Only the public key that is certified by the certificate
will work with the corresponding private key that is owned by the entity identified by the certificate.
In addition to a public key, a certificate also includes the name of the entity it identifies, an
expiration date, the name of the CA that issued the certificate, a serial number, and other
information. Most importantly, a certificate always includes the digital signature of the issuing CA.
The CA digital signature allows the certificate to function as a letter of introduction for users who
know and trust the CA, but do not know the entity that is identified by the certificate.

The contents of certificates are organized according to the X.509 version 3 certificate specification.
This specification has been recommended by the International Telecommunications Union (ITU)
since 1988.
Every X.509 certificate has a data section and a signature section. Figure 1 shows the data and
signature sections of a certificate. Figure 1. Data and signature sections of a certificate

Data section
The data section includes the following information:
 The version number of the X.509 standard supported by the certificate.
 The serial number for the certificate. Every certificate issued by a certificate authority (CA)
has a serial number that is unique among the certificates issued by that CA.
 Information about your public key, including the algorithm used and a representation of the
key itself.
 The distinguished name (DN) of the CA that issued the certificate.
 The time during which the certificate is valid. For example, between 2:00 p.m. on March 26,
2000 and 2:00 p.m. on March 28, 2001.
 The DN of the certificate subject, which is also known as the subject name.
 Optional certificate extensions that provide additional information used by the client or the
server.
Signature section
The signature section includes the following information:
 The cipher or cryptographic algorithm that is used by issuing the CA to create its own digital
signature
 The digital signature for the CA, which is obtained by hashing all of the information in the
certificate together and encrypting it with the CA private key.

Digital certificate authority (CA)
Certificate authorities (CAs) are entities that validate identities and issue certificates. Any node that
validates certificates maintains a list of trusted CA certificates, which determine which issuers of
certificates the node can trust.
The client or server can validate only those certificates issued by one of the CAs for which it has a
certificate. A trusted CA certificate can also be part of a chain of CA certificates, each of which is
issued by the CA above it in a CA hierarchy.

Certificate chains
Certificate authority (CA) hierarchies are reflected in certificate chains. A certificate chain traces a
path of certificates from a branch in the hierarchy to the root of the hierarchy.
Figure 1 shows a certificate chain leading from a certificate that identifies an entity through two
subordinate CA certificates to the CA certificate for the root CA. This example is based on Figure 1
shown in Hierarchies.
Figure 1. A certificate chain

In a certificate chain, the following occurs:

 Each certificate is followed by the certificate of its issuer.
 Each certificate contains the distinguished name (DN) of that certificate's issuer. This is the
same as the subject name of the next certificate in the certificate chain. In this figure, CA Six
contains the DN of CA Three, which issued that certificate. The DN for CA Three is also the
subject name of the next certificate in the chain.
 Each certificate is signed with the private key of its issuer. The signature can be verified with
the public key in the issuer's certificate, which is the next certificate in the certificate chain. In
this figure, the public key in the certificate for CA Three can be used to verify the CA Three's
digital signature on the certificate for CA Six.

Certificate chain verification

Verifying a certificate chain is the process of ensuring that a specific certificate chain is well-formed,
valid, correctly signed, and trustworthy.
The following procedure forms and verifies a certificate chain, beginning with the certificate that is
presented for authentication:
1. The issuer's certificate is located. The source can be the verifier's local certificate database on
that client or server, or the certificate chain that is provided by the subject.
2. The certificate signature is verified using the public key in the issuer's certificate.
3. The validity period for the certificate is verified against the current time provided by the
verifier's system clock.
 4. If the issuer's certificate is trusted by the verifier, verification is successful and stops here.
Otherwise, the issuer's certificate is checked to ensure that it contains the appropriate
subordinate certificate authority (CA) and verification of the certificate chain begins again
with step 1 with the new certificate.
Figure 1 shows what occurs when only a root CA is included in the verifier's local database. Figure
1. Verifying a certificate chain to the root CA

If a certificate for one of the immediate CAs shown in Figure 1, such as CA Two, is found in the
verifier's local database, verification stops with that certificate as shown in Figure 2. Figure 2.
Verifying a certificate chain to an immediate CA

If any of the following events occur at any point in the certificate chain, authentication will fail:
 The validity dates are expired.
 A signature that is not valid is found.
 A certificate for the issuing CA is not found.
Figure 3 shows a certificate chain that cannot be verified. Figure 3. A certificate chain that cannot be
verified
Authentication using digital certificates
Authentication is the process of confirming an identity. In the context of how a network interacts,
authentication involves the confident identification of one party by another party. Authentication
over a network can take many forms, and the use of certificates is one way of supporting that
authentication.
Network interactions generally occur between a client and a server. Client authentication is the
confident identification of a client by a server; that is, identification of the person assumed to be
using the client. Server authentication is the confident identification of a server by a client; that is,
the identification of the organization assumed to be responsible for the server at a particular network
address.

Digital signatures
Encryption and decryption address problems of eavesdropping, but they do not address tampering
and impersonation. However, public-key cryptography does address the problems of tampering and
impersonation.

You can use your private key for encryption and your public key for decryption. Although this is not
desirable when you are encrypting sensitive data, it is an important part of digitally signing any data.
Rather than encrypting the data itself, you can create a one-way hash of the data and then use your
private key to encrypt the hash. The encrypted hash, along with other information like the hashing
algorithm, is known as a digital signature.

Figure 1 shows a simplified view of how you can use a digital signature to validate the integrity of
signed data. Figure 1. Digital signature validating data integrity
Figure 1 shows the original data and the digital signature transferred to the recipient. The digital
signature is basically a one-way hash (or message digest) of the original data that was encrypted with
the signer's private key. To validate the data's integrity, the recipient first uses the signer's public key
to decrypt the digital signature. The recipient then uses the same hashing algorithm that generated the
original hash to generate a new one-way hash of the same data. Information about the hashing
algorithm used is sent with the digital signature; this is not shown in the figure. Finally, the recipient
compares the two hash values. If they match, the data has not changed since it was signed. If the
hashes do not match, the data may have been tampered with since it was first signed or the digital
signature may have been created with a private key that does not correspond to the public key
presented by the signer.

If the hashes match, the recipient can be assured that the public key used to decrypt the digital
signature corresponds to the private key used to create the digital signature. However, confirming the
identity of the signer also requires some way of confirming that the public key truly belongs to a
particular person or other entity. Digital certificates and authentication are used in this case.

You can compare the significance of a digital signature to that of your handwritten signature. Once
you have signed data, it is difficult to deny doing so later. This assumes that the private key was not
compromised or out of the owner's control. Digital signatures make it difficult for the signer to deny
having signed the data.

What Is the RSA Algorithm?

The RSA algorithm is a public-key signature algorithm developed by Ron Rivest, Adi Shamir, and
Leonard Adleman. Their paper was first published in 1977, and the algorithm uses logarithmic
functions to keep the working complex enough to withstand brute force and streamlined enough to
be fast post-deployment. The image below shows it verifies the digital signatures using RSA
methodology.
RSA can also encrypt and decrypt general information to securely exchange data along with handling
digital signature verification. The image above shows the entire procedure of the RSA algorithm.
You will understand more about it in the next section.

RSA in Data Encryption

When using RSA for encryption and decryption of general data, it reverses the key set usage. Unlike
signature verification, it uses the receiver’s public key to encrypt the data, and it uses the receiver’s
private key in decrypting the data. Thus, there is no need to exchange any keys in this scenario.
There are two broad components when it comes to RSA cryptography, they are: 
 Key Generation: Generating the keys to be used for encrypting and decrypting the data to be
exchanged.
 Encryption/Decryption Function: The steps that need to be run when scrambling and
recovering the data.
You will now understand each of these steps in our next sub-topic.

Steps in RSA Algorithm

Keeping the image above in mind, go ahead and see how the entire process works, starting from
creating the key pair, to encrypting and decrypting the information.

Key Generation
You need to generate public and private keys before running the functions to generate your
ciphertext and plaintext. They use certain variables and parameters, all of which are explained below:
 Choose two large prime numbers (p and q)
 Calculate n = p*q and z = (p-1)(q-1)
 Choose a number e where 1 < e < z
 Calculate d = e-1mod(p-1)(q-1)
 You can bundle private key pair as (n,d)
 You can bundle public key pair as (n,e)

Encryption/Decryption Function
Once you generate the keys, you pass the parameters to the functions that calculate your ciphertext
and plaintext using the respective key.
 If the plaintext is m, ciphertext = me mod n.
 If the ciphertext is c, plaintext = cd mod n
To understand the above steps better, you can take an example where p = 17 and q=13. Value of e
can be 5 as it satisfies the condition 1 < e < (p-1)(q-1).
N = p * q = 221
D = e-1mod(p-1)(q-1) = 29
Public Key pair = (221,5)
Private Key pair = (221,29)
If the plaintext(m) value is 10, you can encrypt it using the formula me mod n = 82.
To decrypt this ciphertext(c) back to original data, you must use the formula cd mod n = 29.
You can now look at the factors that make the RSA algorithm stand out versus its competitors in the
advantages section.
Advantages of RSA

 No Key Sharing: RSA encryption depends on using the receiver’s public key, so you don’t
have to share any secret key to receive messages from others.
 Proof of Authenticity: Since the key pairs are related to each other, a receiver can’t intercept
the message since they won’t have the correct private key to decrypt the information.
 Faster Encryption: The encryption process is faster than that of the DSA algorithm.
 Data Can’t Be Modified: Data will be tamper-proof in transit since meddling with the data
will alter the usage of the keys. And the private key won’t be able to decrypt the information,
hence alerting the receiver of manipulation.

What is a Hash Function?

A hash function is a mathematical function or algorithm that simply takes a variable number of
characters (called a ”message”) and converts it into a string with a fixed number of characters (called
a hash value or simply, a hash).
Key Highlights
 A hash function is a mathematical function that converts any digital data into an output string
with a fixed number of characters. Hashing is the one-way act of converting the data (called a
message) into the output (called the hash).
 Hashing is useful to ensure the authenticity of a piece of data and that it has not been
tampered with since even a small change in the message will create an entirely different hash.
 Hash functions are the basic tools of modern cryptography that are used in information
security to authenticate transactions, messages, and digital signatures.

The act of hashing is, therefore, running an input into a formula that converts it into an output
message of fixed length. No matter how many characters long the input is, the output will always be
the same in terms of the number of hexadecimal (letters and numbers) characters.

Hashing is useful to ensure the authenticity of a piece of data, as any small change to the message
will result in a completely different hash value.

Hash functions are the basic tools of modern cryptography that are used in information security to
authenticate transactions, messages, and digital signatures.

Hashing is generally a one-way function, which means that it is easy to convert a message into a
hash but very difficult to “reverse hash” a hash value back to its original message as it requires a
massive amount of computing power.

Why Do We Need Hash Functions?

Standard Length
When you hash a message, it takes your file or message of any size, runs it through a mathematical
algorithm, and spits out an output of a fixed length.
Table 1: Different Hash Functions

In Table 1 above, I have converted the same input message (the letters CFI) into hash values using
three different hash functions (MD5, SHA-1, and SHA-256). Each one of those different hash
functions will spit out an output hash that has a set fixed length of hexadecimal characters. In the
case of MD5, it is 32 characters, SHA-1, 40 characters, and SHA-256, 64 characters.
Table 2: Different Inputs Using the Same Hash Function (SHA-1)
It doesn’t matter what we put in as an input, the same hash function will always produce a hash value
that has the the same number of characters. In Table 2 above, we change the message each time, but
using the same hash function (SHA-1 in this case), the output is always 40 hexadecimal characters
long.

Ensure data integrity

Let’s think of an example where you want to send a digital message or document to someone, and
you want to make sure that it hasn’t been tampered with along the way. You could send it multiple
times and have the recipient verify each copy is the same, but that would not be feasible if the file or
message was very large.

It would be much easier if there was a way of having a shorter and set number of characters for the
sender and receiver to check. And that’s essentially what a hash function allows two computers to
do.
Rather than compare the data in its original (and larger) form, by comparing the two hashes of the
data, computers can quickly confirm that the data has not been tampered with and changed.
Hash functions, therefore, serve as a check-sum or a way for someone to identify whether digital data
has been tampered with after it’s been created.

Verify authenticity
For example, if you send out an email, it can be intercepted easily (especially if it is sent over an
unsecured WiFi network). The recipient of the email has no way of knowing if someone has altered
the contents of the email along the way, called a “Man-in-the-Middle” (MitM) attack.
However, if the sender signs the email with their digital signature and hashes that together with the
email contents, the receiver can examine the hash data to ensure that the email contents have not
been modified after being digitally signed.

To do this, the receiver would compare the hash value on the digitally-signed email received to a
hash value they “re-generate” themselves using the same hash function provided by the sender, as
well as the signer’s public key.

If it matches, that means that no one has altered the message, but if the hashes are different, then the
receiver knows that the contents of the email are not authentic, as even if something small has been
changed in that message, the hash will be completely different.
How Does a Hash Function Work?
A hash function depends on the algorithm but generally, to get the hash value of a set length, it needs
to first divide the input data into fixed-sized blocks, which are called data blocks.
This is because a hash function takes in data at a fixed length. The size of the data block is different
from one algorithm to another.

If the blocks are not big enough, they may add padding to fill it out. However, regardless of what
method of hashing you use, the output, or hash value, is always the same fixed length.

The hash function is then repeated as many times as the number of data blocks.

The “Avalanche Effect”

The data blocks are processed one at a time. The output of the first data block is fed as input along
with the second data block. Consequently, the output of the second is fed along with the third block,
and so on.

Thus, making the final output the combined value of all the blocks. If you change one bit anywhere
in the message, the entire hash value changes. This is called ‘the avalanche effect.

Uniqueness and Deterministic

Hash functions must be Deterministic – meaning that every time you put in the same input, it will
always create the same output.

In other words, the output, or hash value, must be unique to the exact input. There should be no
chance whatsoever that two different message inputs create the same output hash. If a hash function
produces the same output from two different pieces of data, it is known as a “hash collision,” and the
algorithm is useless.

Irreversibility
Ideally, hash functions should be irreversible. Meaning that while it is quick and easy to compute the
hash if you know the input message for any given hash function, it is very difficult to go through the
process in reverse to compute the input message if you only know the hash value.

Brute Force Search

However, it is possible to compute the input given the output hash value, and that involves lots of
computing power. Computing from right to left is called a “brute force” search, using trial and error
to find a message that fits the hash value and see if it produces a match.

Hash Functions in Cryptography

The most famous cryptocurrency, Bitcoin, uses hash functions in its blockchain. Powerful
computers, called miners, race each other in brute force searches to try to solve hashes in order to
earn the mining rewards of new Bitcoins, as well as processing fees that users pay to record their
transactions on the blockchain.
Solving a hash involves computing a proof-of-work, called a NONCE, or “number used once”, that,
when added to the block, causes the block’s hash to begin with a certain number of zeroes. Once a
valid proof-of-work is discovered, the block is considered valid and can be added to the blockchain.

Since each block’s hash is created by a cryptographic algorithm – Bitcoin uses the SHA-256
algorithm – the only way to find a valid proof-of-work is to run guesses through the algorithm until
the right number is found that creates a hash that starts with the right number of zeroes. This is what
Bitcoin miners are doing, running numbers through a cryptographic algorithm until they guess the
valid NONCE.
What are Examples of Common Cryptocurrency Hash Functions?
The SHA-256 function that Bitcoin uses is short for “Secure Hash Algorithm” and was designed by
the United States National Security Agency (NSA) and includes SHA-1, SHA-2 (a family within a
family that includes SHA-224, SHA-256, SHA-384, and SHA-512), and SHA-3 (SHA3-224, SHA3-
256, SHA3-384, and SHA3-512).

Other examples of common hashing algorithms include:

 Message Digest (MD) Algorithm — MD2, MD4, MD5, and MD6. MD5 was long considered
a go-to hashing algorithm, but it’s now considered broken because of hash collisions.
 Windows NTHash — Also known as a Unicode hash or NTLM, this hash is commonly used
by Windows systems
 RACE Integrity Primitives Evaluation Message Digest (RIPEMD)
 Whirlpool
 RSA
Generally speaking, the most popular hashing algorithms or functions have a hash length ranging
from 160 to 512 bits.

Where Else Do You Find Hash Functions at Work?

Any piece of digital information, like a file on your computer, a photo on your smartphone, or a
block on a cryptocurrency blockchain, has a hash. And each hash is unique to each piece of data –
any small change in the underlying information will lead to a completely different hash.

Apart from cryptocurrencies and other blockchain technologies, hash functions can be found
throughout public key cryptography in everything from signing new software and verifying digital
signatures to securing the website connections in your computer and mobile web browsers.

Hashing vs Encryption
Encryption is the practice of taking data and creating a scrambled message in a way that only
someone with a corresponding key, called a cipher, can unscramble and decode it. Encryption is a
two-way function, designed to be reversible by anyone who holds a cipher. So when someone
encrypts something, it is done with the intention of decrypting it later.

Hashing is using a formula that converts data of any size to a fixed length. The computing power
required to “un-hash” something makes it very difficult so whereas encryption is a two-way function,
hashing is generally a one-way function.

Encryption is meant to protect data in transit, hashing is meant to verify that a file or piece of data
hasn’t been altered—that it is authentic. So you might liken encryption to putting a piece of data in a
safe that opens when the recipient knows the combination; hashing is more like a security tamper
seal that indicates if the contents of the data have been altered.
Distribution of Public Keys
Several techniques have been proposed for the distribution of public keys. Virtually all
these proposals can be grouped into the following general schemes:
•                           Public announcement
•                           Publicly available directory
•                           Public-key authority
•                           Public-key certificates

Public Announcement of Public Keys

On the face of it, the point of public-key encryption is that the public key is public. Thus, if
there is some broadly accepted public-key algorithm, such as RSA, any par- ticipant can
send his or her public key to any other participant or broadcast the key to the community at
large (Figure 14.9). For example, because of the growing pop- ularity of PGP (pretty good
privacy, discussed in Chapter 18), which makes use of RSA, many PGP users have adopted
the practice of appending their public key to messages that they send to public forums,
such as USENET newsgroups and Internet mailing lists.

Although this approach is convenient, it has a major weakness. Anyone can forge such a
public announcement. That is, some user could pretend to be user A and send a public key
to another participant or broadcast such a public key. Until such time as user A discovers
the forgery and alerts other participants, the forger is able to read all encrypted messages
intended for A and can use the forged keys for authentication (see Figure 9.3).
 
Publicly Available Directory
A greater degree of security can be achieved by maintaining a publicly available dynamic
directory of public keys. Maintenance and distribution of the public direc- tory would have
to be the responsibility of some trusted entity or organization (Figure 14.10). Such a
scheme would include the following elements:
 The authority maintains a directory with a {name, public key} entry for each
participant.
 Each participant registers a public key with the directory authority. Registration
would have to be in person or by some form of secure authenti- cated
communication.
 A participant may replace the existing key with a new one at any time, either because
of the desire to replace a public key that has already been used for a large amount of
data, or because the corresponding private key has been com- promised in some way.
  
4. Participants could also access the directory electronically. For this purpose, secure,
authenticated communication from the authority to the participant is mandatory.
This scheme is clearly more secure than individual public announcements but still has
vulnerabilities. If an adversary succeeds in obtaining or computing the private key of the
directory authority, the adversary could authoritatively pass out counterfeit public keys and
subsequently impersonate any participant and eaves- drop on messages sent to any
participant. Another way to achieve the same end is for the adversary to tamper with the
records kept by the authority.
 
Public-Key Authority
Stronger security for public-key distribution can be achieved by providing tighter control
over the distribution of public keys from the directory. A typical scenario is illustrated in
Figure 14.11, which is based on a figure in [POPE79]. As before, the scenario assumes that
a central authority maintains a dynamic directory of public keys of all participants. In
addition, each participant reliably knows a public key for the authority, with only the
authority knowing the corresponding private key. The following steps (matched by number
to Figure 14.11) occur.
A sends a timestamped message to the public-key authority containing a request for the
current public key of B.
 The authority responds with a message that is encrypted using the authority’s pri- vate
key, PRauth.Thus,A is able to decrypt the message using the authority’s pub- lic
key.Therefore,A is assured that the message originated with the authority. The message
includes the following:
 B’s public key, PUb, which A can use to encrypt messages destined for  B
 The original request used to enable A to match this response with the cor- responding
earlier request and to verify that the original request was not altered before reception
by the authority
  The original timestamp given so A can determine that this is not an old mes- sage from
the authority containing a key other than B’s current public key
 A stores B’s public key and also uses it to encrypt a message to B containing an
identifier of A (IDA) and a nonce (N1), which is used to identify this transaction
uniquely.
 B retrieves A’s public key from the authority in the same manner as A retrieved B’s
public key.
At this point, public keys have been securely delivered to A and B, and they may begin
their protected exchange. However, two additional steps are desirable:
 B sends a message to A encrypted with PUa and containing A’s nonce (N 1) as well
as  a  new  nonce generated  by B (N2). Because  only  B  could have decrypted
message (3), the presence of N1 in message (6) assures A that the correspondent is B.
 A returns N2, which is encrypted using B’s public key, to assure B that its cor-
respondent is A.
Thus, a total of seven messages are required. However, the initial four mes- sages need be
used only infrequently because both A and B can save the other’s public key for future use
—a technique known as caching. Periodically, a user should request fresh copies of the
public keys of its correspondents to ensure currency.
 
Public-Key Certificates
The scenario of Figure 14.11 is attractive, yet it has some drawbacks. The public-key
authority could be somewhat of a bottleneck in the system, for a user must appeal to the
authority for a public key for every other user that it wishes to contact. As before, the
directory of names and public keys maintained by the authority is vul- nerable to tampering.

An alternative approach, first suggested by Kohnfelder [KOHN78], is to use certificates

that can be used by participants to exchange keys without contacting a public-key
authority, in a way that is as reliable as if the keys were obtained directly from a public-
key authority. In essence, a certificate consists of a public key, an identifier of the key
owner, and the whole block signed by a trusted third party. Typically, the third party is a
certificate authority, such as a government agency or a financial institution, that is trusted
by the user community. A user can present his or her public key to the authority in a secure
manner and obtain a cer- tificate. The user can then publish the certificate. Anyone needing
this user’s pub- lic key can obtain the certificate and verify that it is valid by way of the
attached trusted signature. A participant can also convey its key information to another by
transmitting its certificate. Other participants can verify that the certificate was created by
the authority. We can place the following requirements on this scheme:
1. Any participant can read a certificate to determine the name and public key of the
certificate’s owner.
2. Any participant can verify that the certificate originated from the certificate authority
and is not counterfeit.
3. Only the certificate authority can create and update certificates.
4. These requirements are satisfied by the original proposal in [KOHN78]. Denning
[DENN83] added the following additional requirement:
5. Any participant can verify the currency of the certificate.
A certificate scheme is illustrated in Figure 14.12. Each participant applies to the certificate
authority, supplying a public key and requesting a certificate.

Application must be in person or by some form of secure authenticated communi- cation.

For participant A, the authority provides a certificate of the form
CA = E(PRauth, [T || IDA || PUa])
where PRauth is the private key used by the authority and T is a timestamp. A may then pass
this certificate on to any other participant, who reads and verifies the cer- tificate as
follows:
D(PUauth, CA)  = D(PUauth, E(PRauth, [T || IDA || PUa]))  = (T || IDA || PUa)
The recipient uses the authority’s public key, PUauth, to decrypt the certifi- cate. Because
the certificate is readable only using the authority’s public key, this verifies that the
certificate came from the certificate authority. The elements IDA and PUa provide the
recipient with the name and public key of the certificate’s holder. The timestamp T validates
the currency of the certificate. The timestamp counters the following scenario. A’s private
key is learned by an adversary. A gen- erates a new private/public key pair and applies to
the certificate authority for a new certificate. Meanwhile, the adversary replays the old
certificate to B. If B then encrypts messages using the compromised old public key, the
adversary can read those messages.
In this context, the compromise of a private key is comparable to the loss of a credit card.
The owner cancels the credit card number but is at risk until all possible communicants are
aware that the old credit card is obsolete. Thus, the timestamp serves as something like an
expiration date. If a certificate is sufficiently old, it is assumed to be expired.
One scheme has become universally accepted for formatting public-key cer- tificates: the
X.509 standard. X.509 certificates are used in most network security applications, including
IP security, transport layer security (TLS), and S/MIME, all of which are discussed in Part
Five. X.509 is examined in detail in the next section.
An overview of how an email encryption certificate provides secure email communication
When you send an email through conventional email platforms such as Outlook, Gmail, or Yahoo,
the information could be visible to people who know how to look. Emails are bounced around
through a series of servers and across the internet. As such, they’re not secure without having
encryption or other protective mechanisms in place. This means that they can be “read” by hackers,
putting your company’s (and customers’) sensitive data at risk. This not only opens your company up
to the financial and reputational costs associated with a data breach, but to exorbitant regulatory fines
due to noncompliance as well.
So, how can you secure email communication in a time when phishing and data breaches are on the
rise? Let’s break down how email certificates work and why they’re needed to ensure your emails
are secure.
What is an Email Certificate?
An email certificate is a digital file that is installed to your email application to enable secure email
communication. These certificates are known by many names — email security certificates, email
encryption certificates, S/MIME certificates, etc. S/MIME, which stands for “secure/multipurpose
internet mail extension,” is a certificate that allows users to digitally sign their email communications
as well as encrypt the content and attachments included in them. Not only does this authenticate the
identity of the sender to the recipient, but it also protects the integrity of the email data before it is
transmitted across the internet.
How an Email Security Certificate Works
In a nutshell, an S/MIME email certificate allows you to:
 Encrypt your emails so that only your intended recipient can access the content of the
message.
 Digitally sign your emails so the recipient can verify that the email was, in fact, sent by you
and not a phisher posing as you.
The way that an email encryption certificate works is by using asymmetric encryption. It uses a
public key to encrypt the email and send it so that the recipient, who has the matching private key,
can decrypt the entire message (and any attachments) automatically. Asymmetric encryption is also
what’s behind the SSL/TLS protocol as well as cryptocurrencies.
Let’s say that you need to send an email to a colleague about company financial data. Here is an
email of how this process works when sending the email without and with an email certificate:
Without an S/MIME Email Certificate
With an S/MIME Email Certificate Installed
Installed
• You create a new email in Outlook. • You create a new email in Outlook.

• You draft the content of the email and attach an • You draft the content of the email and attach an
Excel spreadsheet. Excel spreadsheet.

• You hit “Send” to send the plaintext email from • You hit “Send” to send the plaintext email from
Outlook. Outlook.

• The email is sent from your email platform to • Before the message leaves Outlook, the S/MIME
the email server via an unencrypted channel. email certificate automatically:

• The email content (and the spreadsheet

attachment) are sent from the email server to the 1. digitally signs the email to verify your identity
internet. as the sender.

• The email data is then sent from the internet to 2. encrypts the plaintext email data using
 asymmetric encryption (a public key).

• The secure, encrypted email moves from your

email platform to the server via an unencrypted
channel.

the recipient’s email server. • The encrypted email content and attachment are
sent from the email server to the internet.
• The recipient receives an unsigned, unencrypted
email from you, an unverified sender. They open • The email data is then sent from the internet to
the email and read its plaintext message and the recipient’s email server.
access its plaintext Excel spreadsheet.
• The recipient receives the encrypted email,
which is digitally signed to verify your identity as
the sender.

• When they open the email, the private key

automatically decrypts the content and email
attachment so they can read it in plaintext.
Did you notice a difference in the two scenarios? That’s why an email certificate is so important. In
the first scenario that lacks an email encryption certificate, the sender sends a plaintext,
unencrypted email to the recipient via an unencrypted server and the internet. This leaves the
message and its attachments vulnerable to interception by hackers who can “read” the data and
translate it to plaintext. In the second scenario in which the sender uses an email security certificate,
the sender writes a plaintext email that is encrypted prior to moving to the unencrypted server and
the internet. This means that even if the hacker managed to intercept the message, they would be
unable to decrypt the data because they wouldn’t have the private key. Even once the email reaches
the recipient, it remains encrypted while it’s sitting on their computer. This email encryption process
helps to protect your data both when it is at rest and in transit.

Why Email Security Certificates Are Vital to Secure Email Communication

Email encryption certificate is the digital certificate used to sign the email to ensure the receiver that
the email has come from a legitimate person and also that the email has not been tampered with
while in transit. The email is encrypted with Public Key Infrastructure (PKI) algorithm while in
transit so that only the intended recipient can read it.

Email Security Helps to Protect Your Business and Build Customer Trust
As we mentioned earlier, phishing attacks are on the rise and are now the leading cause of cyber
attacks. A simple email can wreak havoc on a company of any size by providing a hacker with
access to their systems — including financial information, proprietary designs, client information,
and data backups — and, ultimately, could cause the company to permanently close its doors.

To help keep their business’s email communications secure, companies can consider the different
ways that they can choose to secure their emails — anti-spam filters and plugins, Domain Keys
Identified Mail (DKIM), sender policy framework (SPF), encrypting email servers, etc. While using
a multi-layered approach is both advisable and necessary, using S/MIME email certificates is
among the most important methods. After all, a digital certificate for email encryption enables you
to encrypt the contents of an email before it ever leaves your email account.

Email Security Helps to Prevent Noncompliance

An additional benefit of using an email certificate is that it can help your organization with
regulatory compliance. Regulations such as the Payment Card Industry’s Data Security Standard
(PCI-DSS), the European Union’s General Data Protection Regulation (GDPR) data security
requirements, and the Healthcare Insurance Portability and Accountability Act (HIPAA) underscore
the importance of having encryption and other protection mechanisms in place for sending sensitive
data via email and other electronic methods.

What is Transport Layer Security (TLS)?

Transport Layer Security, or TLS, is a widely adopted security protocol designed to facilitate privacy
and data security for communications over the Internet. A primary use case of TLS is encrypting the
communication between web applications and servers, such as web browsers loading a website. TLS
can also be used to encrypt other communications such as email, messaging, and voice over IP
(VoIP). In this article we will focus on the role of TLS in web application security.

TLS was proposed by the Internet Engineering Task Force (IETF), an international standards
organization, and the first version of the protocol was published in 1999. The most recent version is
TLS 1.3, which was published in 2018.

What is the difference between TLS and SSL?

TLS evolved from a previous encryption protocol called Secure Sockets Layer (SSL), which was
developed by Netscape. TLS version 1.0 actually began development as SSL version 3.1, but the
name of the protocol was changed before publication in order to indicate that it was no longer
associated with Netscape. Because of this history, the terms TLS and SSL are sometimes used
interchangeably.

What is the difference between TLS and HTTPS?

HTTPS is an implementation of TLS encryption on top of the HTTP protocol, which is used by all
websites as well as some other web services. Any website that uses HTTPS is therefore employing
TLS encryption.

Why should businesses and web applications use the TLS protocol?
TLS encryption can help protect web applications from data breaches and other attacks. Today, TLS-
protected HTTPS is a standard practice for websites. The Google Chrome browser gradually cracked
down on non-HTTPS sites, and other browsers have followed suit. Everyday Internet users are more
wary of websites that do not feature the HTTPS padlock icon.

What does TLS do?

There are three main components to what the TLS protocol accomplishes: Encryption,
Authentication, and Integrity.
 Encryption: hides the data being transferred from third parties.
 Authentication: ensures that the parties exchanging information are who they claim to be.
 Integrity: verifies that the data has not been forged or tampered with.
How does TLS work?
For a website or application to use TLS, it must have a TLS certificate installed on its origin server
(the certificate is also known as an "SSL certificate" because of the naming confusion described
above). A TLS certificate is issued by a certificate authority to the person or business that owns a
domain. The certificate contains important information about who owns the domain, along with the
server's public key, both of which are important for validating the server's identity.
A TLS connection is initiated using a sequence known as the TLS handshake. When a user navigates
to a website that uses TLS, the TLS handshake begins between the user's device (also known as the
client device) and the web server.
During the TLS handshake, the user's device and the web server:
  Specify which version of TLS (TLS 1.0, 1.2, 1.3, etc.) they will use
 Decide on which cipher suites (see below) they will use
 Authenticate the identity of the server using the server's TLS certificate
 Generate session keys for encrypting messages between them after the handshake is complete
The TLS handshake establishes a cipher suite for each communication session. The cipher suite is a
set of algorithms that specifies details such as which shared encryption keys, or session keys, will be
used for that particular session. TLS is able to set the matching session keys over an unencrypted
channel thanks to a technology known as public key cryptography.

The handshake also handles authentication, which usually consists of the server proving its identity
to the client. This is done using public keys. Public keys are encryption keys that use one-way
encryption, meaning that anyone with the public key can unscramble the data encrypted with the
server's private key to ensure its authenticity, but only the original sender can encrypt data with the
private key. The server's public key is part of its TLS certificate.

Once data is encrypted and authenticated, it is then signed with a message authentication code
(MAC). The recipient can then verify the MAC to ensure the integrity of the data. This is kind of like
the tamper-proof foil found on a bottle of aspirin; the consumer knows no one has tampered with
their medicine because the foil is intact when they purchase it.

How does TLS affect web application performance?

The latest versions of TLS hardly impact web application performance at all.
Because of the complex process involved in setting up a TLS connection, some load time and
computational power must be expended. The client and server must communicate back and forth
several times before any data is transmitted, and that eats up precious milliseconds of load times for
web applications, as well as some memory for both the client and the server.

However, there are technologies in place that help to mitigate potential latency created by the TLS
handshake. One is TLS False Start, which lets the server and client start transmitting data before the
TLS handshake is complete. Another technology to speed up TLS is TLS Session Resumption,
which allows clients and servers that have previously communicated to use an abbreviated
handshake.
These improvements have helped to make TLS a very fast protocol that should not noticeably affect
load times. As for the computational costs associated with TLS, they are mostly negligible by
today’s standards.
TLS 1.3, released in 2018, has made TLS even faster. TLS handshakes in TLS 1.3 only require one
round trip (or back-and-forth communication) instead of two, shortening the process by a few
milliseconds. When the user has connected to a website before, the TLS handshake has zero round
trips, speeding it up still further.

What is IPsec?
IPsec is a group of protocols that are used together to set up encrypted connections between devices.
It helps keep data sent over public networks secure. IPsec is often used to set up VPNs, and it works
by encrypting IP packets, along with authenticating the source where the packets come from.
Within the term "IPsec," "IP" stands for "Internet Protocol" and "sec" for "secure." The Internet
Protocol is the main routing protocol used on the Internet; it designates where data will go using IP
addresses. IPsec is secure because it adds encryption* and authentication to this process.

How does IPsec work?

IPsec connections include the following steps:
Key exchange: Keys are necessary for encryption; a key is a string of random characters that can be
used to "lock" (encrypt) and "unlock" (decrypt) messages. IPsec sets up keys with a key exchange
between the connected devices, so that each device can decrypt the other device's messages.
Packet headers and trailers: All data that is sent over a network is broken down into smaller pieces
called packets. Packets contain both a payload, or the actual data being sent, and headers, or
information about that data so that computers receiving the packets know what to do with them.
IPsec adds several headers to data packets containing authentication and encryption information.
IPsec also adds trailers, which go after each packet's payload instead of before.

Authentication: IPsec provides authentication for each packet, like a stamp of authenticity on a
collectible item. This ensures that packets are from a trusted source and not an attacker.

Encryption: IPsec encrypts the payloads within each packet and each packet's IP header (unless
transport mode is used instead of tunnel mode — see below). This keeps data sent over IPsec secure
and private.

Transmission: Encrypted IPsec packets travel across one or more networks to their destination using
a transport protocol. At this stage, IPsec traffic differs from regular IP traffic in that it most often
uses UDP as its transport protocol, rather than TCP. TCP, the Transmission Control Protocol, sets up
dedicated connections between devices and ensures that all packets arrive. UDP, the User Datagram
Protocol, does not set up these dedicated connections. IPsec uses UDP because this allows IPsec
packets to get through firewalls.

Decryption: At the other end of the communication, the packets are decrypted, and applications (e.g.
a browser) can now use the delivered data.

What protocols are used in IPsec?

In networking, a protocol is a specified way of formatting data so that any networked computer can
interpret the data. IPsec is not one protocol, but a suite of protocols. The following protocols make
up the IPsec suite:
Authentication Header (AH): The AH protocol ensures that data packets are from a trusted source
and that the data has not been tampered with, like a tamper-proof seal on a consumer product. These
headers do not provide any encryption; they do not help conceal the data from attackers.
Encapsulating Security Protocol (ESP): ESP encrypts the IP header and the payload for each
packet — unless transport mode is used, in which case it only encrypts the payload. ESP adds its
own header and a trailer to each data packet.
Security Association (SA): SA refers to a number of protocols used for negotiating encryption keys
and algorithms. One of the most common SA protocols is Internet Key Exchange (IKE).
Finally, while the Internet Protocol (IP) is not part of the IPsec suite, IPsec runs directly on top of
IP.

What is the difference between IPsec tunnel mode and IPsec transport mode?
IPsec tunnel mode is used between two dedicated routers, with each router acting as one end of a
virtual "tunnel" through a public network. In IPsec tunnel mode, the original IP header containing the
final destination of the packet is encrypted, in addition to the packet payload. To tell intermediary
routers where to forward the packets, IPsec adds a new IP header. At each end of the tunnel, the
routers decrypt the IP headers to deliver the packets to their destinations.
In transport mode, the payload of each packet is encrypted, but the original IP header is not.
Intermediary routers are thus able to view the final destination of each packet — unless a separate
tunneling protocol (such as GRE) is used.

What port does IPsec use?

A network port is the virtual location where data goes in a computer. Ports are how computers keep
track of different processes and connections; if data goes to a certain port, the computer's operating
system knows which process it belongs to. IPsec usually uses port 500.

What is DNS security?

DNS security is the practice of protecting DNS infrastructure from cyber attacks in order to keep it
performing quickly and reliably. An effective DNS security strategy incorporates a number of
overlapping defenses, including establishing redundant DNS servers, applying security protocols like
DNSSEC, and requiring rigorous DNS logging.

Why is DNS security important?

Like many Internet protocols, the DNS system was not designed with security in mind and contains
several design limitations. These limitations, combined with advances in technology, make DNS
servers vulnerable to a broad spectrum of attacks, including spoofing, amplification, DoS (Denial of
Service), or the interception of private personal information. And since DNS is an integral part of
most Internet requests, it can be a prime target for attacks.

In addition, DNS attacks are frequently deployed in conjunction with other cyberattacks to distract
security teams from the true target. An organization needs to be able to quickly mitigate DNS attacks
so that they are not too busy to handle simultaneous attacks through other vectors.

What are some common attacks involving DNS?

Attackers have found a number of ways to target and exploit DNS servers. Here are some of the most
common:
DNS spoofing/cache poisoning: This is an attack where forged DNS data is introduced into a DNS
resolver’s cache, resulting in the resolver returning an incorrect IP address for a domain. Instead of
going to the correct website, traffic can be diverted to a malicious machine or anywhere else the
attacker desires; often this will be a replica of the original site used for malicious purposes such as
distributing malware or collecting login information.

DNS tunneling: This attack uses other protocols to tunnel through DNS queries and responses.
Attackers can use SSH, TCP, or HTTP to pass malware or stolen information into DNS queries,
undetected by most firewalls.

DNS hijacking: In DNS hijacking, the attacker redirects queries to a different domain name server.
This can be done either with malware or with the unauthorized modification of a DNS server.
Although the result is similar to that of DNS spoofing, this is a fundamentally different attack
because it targets the DNS record of the website on the nameserver, rather than a resolver’s cache.
NXDOMAIN attack: This is a type of DNS flood attack where an attacker inundates a DNS server
with requests, asking for records that do not exist, in an attempt to cause a denial-of-service for
legitimate traffic. This can be accomplished using sophisticated attack tools that can auto-generate
unique subdomains for each request. NXDOMAIN attacks can also target a recursive resolver with
the goal of filling the resolver’s cache with junk requests.

Phantom domain attack: A phantom domain attack has a similar result to an NXDOMAIN attack
on a DNS resolver. The attacker sets up a bunch of ‘phantom’ domain servers that either respond to
requests very slowly or not at all. The resolver is then hit with a flood of requests to these domains
and the resolver gets tied up waiting for responses, leading to slow performance and denial-of-
service.
Random subdomain attack: In this case, the attacker sends DNS queries for several random,
nonexistent subdomains of one legitimate site. The goal is to create a denial-of-service for the
domain’s authoritative nameserver, making it impossible to lookup the website from the nameserver.
As a side effect, the ISP serving the attacker may also be impacted, as their recursive resolver's cache
will be loaded with bad requests.

Domain lock-up attack: Attackers orchestrate this form of attack by setting up special domains and
resolvers to create TCP connections with other legitimate resolvers. When the targeted resolvers send
requests, these domains send back slow streams of random packets, tying up the resolver’s resources.
Botnet-based CPE attack: These attacks are carried out using CPE devices (Customer Premise
Equipment; this is hardware given out by service providers for use by their customers, such as
modems, routers, cable boxes, etc.). The attackers compromise the CPEs and the devices become
part of a botnet, used to perform random subdomain attacks against one site or domain.

What is DNSSEC?
DNS Security Extensions (DNSSEC) is a security protocol created to mitigate this problem.
DNSSEC protects against attacks by digitally signing data to help ensure its validity. In order to
ensure a secure lookup, the signing must happen at every level in the DNS lookup process.

This signing process is similar to someone signing a legal document with a pen; that person signs
with a unique signature that no one else can create, and a court expert can look at that signature and
verify that the document was signed by that person. These digital signatures ensure that data has not
been tampered with.
DNSSEC implements a hierarchical digital signing policy across all layers of DNS. For example, in
the case of a ‘google.com’ lookup, a root DNS server would sign a key for the .COM nameserver,
and the .COM nameserver would then sign a key for google.com’s authoritative nameserver.

While improved security is always preferred, DNSSEC is designed to be backwards-compatible to

ensure that traditional DNS lookups still resolve correctly, albeit without the added security.
DNSSEC is meant to work with other security measures like SSL/TLS as part of a holistic Internet
security strategy.

DNSSEC creates a parent-child train of trust that travels all the way up to the root zone. This chain
of trust cannot be compromised at any layer of DNS, or else the request will become open to an on-
path attack.

To close the chain of trust, the root zone itself needs to be validated (proven to be free of tampering
or fraud), and this is actually done using human intervention. Interestingly, in what’s called a Root
Zone Signing Ceremony, selected individuals from around the world meet to sign the root DNSKEY
RRset in a public and audited way.

What are other ways of protecting against DNS-based attacks?

In addition to DNSSEC, an operator of a DNS zone can take further measures to secure their servers.
Over-provisioning infrastructure is one simple strategy to overcome DDoS attacks. Simply put, if
your nameservers can handle several multiples more traffic than you expect, it is harder for a
volume-based attack to overwhelm your server. Organizations can accomplish this by increasing
their DNS server's total traffic capacity, by establishing multiple redundant DNS servers, and by
using load balancing to route DNS requests to healthy servers when one begins to perform poorly.
Another strategy still is a DNS firewall.

What is a DNS firewall?

A DNS firewall is a tool that can provide a number of security and performance services for DNS
servers. A DNS firewall sits between a user’s recursive resolver and the authoritative nameserver of
the website or service they are trying to reach. The firewall can provide rate limiting services to shut
down attackers trying to overwhelm the server. If the server does experience downtime as the result
of an attack or for any other reason, the DNS firewall can keep the operator’s site or service up by
serving DNS responses from cache.

In addition to its security features, a DNS firewall can also provide performance solutions such as
faster DNS lookups and reduced bandwidth costs for the DNS operator. Learn more about
Cloudflare’s DNS firewall.

DNS as a security tool

DNS resolvers can also be configured to provide security solutions for their end users (people
browsing the Internet). Some DNS resolvers provide features such as content filtering, which can
block sites known to distribute malware and spam, and botnet protection, which blocks
communication with known botnets. Many of these secured DNS resolvers are free to use and a user
can switch to one of these recursive DNS services by changing a single setting in their local router.
Cloudflare DNS has an emphasis on security.

Are DNS queries private?

Another important DNS security issue is user privacy. DNS queries are not encrypted. Even if users
use a DNS resolver like 1.1.1.1 that does not track their activities, DNS queries travel over the
Internet in plaintext. This means anyone who intercepts the query can see which websites the user is
visiting.
This lack of privacy has an impact on security and, in some cases, human rights; if DNS queries are
not private, then it becomes easier for governments to censor the Internet and for attackers to stalk
users' online behavior.

DNS over TLS and DNS over HTTPS are two standards for encrypting DNS queries in order to
prevent external parties from being able to read them.