Above is a section of a private key that was previously used to log into a webserver. This is a partial example of asymmetric encryption.
Part 1: What Does Encryption Do?
As lawyers (and pretty much just as humans who exist in a digital world) we’re given a lot of surface level advice about encryption. We’re told that we need to encrypt our data in order to keep it safe. We need to encrypt our email, encrypt our phones, encrypt our text messages, and our client files. We should encrypt all the things we hold dear in order to protect them, and even those we don’t just for good measure. Ciphers and cryptography will save us all from being embarrassed (and, more importantly, from being disbarred). Encryption will keep all the bad actors at bay. And if it doesn’t, encryption will render them harmless.
But what does this mean? Like, literally. What are we supposed to do with that? Should we just encrypt everything we touch? If so, why isn’t that just the default? Why would our email providers even allow for non-encrypted email? And why wouldn’t our hard drives just naturally be in a state of encryption? If it’s so important, why do I even have to think about encryption?
Let’s Encrypt Everything
Unfortunately, as you know through your own experience, encryption doesn’t come without practical costs. Depending on the type of encryption you’re using, and the purpose of that encryption, the effects can differ significantly. Encryption may noticeably slow your process down, it may negatively affect the user experience, or it may simply make it impractical to communicate between two parties. When this happens, people tend to abandon these security mechanisms for ease of usability. And abandoned security is useless security.
What should we encrypt, then?
Well, as we’re so fond of telling everyone else. It depends.
It depends on various situational factors (typically balancing security versus usability). Which means, each person needs to be able to make at least rudimentary encryption decisions on their own behelf. As you can imagine, if we could slap a system-wide solution on the problem, we already would have – and I wouldn’t have to write this. But you can’t. So, the security of your clients’ information depends on your office’s ability to make day-to-day decisions based on the facts at hand. — That sounds promising, right?
To make this work, you (and those in your office) should have a basic understanding of what the purposes of encryption are, and how we typically achieve those purposes. I attempt to explain some of that below.
I know what you’re thinking: “This is the most interesting thing ever!!” And, “I can’t wait to read more about how data is turned into other data!” If that’s the case, you’re in luck. We’ll follow this article up with some ideas on specific data to encrypt in your office, and we’ll look at some common encryption tools to achieve that. Then we’ll move on to a discussion of some of the limitations and pitfalls of particular encryption techniques.
Uses and Common Forms
Before we get started, we need to make sure we’re on the same page – encryption can be a nebulous term. In this article, when we talk about encryption, we mean the literal changing of a value or values (i.e. a sentence) and turning it into something that cannot be read without decrypting (if it can even be decrypted). For example, if we were to encrypt something using the ROT1 cipher (which you are probably already are familiar with), then it would look something like this.
I am an encryption! ⇒ J bn bo fodszqujpo!
In the sentence above, we replaced every letter with the one to the right of it in the Alphabet (e.g ROTate 1) in order to obscure the meaning of the sentence. It’s a simple cipher that’s pretty easy to crack, but it can be effective if you are trying to hide something from an eight-year-old.
There are, obviously, many techniques other than ROT1 out there. Some of them are simple, some are extremely complex, some are easily decrypted, while others are never intended to be decrypted again. But this gives you the idea of what we mean by encryption, now let’s look at what we can do with encryption.
Encryption Goals:
Encryption can generally be used to accomplish four goals. All security tasks that can be achieved through encryption fall into one or more of these categories. Keep these ideas in mind as we go through the rest of these articles and when you are making encryption decision.
Authentication, in this situation, is not the “user authentication” you think of when accessing a device or program (although this is certainly a portion of that process). Here, Authentication is much more focused. It means confirming that the sender of data is the entity that the message claims sent the data. Essentially, it’s assurance that Party 1 has not sent information to Party 2 and tried to make them think that Party 3 was the originator.
For example, if I send a request to my online banking application asking them to show me my account information, the bank wants to be sure that it is me who’s sending this request. In order to confirm my sender identity, we (the bank and I) would have agreed on a method of verification prior to my sending this request, likely utilizing one of the forms of encryption discussed below.
Confidentiality is the most obvious use of encryption mechanisms. As is shown with the ROT1 cipher above, we use encryption to change information in a way that third parties have difficulty reading, but our intended recipient does not.
This would be the goal when protecting your client files, or sensitive email that you send to other parties. However, this form of encryption requires pre-transmission communication between the parties in order to establish what method is being used to decipher the information. If I send you the message above, in order to read it, you would need to know that I was using the ROT1 cipher (unless you could figure it out on your own – which wouldn’t be very secure).
Validation of Integrity is basically determining that information you receive is still in the state it was in when it started its journey. Essentially, we want to make sure that a third party did not intercept a communication, change it in a way that suits their needs and then send it on as if it came from the original sender.
Non-repudiation is used when you want to be able to keep a party from denying that they took an action. For example, when Parties 1 and 2 sign a digital contract, we want to be able to prove to Party 3 that this happened, and we want to prove it in a way that Parties 1 and 2 cannot feasibly deny it.
Yes, this is different from Authentication. Authentication only works to verify that what the sender says is true. If the sender denies that they transferred the information, Authentication can’t independently prove otherwise.
Encryption Methods:
To accomplish these goals, there are a lot of different encryption mechanisms available, depending on your specific preferences. The style of these mechanisms, however, can be broken-down into three categories.
Symmetric Encryption, or secret key cryptography, is probably the simplest form to understand. We’ve all used it, and we were aware that we were using it at the time. Here, the sender applies a secret key (think key like puzzle key, not key like open a door), to their information to encrypt it. Then the receiver applies that same key to the information to reverse the process.
Pretty simple, right? The catch in this one is that the parties need to have agreed upon a key prior to the communication and they need to keep that key a secret. Additionally, the key needs to be complex enough to make it infeasible to crack. Keep in mind, however, that, given enough time and computing power, any key can be cracked through brute force.
Asymmetric Encryption, or public-private key pair, is a bit more difficult to visualize. While you’ve certainly used this method (quite frequently, in fact), you may not have been aware of it at the time. In this case, a party creates a private key and a public key that correspond with each other. The party uses their private key to decipher information that has been encrypted with the public key. Importantly for this method, the information cannot be decrypted using the public key.
For example, Party 1 wants to allow Parties 2 and 3 to communicate with her directly but she doesn’t want the other party to know what was said. In order to do this, she creates a pair of keys and sends the public key to both of them to use. Party 2 decides that he wants to send a secret message to Party 1, so he uses the public key to encrypt the message and sends it on to her. Even though Party 3 has access to the public key and could create an encrypted message for Party 1 himself, Party 2 can rest assured that only Party 1 can decrypt the encoded message. In this way, it doesn’t matter if Party 3 gains access to the message while it’s being sent (in transit) or not.
Hashing, is a method for encrypting information of an arbitrary length into information of a fixed length. This method is inherently one-directional, and (a good hash function) is practically infeasible to reverse engineer. However, given a specific value, the hash function will return the same exact final value each time. Therefore, hash functions are helpful when trying to find out whether or not something matches. It is not useful if we ever need to read the information that has been hashed again.
88567dd4e1f305ce4dce12877c7c8e298dc24333be1465086187add11439b203
Above is the SHA-256 hash value of the phrase, “This is a sample client communication!”
A common example of this is when a website validates your password. It’s very bad practice to store passwords in plain text so, any reputable website will instead store the hash value of your chosen password (something like the example above). When you log-in, the entry that you send to the webserver is then sent through the same hash function and the result (the hash value of what you entered) is compared to the stored information (which is the hashed value of your original password). If they were both the same word or phrase to start with, the hash values will inevitably match and you will be granted access. You could imagine that this same method could be used to verify that a transmission had not changed in transit if it is sent along with its hash value.
Conclusion
You’re not gonna win any Quiz Bowl competitions with the information above. However, it should help you to make informed decisions about your client data in the future. Obviously, it’s not extremely important to know exactly what happens when an encryption method is employed (I mean, unless you just dig cryptography). It is important, though, to understand the basic ideas. It should help us spot our vulnerabilities. After all, a security system is only as good as its weakest point.
As always, if you have any questions, feel free to leave a comment below and we’ll do our best to help you with it (or at least point you in the right direction). And be safe out there. Try not to get Phished.
