Imagine if all your internet emails, messages, and purchases were available for everyone to see. A black hat would just need to watch your network traffic to learn anything they wanted to know about your internet browsing, steal your files, or even capture passwords. One of the most important parts of cybersecurity is cryptography, or the process of hiding data so only authorized people can see it.

In this chapter, you’ll learn how encryption works, how attackers try to break it, and how you can strengthen it to protect your personal information from prying eyes.

What Is Cryptography?

Cryptography is the study and art of writing codes. When people want to hide data, they often do so by writing a code or process, known as a cipher, to conceal the information. In modern computer systems we hide data using cryptographic algorithms, which are procedures that perform complex math to securely transform information.

Ciphers and algorithms work in various ways, but they all use keys to function. A key is a piece of unique information that usually remains secret. Using the key, a person can turn plaintext, or data that hasn’t been encrypted, into ciphertext, or encrypted data. The encryption process is similar to putting a lock on a door. When a door is unlocked, anyone can access what’s on the other side. Locks, like cryptography, restrict access to only those who have the key. Every door has a unique lock and key that can be used to keep whatever is on the other side of the door safe. Encoding data using a key is known as encryption. You can think of this like locking a door. Reversing the encryption, a process equivalent to unlocking the door, is called decryption.

What We Encrypt

We use encryption on many types of files and processes. Basically, anything stored on a computer can be encrypted in some form or fashion. However, the type of encryption used might change depending on the state of the data. All data is organized into one of three categories: data at rest, data in transit, and data in use. Data at rest includes any file that a computer isn’t actively processing; for example, music, documents, or information in a database. Data in transit is any data being sent between two systems, including packets (as discussed in Chapter 6), emails, or files in the process of being sent over a network. Data in use is data that a computer system is currently using. This type of data can’t be encrypted, because the computer must be able to read it to use it.

As data moves between different states, the encryption type changes. For example, imagine you install a game on your computer. If you’re not playing that game, you can encrypt it using file encryption, storing it on your hard drive or other storage medium. But as soon as you open the game, it becomes data in use and must be decrypted by the computer to function. Now let’s say you send the game to a friend over the internet. At that point, the game becomes data in transit and must now use transport encryption.

The different options for encryption help distinguish the methods used to encrypt that particular type of data. Each encryption option has its strengths and weaknesses, which we’ll discuss in more detail in “Modern Cryptography” on page 160. For now, keep in mind that just because you’re using one type of encryption, such as file encryption, that doesn’t always mean your data is safe in other states, such as when it’s in use or in transit.

Early Cryptography

The practice of writing encrypted messages has been around for as long as writing has. Militaries used early cryptographic techniques to transport messages, ensuring that the enemy couldn’t learn about their plans should the messages fall into the wrong hands.

Early cryptography was also fairly ad hoc. People had no set standards for how to encrypt messages, so they typically invented strategies on a case-by-case basis. At times, the lack of standards presented problems when transporting messages to a stranger, such as a king or general in another kingdom, because they didn’t know the encryption method. In fact, some historical writings have yet to be interpreted because experts believe they’re written in long-lost ciphers.

The absence of standards highlights one of the primary problems in cryptography: how do you create a system that hides information well while still sharing a decryption key between two people? In other words, this is a problem of balancing the CIA triad elements of confidentiality and availability. If the encryption system is too difficult, it can be challenging to use effectively. For example, if I encrypt a message so it can only be decrypted on the highest peak in a kingdom during a full moon while saying magic words backward in Elvish, I might very well prevent enemies from reading it. But if I want to share my work with other wizards, it will be problematic for them to read it too. However, if I create a cipher that uses a keyword for decryption and then write that word at the top of the message, the encryption becomes pointless because anyone who gets the message will know the keyword as well.

Balancing availability and confidentiality considerations is an ongoing problem in cryptography. To help solve this problem, cryptographers began relying on two methods of encryption: substitution and transposition.

Substitution Ciphers

To create a substitution cipher, you replace one symbol with another. For example, consider the fictitious Super Awesome Substitution Cipher in which you replace each letter of a message with a number. To use the Super Awesome Substitution Cipher, you would only need to know one of the substitutions, which could be used as the key. That key might be A is equal to 10. Once you know the key, it’s easy to continue counting, pairing each subsequent letter with the next number: B becomes 11, C becomes 12, and so on, ending with Z becoming 36. Using this cipher and key, the message attack now becomes 10, 29, 29, 10, 12, 20, 23, 24, 32.

This substitution cipher wouldn’t be very secure for practical use, because it’s simple to crack through trial and error. However, throughout history, many effective ciphers have used the substitution method. The most famous is the Caesar Cipher, which Julius Caesar invented. It relied on the use of two copies of the alphabet. The writer lined up the two alphabets, one on top of another, so they matched: the letter A in the top alphabet aligned with the letter A in the bottom alphabet. The writer then shifted the bottom alphabet left or right by a few spaces and used the shifted alphabet to encrypt their message. The number of spaces shifted was the key. For example, to encrypt the letter A with a key of 3, you would write it as the letter D. Although it’s still easy to break, this was the first cipher to create a standard substitution algorithm, and it became the basis for future substitution ciphers.

Transposition Ciphers

Whereas a substitution cipher replaces a message with completely new symbols, a transposition cipher uses the same symbols but arranges them in a different order to hide their meaning. This process resembles the word jumbles you see in newspapers or online. When put through a transposition cipher, the message attack now might become kcnwta toa, for example.

For a transposition cipher to be an effective form of encryption instead of a fun brainteaser, you must scramble the letters in an organized fashion. There are several ways to accomplish this, but one of the oldest is the Scytale method. Invented in Greece, the original Scytale method used a piece of cloth that was wrapped around a rod of a certain thickness and length. Writers wrote the message across the cloth, and when they unwound it the message was naturally scrambled along its length. A person had to wrap the cloth around the same type of rod to decrypt the message. To conceal the messages even further, people sometimes wore the cloths as belts.

Modern Cryptography

In the 1800s, governments began to use more systematic approaches to cryptography. This included building machines to handle the encryption/decryption process, a method of cryptography best illustrated by the German Enigma machine. Used during World War II, the Enigma used three rotating dials that encrypted and decrypted messages being sent via radio. Theoretically, the cipher was too complicated to break without an Enigma machine to do the work, because the machine’s use of three unique disks generated an extensive number of symbol combinations.

But the cipher wasn’t unbreakable. The universal flaw in cryptography is that any cipher can be broken, given enough time, even if it takes a billion years to try every possible key combination. The real value of a cipher is its work factor, meaning that it takes long enough to break that the message is no longer relevant. By the end of World War II, cryptanalysis, or the study of breaking ciphers, was so advanced that researchers could break any code that relied on a mechanical process, such as the one the Enigma machine used, in a short amount of time. This lowered the work factor of these ciphers, essentially making them worthless.

The advent of computers further reduced work factors, but also created new means of creating ciphers. Computers made it effortless to perform advanced math calculations quickly. As a result, people were able to solve problems in a matter of minutes that would normally have taken them days or weeks to finish. Starting in the 1950s, modern cryptographers began working on new methods of encryption that used exceptionally complicated mathematical problems to compute the numbers necessary to create the ciphertext. For example, using two specific points on an elliptical curve graph that are paired together, you can create a set of keys to encrypt and decrypt ciphertext. Even if you knew one of the points, it would take a high-end computer many, many years to search through all the possible pairs for the correct one.

Eventually, cryptographers created three main methods of encryption: symmetric, asymmetric, and hashing. These three methods became the foundation of modern cryptography and are what most encryption is built upon today.

Symmetric Cryptography

Symmetric cryptography, also known as single or private key cryptography, uses one key to encrypt and decrypt plaintext (Figure 9-1).

Symmetric key algorithms use complex functions to create ciphertext from plaintext, but at their core they still use substitution and transposition techniques. Instead of switching and moving letters, they move around the computer’s 1s and 0s that represent those letters. They’re much stronger than traditional transposition and substitution techniques, because unlike a human manipulating data by hand, a computer can perform hundreds, if not thousands, of transformations in a short amount of time. Computers can also change how they perform the substitution or transposition while running their algorithm. However, this can be tricky for two reasons: the system needs to scramble the 1s and 0s to ensure they can’t be read again, but also make sure the process can be reversed given the correct key.

To make these processes easier, symmetric key algorithms use two types of cipher modes: stream and block. In stream cipher mode, the computer encrypts one bit of data at a time. This mode creates some of the fastest encryption but is generally considered weaker than block modes, because it generates less randomness in the resulting ciphertext; in other words, it produces patterns that can make breaking the algorithm easier, especially if the key is too short or if the same key is used frequently.

Block ciphers encrypt fixed-length blocks of bits. This technique is slower but stronger than using a stream cipher. Instead of encrypting each bit one at a time, the algorithm organizes bits into blocks. For example, a 4 × 4–sized block of bits is taken from the data you’re encrypting, and an equally large block of bits is taken from the key. Then the algorithm encrypts the whole block of bits at once, creating an encrypted 4 × 4–sized block of bits.

Because the blocks are all the same size, the algorithm can combine a previously encrypted block with the key to create a new, unique input to use for the next block that is encrypted. Therefore, not only does the key help create a unique encryption, but what is being encrypted also helps increase the uniqueness of the final ciphertext, making it incredibly hard to break.

Just like locking a door with a key, symmetric algorithms are fast when encrypting files, making them efficient at bulk encryption, such as encrypting numerous files on a hard drive or an entire database. But this speed comes with a catch. If two people attempt to communicate using a symmetric algorithm, they must find a way to transmit the key without exposing it. This requires finding some method of transportation other than the one used to send the ciphertext, because anyone who intercepted the ciphertext would also intercept the key if they were together. The type of transfer needed is known as out of band transportation and can be tricky to do in many situations.

Many symmetric algorithms are available, but two in particular are well known. One is the Data Encryption Standard (DES), which is one of the first modern encryption standards widely used among government, military, and public systems. This algorithm implements a block cipher with a 56-bit key. Although 56 bits resulted in an effective work factor when DES was invented, since the early 2000s it’s been easy to break a DES key in less than 24 hours due to an increase in computer processing power. The more bits there are in a key, the more combinations a computer must go through to guess the right key. But as processors became faster, it became possible for computers to calculate the possible combinations more rapidly. A 56-bit key just doesn’t produce enough combinations to prevent modern processors from guessing the key quickly.

To get more life out of DES, cryptographers invented a new method of using the algorithm, called 3DES (pronounced “triple DES”), which, as you might guess, used three DES keys instead of just one. However, this method included a flaw in how the encryption was executed. Black hats can exploit this flaw to break 3DES nearly as quickly as DES.

Because DES was at the end of its life cycle, people needed a new algorithm to replace it. Many cryptographers tried to develop a replacement, and in the end, they settled on the Rijndael algorithm. Today, we commonly call the implementation of this algorithm the Advanced Encryption Standard (AES). AES typically uses a key size of 128 bits, although the key can be as long as 256 bits if needed. AES uses the block encryption method. Although first implemented in 2001, it’s still very much in use today and has an excellent work factor. Even with current supercomputers, it would take a billion billion years to brute-force an AES key—longer than the age of the universe.

Asymmetric Cryptography

Although symmetric cryptography works well for most encryption needs, such as protecting files or creating a secure connection between two devices, the inability to easily share keys between two parties makes it problematic to use effectively to communicate across the internet. This is where asymmetric cryptography, also known as public key encryption, steps in.

In asymmetric cryptography, the algorithm uses two keys for each party: a public key and a private key. The keys are linked, so anything that the public key encrypts only the private key can decrypt, and vice versa. No one key can encrypt and decrypt the same ciphertext. This system is useful because any data encrypted with the public key can only be decrypted with the private key, so you can share the public key in the same message as the data you intend to encrypt (Figure 9-2).

For this reason, asymmetric cryptography makes it easy to encrypt communication between two people, especially when they don’t know each other. For example, let’s say Alice wants to send Bob a private document using email. Before she encrypts the document, she needs to be assured that Bob can decrypt it once it reaches his inbox. If she were using a symmetric key, she wouldn’t be able to send the key with the email, because anyone who might be sniffing the traffic would see the document and the key. She could put the symmetric key on a zip drive and send it to Bob in the mail, but this would take time and effort. Instead of using a symmetric key, Alice could ask Bob to send her his public key. Bob can send this key over the internet by any convenient means because it doesn’t have to remain a secret. Alice can then encrypt the document using Bob’s public key and send the document back by email. If an adversary intercepts the email, they won’t be able to decrypt it, because only Bob’s private key can do that. If his private key is secret, it doesn’t matter who has his public key.

Public key cryptography is also beneficial for proving that someone is who they say they are and to keep them from refuting that they sent something, a concept called non-repudiation. Let’s say that Bob reviews the document, says it looks good, and sends it back to Alice. Alice wants to confirm that Bob sent the document instead of someone pretending to be Bob. To do this using asymmetric cryptography, Bob can encrypt a hash of the document using his private key and send that to Alice (we’ll discuss hashes in “Hashing” on page 166). Only Bob’s public key can decrypt the file. If the decryption works, Alice knows that Bob sent it, because he is the only one with access to the private key. In addition, Bob can’t later say that he didn’t send the document, because the key pair is unique to him. Unless Bob’s private key is compromised, no other person could have used it to encrypt the information.

Much like in symmetric cryptography, many different algorithms use asymmetric keys. However, these algorithms don’t use block or stream ciphers. Instead, they rely on extremely complex math problems to create their key pairs. For example, one of the first asymmetric algorithms worked by calculating discrete logarithms. Another uses the factoring of large prime numbers. Although the details of these math problems are outside the scope of this book, the keys are the numbers required to solve the problems. The problems are so complex that, without the numbers, it would take a very long time for a computer to calculate the values necessary to solve them. This is what creates the algorithm’s work factor.

For a long period of time, the de facto standard for asymmetric cryptography was an algorithm known as Rivest–Shamir–Adleman (RSA). Named after its inventors, RSA was the most widely used public key cryptography algorithm on the internet from 2000 to 2013. Its main key size was 1024 bits, which is much larger than the keys symmetric cryptography uses. In recent years RSA has fallen out of favor, because in 2013 it was proven that the US government could crack 1024-bit RSA keys using supercomputers. Since then, most systems use either a 2048-bit key, which is substantially more complex, or another algorithm.

One of the more popular replacements for RSA is Elliptical Curve Cryptography (ECC). Although asymmetric cryptography is much slower than symmetric cryptography and creates substantially larger files, ECC is one of the fastest asymmetric algorithms. It can encrypt files 10 times faster than RSA. ECC also doesn’t require nearly as much processor power to use. Its typical key size is 160 bits, but it can also use 256-bit keys. As a result, we can implement ECC on devices that don’t have a lot of memory, such as IoT devices.

Validating Public Keys

After reading about public key cryptography, you might be wondering how Alice initially gets Bob’s public key. This is a bigger problem than you might first expect, because although it doesn’t matter who receives that public key, you must make sure that you’re using the correct public key for the message’s recipient. Doing so is especially important when communicating across the internet, because you have no idea whether the recipient is the person you think they are. They might be a black hat pretending to be someone else. The two main ways to verify public keys are webs of trust and certificate authorities.

Webs of Trust

A web of trust is a network of trusted individuals in which each person vouches for the people to whom they’re connected in the web. For example, Alice knows Bob in real life and trusts him, so she creates a trusted link between her and Bob, and her system accepts Bob’s public key. Bob not only trusts Alice but also Charlie. Therefore, Alice also trusts Charlie, because her trust of Bob transfers to every person Bob trusts (which also includes Danielle, Eric, and Frankie in the web).

Although the web of trust works well for small organizations that don’t want a centrally managed trust system, it doesn’t work well on the internet. With the billions of people using the internet, it would be nearly impossible to make sure that every person in the web of trust was trustworthy. Adversaries could easily exploit the web to trick people into sending them sensitive information. Therefore, only a few applications use the web of trust system. One of the most famous is called Pretty Good Privacy (PGP). PGP is an encryption system primarily used to encrypt email. It was created as an alternative to centralized trust solutions that might become compromised or snooped on by government or private organizations.

Certificate Authorities

The vastly more popular way to verify that public keys are authentic is to use a digital certificate. Similar to a high school or college diploma, a digital certificate is a document that verifies that the public key you received truly did come from the person who sent it. To maintain and manage a digital certificate, a person uses the services of a certificate authority (CA), a third-party organization that creates, manages, and validates certificates for individuals or organizations. Essentially, it tells you whether a public key can be trusted.

CAs provide several different services. One is that they create certificates for people or organizations. When an organization, for example Sparkle Kitten Inc., wants to use public key encryption for its website, it chooses a CA to provide the company with a certificate. That CA then verifies that Sparkle Kitten Inc. is a legitimate company and that the person requesting the certificate in fact represents Sparkle Kitten Inc. Once they’ve done so and received a fee, the CA creates the digital certificate and provides a copy to the company. The CA also creates the public/private key pair that accompanies the certificate. Typically, these certificates expire in a year, at which point anyone who has the certificate will receive a warning. Be mindful of expiring certificates when you’re visiting a site. Even though the owner might just have forgotten to renew their certificate, black hats can use expired certificates to trick you into connecting to an unsafe website.

Another service CAs provide is key management and recovery. Let’s say that Sparkle Kitten Inc. encrypts its entire database using a symmetric key and then encrypts that symmetric key using its CA-issued public key (a common practice for sharing symmetric keys across the internet). The private key would be the only way to access the symmetric key and decrypt the database. Now, let’s say that one of the resident company cats knocks the system that stores the private key out a window, destroying the hard drive so no data can be recovered from it. Without the key, the data encrypted on the database would be lost forever. Fortunately, CAs can retain copies of the public/private key pairs they create in highly secure vaults for just such emergencies, if they provide this service and you pay an additional charge for it. Once Sparkle Kitten Inc. provides the authentication materials needed to prove that it legitimately owns the key, the CA releases the private key back to the company, allowing it to recover the database.

Additionally, CAs provide a highly managed repository of all the publicly available certificates that they manage. This allows anyone on the internet to validate that the public key sent to them is from the right person. For example, when a customer goes to Sparkle Kitten Inc.’s website, they will receive a digital certificate and a public key to use to secure the connection. The customer’s browser will then contact the CA that issued the certificate to verify that the certificate came from that specific CA. If the CA verifies it as authentic, the browser can trust the public key that was sent to it. CAs maintain lists of bad certificates and routinely update their lists so adversaries can’t use compromised or outdated certificates.

Hashing

One of the most widely used forms of cryptography is hashes, which are one-way cryptographic functions that always provide the same encrypted output given the same input. Once data is encrypted using a hashing algorithm, it can never be decrypted. For example, if I put the word CAT through a hashing algorithm, the output might be x5d7nt2k. Every time I put the word CAT into the algorithm, it will come out the same. But if I change even one letter, say creating the word PAT, the entire ciphertext will change to a completely different output; for example, l3loi2jd. Even changing a letter’s case, say from a capital C to a lowercase c, would substantially change the ciphertext. This is known as the waterfall effect, and it’s one of the main purposes of hashing algorithm; that is, making sure that even the most minor change creates a vastly different ciphertext.

It might be difficult at first to understand why we need an algorithm that always creates the same output and can’t be reversed. One of the reasons hashing is useful is that it provides a way to verify that information is authentic without revealing the information. For example, we use hashing to verify passwords. Rather than storing passwords in plaintext—an incredibly unsafe practice that makes them easy to compromise—applications usually put passwords through a hashing algorithm and then store the hash. When users want to log in to their accounts, they enter their passwords, which get put through the same type of hashing algorithm. Instead of sending the password in plaintext, the application sends the hash over the network. When it reaches the system, it compares that hash to the one stored in its database. Because a hashing algorithm’s output never changes if the input is the same, the system knows that the user entered the correct password if the hashes match. Also, this means the user is the only one who knows the value of the password in plaintext form.

We also use hashing to verify files. I can run a file, such as a piece of software, through a hashing algorithm to get a hash and then distribute that hash to the public. When someone downloads my software, they can run it through the same hashing algorithm and compare it to the hash I provided. If both are the same, they know that it’s the original software and hasn’t been modified by another person, perhaps by adding malicious code like a virus.

Many hashing algorithms are available for public use. The first algorithm to gain popularity was Message Digest 5 (MD5). MD5 had a digest size of 128 bits, which means that its output was always 128 bits long, no matter how much data was input. Although this might seem like a lot of bits, it’s not nearly enough to prevent an attacker from cracking the hash (more on this topic in “How Black Hats Break Hashes” on page 171). Due to MD5’s flaws, security professionals replaced it with Secure Hashing Algorithm 1 (SHA-1). SHA-1 has a digest size of 160 bits, which, although better than MD5, is still too small to survive modern hacking techniques. Currently, we use either the SHA-2 or SHA-3 algorithms. Both have much larger digest sizes, typically 256 or 512 bits.

It’s also important to note that users usually don’t have to do anything to use a hashing algorithm. Hashing occurs as part of normal communication between your computer and an application or server. In fact, your computer doesn’t even choose which algorithm it uses; instead, the service to which it’s connecting decides which one it should use.

What Happens When You Visit a Website?

Now that you’ve learned about the different types of modern cryptography, let’s revisit what we know about encrypted traffic flowing across the internet. Let’s say you want to visit a secure website, such as sparklekitten.net. First, the Sparkle Kitten web server sends you a digital certificate. This certificate includes three pieces of important information: the public key for that web server, the type of symmetric key algorithm it will accept, and the CA that created the certificate. Then your system verifies that the certificate is legitimate by contacting the CA (or checks whether it’s signed by an already trusted CA, such as a trusted root authority).

If the CA validates the certificate, your system creates a symmetric key using the algorithm the web server dictates. Because public key encryption is so slow, you must use a symmetric key to send data efficiently to sparklekitten.net. However, to be secure, sparklekitten.net can’t directly send you a symmetric key, because any black hat intercepting traffic from the web server could capture it and break the encryption. Instead, you create a symmetric key and use sparklekitten.net’s public key to encrypt it. Now only sparklekitten.net’s private key can decrypt the symmetric key. You also send a hash of all the data you just sent to sparklekitten.net to use as an integrity check.

Once sparklekitten.net’s web server receives the encrypted symmetric key, it decrypts the key using its private key. Then the web server uses the hash to verify the key’s integrity. If everything looks good, the web server confirms the connection, allowing you and sparklekitten.net to communicate securely using the same symmetric key. This entire process usually takes less than a second to complete. Figure 9-3 provides a breakdown of how this communication works.

Although we use hashing and symmetric and asymmetric cryptography in a variety of ways, securing communications, as in the preceding website example, is one of the more common uses. The main aspect to remember is that systems usually handle keys and encryption in the background. As a user, you don’t need to do anything to secure your system using the power of encryption. In fact, you might not even realize it’s happening, making encryption simple, fast, and effective for all users. However, this lack of awareness can lead to attacks by adversaries you might not even know about.

How Black Hats Steal Your Keys

Circumventing encryption is a central part of being a black hat. An attacker can work around the security encryption provides in many ways, most of which involve another type of attack, such as social engineering, which renders the presence of encryption irrelevant. For example, you might have full-disk encryption on your hard drive, but if an adversary tricks you into revealing the pin code or password you use to access the drive, it doesn’t matter how strong the encryption is. This is also true if they can trick you into negotiating an encrypted connection with them instead of with a legitimate service, as is the case in many man-in-the-middle attacks. If this situation occurs, you share the symmetric key you generate with the adversary, allowing them to decrypt your traffic before passing it on to the legitimate service.

Attackers can also steal keys stored on hardware, especially those that applications use. Keys stored on hardware are generally harder to compromise because the attacker usually has to physically interact with the system to steal those keys. For example, your keys might be stored on a USB drive that needs to be plugged in for them to access those keys. If the adversary doesn’t have the USB drive, they can’t get the keys. Certain vulnerabilities, such as errors in memory storage or problems with how CPUs access information, have made it possible to access keys stored on hardware, although these are normally very rare and difficult to exploit.

These attacks against hardware don’t attack the encryption algorithm but instead affect its implementation. Many cryptography compromises are caused by flaws in how the encryption ran at the time of use rather than how the algorithm is supposed to run in a perfect situation. One of the most famous examples is the wireless encryption standard WEP. It used the RC4 algorithm but chose an extremely small key space and reused information to create keys. This led to a compromise of the standard, even though the underlying algorithm was strong.

Cryptanalysis

The study of cryptography and how to break it is known as cryptanalysis. Modern cryptanalysis searches the inner workings of an encryption algorithm for any possible flaw that might reveal the plaintext of an encrypted message. This includes not just methods for finding the key, but also ways to decode the plaintext without revealing the key.

Researchers use a variety of techniques during cryptanalysis. One such technique is brute-force analysis. As mentioned earlier, any algorithm can be broken given enough time. The problem is, if brute-forcing the algorithm takes a long time—say, years or decades—the information obtained upon breaking it might no longer be useful. Therefore, brute-force analysis also includes methods to reduce the time it takes to correctly guess a key by exploiting flaws in how algorithms process information. For example, 3DES’s main flaw was that, at its core, it used three different DES keys during its encryption process. By analyzing the algorithm, researchers found they could isolate each key separately, essentially turning them into normal 56-bit DES keys, which could then be broken using traditional brute-force techniques, thus neutralizing the strength of 3DES. This attack became known as meet-in-the-middle (not to be confused with man-in-the-middle).

Another cryptanalysis technique is analyzing how plaintext is converted to ciphertext. One of the more common ways of doing this is by using differential analysis, which focuses on differences in plaintext inputs and ciphertext outputs. This method creates various plaintext inputs to a cipher, all identical except for a controlled variable, such as a varying number in each input. The researcher then analyzes the ciphertext output and looks for statistical patterns based on the plaintexts used. Another analysis technique is integral analysis, which considers a block cipher’s substitution method, looking for statistical patterns in how a cipher manages its substitution. Both types of analysis can often discover exploitable flaws, such as the meet-in-the-middle flaw mentioned previously.

Cryptanalysis doesn’t just focus on how the algorithm encrypts plaintext; it also looks at how it interacts with the systems around it. A side-channel attack focuses on elements that are outside the algorithm, such as its power consumption, timing, and even any sounds the encryption process generates that could potentially lead to the discovery of critical flaws.

Asymmetric Algorithm Attacks

Although many cryptanalysis techniques work equally well on symmetric and asymmetric algorithms, the nature of public key cryptography makes it more vulnerable to brute-force attacks. Because asymmetric algorithms rely on complex mathematics to create their key pairs, adversaries could potentially use any method that helps solve a problem faster to break an asymmetric algorithm. For example, your algorithm might rely on the difficulty of calculating discrete logarithms, creating keys from the numbers required to calculate the discrete logarithm between a pair of numbers chosen at random. If a mathematician finds a faster way to do this, they might significantly reduce the work factor of your algorithm.

The security of RSA was diminished when Edward Snowden, an NSA contractor, revealed that supercomputers could accomplish the factoring of prime numbers required to create the public/private key pair. This meant that the typical key length of 1024 bits was no longer viable, and the algorithm had to use 2048-bit keys to be secure. As computer processors continue to increase in power, asymmetric cryptography must constantly update its algorithms and standards to avoid being broken.

Protecting Your Keys

To keep keys safe, many cryptographic algorithms use an initialization vector (IV). An IV consists of random bits that the algorithm adds to the key before encrypting the data. This ensures that even data encrypted with the same key follows different encryption processes. IVs are a great way to protect against cryptanalysis, because they omit patterns from encrypted data.

Another way to protect keys is to limit how often you reuse them. Because keys are more likely to be cracked when used frequently, it’s best to change them as often as possible. You can do this by using a session key, which encrypts data during a single session only, such as during a connection to Google. As soon as you close the Google window or a certain timeout is reached, the session is over and the platform destroys the key. That way, even if an attacker somehow obtains the key during the session, they won’t be able to use it to decrypt future communications. We often use symmetric keys, such as those created during the connection to sparklekitten.net discussed earlier in the chapter, as session keys to secure communications on the internet.

We must also periodically change asymmetric keys. Typically, this occurs on a yearly basis as part of normal certificate renewal, but you can do it more often. A good rule to adhere to when deciding when to update asymmetric keys is that the more traffic is encrypted using the key, the sooner it needs to be changed: a key used twice a year has much less exposure than one used thousands of times a month (or, in the case of a big company like Google, thousands of times a second).

How Black Hats Break Hashes

We often use hashes to check the integrity of certain data, such as a password. By their very nature, hashes aren’t reversible. The hashing algorithm only creates a hash; it can’t be used to decrypt it. So, most normal cryptanalysis attacks won’t work on hashing algorithms. However, hashes aren’t invulnerable to attack.

The main way that adversaries break hashes is by using brute-force techniques. This can be as simple as creating a table containing the hashes of random but plausible inputs and then comparing the hash they’re trying to break to the hashes in the table. Once they find the hash, they know that they’ve correctly guessed the input. But given the amount of inputs possible—a near infinite quantity—this approach is rarely effective unless they have information to narrow down the possible results, perhaps by using other password-cracking techniques, like a dictionary attack or social engineering. But hashes do have a critical flaw that makes them easier to brute-force than other encryption keys: that flaw is collisions.

A collision occurs when two inputs create the same hash output. For example, by random chance, the words sparkle and kitten might both create the hash f90ab7. Collisions in hashing algorithms reduce the amount of time it takes to reverse a hash. Think of it this way: if you had a list of 10 items that you had to get at the grocery store, and each item was in a different part of the store, it would take you, say, 20 minutes to find them all. But if two of the items were right next to each other on the shelf, it would reduce the time it took to find all the items. The more items that were next to each other, the less time it would take to find them all. The more collisions there are in the hashing algorithm, the less time it takes an attacker to go through the various combinations to find the one they’re looking for. Finding a collision can effectively halve the amount of time necessary to guess the input given a specific hash output. More collisions reduce that time further.

Stronger hashing algorithms generate fewer collisions and thus take longer to break. But as a workaround, black hats use a technique that requires a special tool known as a rainbow table. Essentially, a rainbow table is a table of precomputed hashes that have been grouped together by hash output to make a specific output easier to find. So if I have the hash 4fd3cd, the table will attempt to isolate that hash into a specific group of outputs and find the password that created the hash in that group. Once the table finds the password, I can run it through the hashing algorithm to confirm it’s correct.

Salting Your Hashes

The MD5 algorithm is extremely susceptible to collision attacks. It can take seconds, given the right information, to break one of its hashes. SHA-1, although more secure than MD5, is also susceptible. SHA-2 and SHA-3 are more secure due to their hash size. Another way to strengthen hashes is to use salt. Like an IV, a salt is a series of random bits that we add to an input before hashing it. This procedure creates a unique hash that is completely different from the unsalted input.

As an example, let’s say the input kitten creates the hash f903d. To keep the hash more secure, my system might hash kitten by adding a random set of numbers to the end, making the input something like kitten123 (although, in practice, it would add bits to the input’s binary representation rather than decimal digits). Because the system adds new numbers to kitten every time it hashes that input, the hash is different every time. This process also makes it harder to group hashes together in a rainbow table because the output isn’t directly connected to the original plaintext that was hashed.

By adding salt, you increase the number of possible hashes to a point at which collisions become incredibly rare or difficult to discover. As a result, breaking the hashes becomes a very long process, especially if the inputs are complex (see “Type 1: Something You Know” on page 76 for more details). That said, just like encryption keys, any hash can be broken given enough time.

Exercise: Encrypting and Hashing Files

Windows and macOS systems provide several tools to help you encrypt and hash files. In this exercise, you’ll use the tools embedded in Windows 10 and macOS to encrypt a file. You’ll also hash a file and then encrypt it and hash it again to see the difference between the hashed outputs. After completing the exercise, you’ll be able to protect your files and verify whether they’ve been modified. (Only the Pro version of Windows 10 allows for inherent file encryption. For those using Windows Home Edition, I suggest using the VeraCrypt Open Source software to create a place to store sensitive files so they’re encrypted.)

Encrypting and Hashing a File in Windows 10

To practice using file encryption, you need to create a file to encrypt. The quickest way to do this is to open a text editor, add some text, and then save it as a .txt file in an easy-to-remember location; you’ll be entering the file path later. Choose a filename without spaces to make it easier to use later in the exercise. Figure 9-4 shows a super-secret file I created called Secretfile.txt and saved to a folder called Secret.

Next, you need to make sure that no one can modify your secret file without you detecting a change. One of the easiest ways to do this is to create a hash of the file. You can then compare this hash with the hashes of other versions of the same file to confirm the contents are identical. Windows 10 features built-in tools that allow you to create such a hash. To access these tools, open the Command Prompt application, just as you did in the exercise in Chapter 2.

In the Command Prompt window, you’ll use the certutil command line tool. Normally we use certutil to find information about certificates, but it can also create file hashes. Run the tool using the following command:

C:WindowsSystem32> certutil -hashfile C:UsersSparkleKittenDocumentsSecretfile.txt SHA512

SHA512 hash of C:UserssamgrDesktopSecretSuperSecret.txt:
0dd47a4aa75835dfd19b1bb6ed5f8f60cc87492dacf8284ef598229cc258244f67d430e18d7cb770d36ed8b205af1571f42f9956bbe544a362ca191256450eb0
CertUtil: -hashfile command completed successfully.

This command runs certutil using the hashfile function. Recall from the exercise in Chapter 2 that subsequent commands beginning with a dash (–), which are called flags, can modify the original command. Add the path to the file so the system knows which file you want to hash. To enter the file path, start with the hard drive letter (often it’s C), and list each folder in order until you reach the one where you stored your file; be sure to use the backslash () between each folder name. Then choose the hashing algorithm to use. By default this tool uses SHA-1, so here we enter SHA2-512 to make sure we’re using a strong algorithm. Press ENTER to run the command.

The command calculates the hash and then outputs a long string of characters. Copy and paste this string into another .txt file, such as one called SecretHash.txt, to save it for later comparison.

Now that you’ve hashed the file, you need to encrypt it. For this exercise, you’ll use the built-in encryption feature in Windows 10. To access this feature, right-click the file in the filesystem, and click Properties to open the Properties menu. Find the area labeled Attributes at the bottom of the window and click Advanced. From here, you’ll see a few different options. Select Encrypt Contents To Secure Data, as shown in Figure 9-5, and then click OK to encrypt the file using the default AES algorithm.

Now the file is encrypted and secure. Let’s run the certutil tool one more time to compare the hashes of the original (Secretfile.txt) and encrypted versions of the file. Because you already have the hash for Secretfile.txt when it wasn’t encrypted in the SecretHash.txt file, all you need to do now is create a new hash for Secretfile.txt that is encrypted. Keep in mind that any change to the file, no matter how slight, should create a new hash. After running the same certutil command as you did earlier, paste the hash into the text file called SecretHash.txt where you pasted the first hash and compare the two. Notice that the hashes are vastly different, which indicates that something happened to the original file. If you hadn’t made that change, you’d suspect the file had been tampered with for malicious purposes.

Protecting Files Using macOS

Protecting files in macOS is simple because you can access every tool you need from the Terminal using a few basic commands. To start, you’ll need to create a file to use as an example. Open a text editor, create a new file named Secret, and save it as a .rtf file in your Documents folder. You can write any message you want in the file.

Once you’ve created the file, you can hash it to give you a baseline to check against in case the file is modified. Open the Terminal application, as you did in the Chapter 2 exercise. You don’t need any special permissions to use the commands in the Terminal.

To hash Secret.rtf, use the following shasum command. To indicate the home directory, you can use the tilde (~) symbol instead of typing it in the path:

$ shasum ~/Documents/Secret.rtf

2966acd0faf387e024b8b6be50f47450c3c2f7fb  /Users/sparklekitten/Documents/Secret.rtf 

Once you’ve entered the command, it automatically produces a hash. The long string of characters is the hash of your file. Copy this string into a new file called SecretHash.rtf to save it for later comparison.

To encrypt Secret.rtf, you’ll use the openssl tool. SSL is a form of encryption for network communication, and openssl is an open source toolset for that protocol. You can use it to encrypt Secret.rtf by entering the following command:

$ openssl aes256 -in ~/Documents/Secret.rtf -out ~/Documents/Secret.rtf.enc

enter aes-256-cbc encryption password:
Verifying - enter aes-256-cbc encryption password:

This command uses the AES-256 algorithm, which, as you learned in this chapter, is incredibly strong. It then takes an input—in this case, the file you want to encrypt. The output uses a different filename to distinguish between the original Secret.rtf file and the encrypted one, so I suggest adding .enc to the end of the encrypted file’s name so you know it’s encrypted. After you press ENTER to run the command, you’ll be asked to enter a passphrase twice (the second time is a confirmation). Be sure to remember this passphrase, because it’s the only way to decrypt your file.

To decrypt Secret.rtf, you run the same command again but add -d for decryption and reverse the -in and -out paths, as shown here:

$ openssl aes256 -d -in ~/Documents/Secret.rtf.enc -out ~/Documents/Secret.rtf 

For now, let’s leave Secret.rtf encrypted so you can hash it again and compare it with the original hash you created before encrypting the file. Run the shasum command again, but this time, point it to the encrypted file:

$ shasum -/Documents/Secret.rtf.enc 
786109556539fa6571704db78b79fb0d6ae035db 

As you can see, the hash is completely different from the original you created and saved into your SecretHash.rtf file. This hash will help you detect whether your file has been modified, which might indicate that something malicious was added to it.

Using ssh-keygen to Generate a Public Key (Windows 10 or macOS)

Now that you’ve encrypted your file, whether on Windows 10 or macOS, and created your hashes, you’ll need to create a secure means of sending the file. Even though it’s encrypted, it’s always best to send a file using a secure communication channel. To do this, you might need a set of public/private asymmetric keys. You can generate an RSA key pair using the command ssh-keygen, whether you’re on Windows or macOS. For this exercise, I used the Windows command, but it’s the same command for macOS:

C:WindowsSystem32> ssh-keygen

Generating public/private rsa key pair.
Enter file in which to save the key (C:Userssamgr/.ssh/id_rsa): mykey
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in mykey.
Your public key has been saved in mykey.pub.
The key fingerprint is:
SHA256:FCRaZDnraock8vueS1FqjEZmdzcRB+LqXzRvRwqrLxc samgr@DESKTOP-OPFVANO
The key's randomart image is:
+---[RSA 2048]----+
|     .*o*o.      |
|     =oo +       |
|  + o +o+        |
| + + =.o .       |
|  o *.  S   .    |
|...o....E= o     |
| o ooo  o.+ .    |
|  ..+ooo.. .     |
|  .==oo+.        |
+----[SHA256]-----+

A prompt appears asking where you want to store the file. The default path is the .ssh folder in the current user’s directory (in the example the directory is samgr, but it will be whatever the directory is named on your system). The default filename is id_rsa. To select this default press ENTER, or create your own file path if you want to save the key in a particular place. The next prompt asks for a passphrase to secure the key against misuse. If you add a passphrase, you’ll need to enter that phrase every time you use the key. Enter a strong passphrase and then reenter it at the next prompt. Once you do this, your key is generated and saved to the .ssh folder in your Users directory.

The .ssh folder should now contain two files. One is id_rsa, which is the actual private key. You can open this file in Notepad to view the private key. The other file is a publisher file that contains the public key. You can also open this file in Notepad to see the public key. Now you have a public/private key pair that you can use for encrypted communication when necessary.

Knowing how to create a hash, encrypt a file, and generate public/private key pairs allows you to encrypt your communications to ensure their safety. Using these techniques, you can protect your files from unauthorized access and determine whether they were modified. You can also check files you download, especially executables, to see whether their hash matches what the vendor posts as the real hash. If it’s different, it’s possible a black hat changed the file to add malware or other malicious code to it.

Conclusion

Cryptography is a complex subject with lots of moving parts. This makes it challenging to know how to keep your communications secure. By recognizing the basic structure of how cryptography is used in the modern world, with symmetric and asymmetric encryption and hashing working together to create secure connections, you’ll have a better understanding of how to keep your connections secure from adversaries trying to steal your data. Although there are numerous ways that black hats can steal keys or crack encryption, using cryptography correctly works well to mitigate the risk of an attack being successful. One easy way to ensure that it’s properly implemented when you’re connecting to a website or using a protocol is to check for the S.

What do I mean by check for the S? Many protocols use the letter S to indicate that they’re secure—for example, SSH (for secure remote access), FTPS (for secure file transfer), and HTTPS (for secure web connections). By contrast, Telnet, FTP, and HTTP provide the same services without encryption. Although not all secure protocols have an S in their acronym (WPA is a prime example), looking for the S is a good reminder to check for encryption when sending or storing important data. The context in which you’re using the protocol determines where you need to look for the S. For example, when browsing the internet, look at the website name to ensure it starts with HTTPS instead of HTTP.

It’s up to you to verify that your system sets up the encryption correctly, whether you’re shopping online or sending sensitive tax documents to your accountant. You do this in the security settings, either on your computer or in a software application you’re using. By understanding how encryption works, you can do a better job of ensuring it’s working the way it’s supposed to. This guarantees that whatever you’re doing or sending is hidden from attackers, as long as it remains encrypted.