Transcription
Change is the only constant. If you don't like the way things are now, it's going to change. Also, if you do like the ways things are, well, that'll change too. That's true in life. It's also true with technology. Set it and forget it is a prescription for disaster. Brittle, inflexible systems will collapse under the weight of new operating conditions. But systems built with the assumption that things will change will be more resilient and are able to weather the inevitable storms.
When it comes to cryptography, the goal should be crypto agility, an adaptable system that can roll with the punches because there will definitely be punches. Let's take a look at why you need this, what it looks like, and how you can achieve it. So why do you need crypto agility? Let's talk about that. It turns out that even our best tech has an expiration date. Algorithms come and algorithms go. You don't buy that milk and leave it on the shelf for a month, it's not gonna taste good. The same thing is true with our crypto. So let's take a look at a few historical examples so you can see what I mean.
I'm gonna start off with what was considered the gold standard of cryptography for many years, the Data Encryption Standard, DES, very clever name, right? In this case, this was invented actually by IBM in 1977. We came out with this as part of a government contract and as I said, it was the gold standard, used in private industry and public. Everyone was using this. It was considered the best. And it was great in 1977. However, 20 years on, it was broken. It was proven to be broken. The crypto community already realized that systems had gotten stronger and faster over the course of those two decades. So there was a need to basically show that we needed a replacement because a lot of people still kind of had their heads in the sand on this. So this was proven at the RSA security conference in 1998 where a computer called Deep Crack did the first break of DES doing a brute force attack, just basically trying all the keys. And by the way, leveraging the systems of a lot of other people who volunteered spare cycles on their PCs, like me, as part of a grid project in order to break this in less than a day. First time that had ever been done publicly. But as a result of that happening, it proved to the whole world that DES, in fact, had expired. It had served its useful purpose. And in 2005, eventually DES was deprecated. But look at the time it took. It wasn't like as soon as it was broken, we had a replacement and it was deprecated. It took some time.
Let's take a look at another example. And these things that I'm referring to here, we know as symmetric ciphers. So they're the crypto algorithms where they use the same key on both sides, that's the symmetry. We use it to encrypt, we use the same key to decrypt. So it's very simple in that regard. RC4 was another really popular example back in the day. 1987 is when this was invented. And it served well for a period of time. But in 2001, it was shown to be broken. And then a couple of years later, well, no, not a couple years later. It was a long time later that we finally got this one deprecated. So again, we see that gap repeating. The worldwide community kind of got together and said, until we get a brand new algorithm, why don't we reuse DES? It's been shown to be good. So they came up with a thing called Triple DES, where you basically did three different DES operations. You have one key, two keys, three different keys, each one of them 56 bits long, and you do an encrypt of the data. Then you decrypt with the second key, then you do a third encryption with the third key. And that way you end up with something that's stronger. And it's already based on something we knew would work. So it was kind of a side step to having to come out with a brand new standard. Well, this was basically came into existence and got standardized in 1995, because notice at that point, we already realized that DES was getting weak. It was long in the tooth, and we needed a replacement, and this was a short-term successor to it. However, in 2016, this was shown to be broken. And then a couple of years later in 2018, we deprecated that.
And finally then, the U.S. National Institute of Standards and Technology did a great job here where they went and said, we need a replacement for all of these symmetric ciphers, something that we've really thought through, and we're gonna call it the Advanced Encryption Standard. And they put out a call for proposals and the winner was chosen, and we've been using AES ever since. I think that was about 2016 that that occurred. AES uses 128-bit encryption in most cases, although it can support more. But that was really common certainly when it first came out. So there you can see three different examples of symmetric ciphers, and they were good until they weren't and then they needed to be replaced. And now we have the replacement.
So what's the next thing on the horizon? What's the thing that's gonna cause us to need to change all of this again? And the answer is, it's the quantum menace. In other words, quantum computers will be able to break AES in its current form, if we don't do something about it. And the something we're gonna do about it, in particular, is instead of doing AES at 128 bit, we're going to double the key size to 256 bits. It seems that, according to the crypto experts, if we make a move like that, then even the strongest quantum systems that we can foresee in the foreseeable future will not be able to break that. So just double the key size. But it means we gotta go back and change all of the implementations we did with 128-bit AES.
Now I just talked about symmetric ciphers, but you can imagine if there are symmetric ciphers, there's also gonna be asymmetric ciphers, and there are. And we use them all the time. The most common of these is RSA. The RSA algorithm is one where it's named after the first letters of the three men who created this one, their last names. And RSA is designed so that you have a public key and a private key. And what you encrypt with one, you can only decrypt with the other. So it's a pair of keys. We use it for exchanging symmetric keys. We use it as part of PKI, public key infrastructure, digital certificates, all of that stuff relies on RSA capabilities. So we need that kind of a feature in order to make all of this stuff work. Now RSA, however, we can't just double the key size on this. We're gonna have to do a lot more. In fact, we have to come up with brand new algorithms. We need post-quantum crypto algorithms or quantum-safe algorithms, quantum-safe cryptography. Brand new algorithms. We can't just double the key size here, but here we need new algorithms and now we got to figure out how we go back into all of our code and change that.
It's inevitable that you're gonna have to change crypto algorithms over time. We've done it in the past, we'll keep doing it going forward. I just showed you examples of that already. Replacing these though, is slow, costly, and risky. Nobody wants to do this. So what's the answer to all of this churn? It's a thing called crypto agility. And crypto agility is essentially the ability to rapidly adapt cryptographic mechanisms in response to threats, technological advances, or vulnerabilities without disrupting infrastructure or business processes. So that's what crypto agility is. With crypto agility, these negative impacts can be minimized.
Let me show you what I mean. So let's start off with, you've written some code, your organization has a bunch of applications sitting out here, and these applications need to do certain cryptographic operations. So we've got our code going along and then all of a sudden they need to encrypt something. So I've embedded the code to do the crypto right there. And then I continue on my merry way. I might've gotten that from an open source repository. I found out where was an implementation of that encryption function. And then, I just embed it right there, copy and paste, easy. Then I come along over here and this application needs to decrypt that section. So I'm going to pull the portion of code for that and embed that directly in. And then I do the same thing over here and maybe I do an encrypt and then later in the same application, I do a decrypt and then I continue. So everything's working fine until the day we find out that this crypto algorithm is broken. And so is this, and so is this, and is this. Now, what do I do? Well, I'm gonna have to now go in, crack open the code in each of these cases and replace this vulnerable code with a better algorithm, or a stronger key strength, or something like that. That's gonna take us time. It's gonna be error-prone. It could be that while I do that, I mess around and cause something else not to work. This is not ideal. And I've just shown you a very simple example. An organization may have tons of these actually in their infrastructure.
So what's a better way to do this? A better way is instead of putting the code to the crypto algorithms directly in the code, put it here and then make calls. This is a more modular approach. When I do this, now if I need to make a change, I just change it here. All of these things are calling in one place. It's actually more efficient as well in terms of the way that we create this. And then when the post-quantum era comes, or we're ready to deal with some other threat, maybe someone finds a vulnerability in an algorithm that has served us very well for a long time, then we come up with our new algorithm and we just plug it in here. And we can use, for instance, our post-quantum crypto algorithms, plug it in here, and now the code inherits all of that capability automatically.
Okay, how are we going to achieve crypto agility? It starts off with discovery. I have to know what it is that I'm gonna need to fix. And you need to know where all of your instances of cryptography are in your environment. You're gonna need tools in order to do scans of the code and find where all those are. And from that, you're gonna generate a cryptographic bill of materials, a C-bomb, that's basically your inventory. That's where we're gonna start attacking from. From there, I evaluate all of the instances of cryptography that I have and figure out which ones of them are weak, which ones are just not quantum safe, which ones are using deprecated algorithms, which ones use key lengths that are too small, all that sort of stuff. Then from there, I need to prioritize. If you're like most organizations, you're not going to be able to fix all of these in a day. One organization that I know of has more than 4,000 instances of cryptography in their environment. They cannot fix all those in a day. So they're going to have to figure out which ones need to go first, then next, then, next. And then ultimately, I'm going to go fix those things. I'm gonna remediate all of the instances that are weak. With the goal, if I've got to go in and lift open the hood, or crack open the code, use whatever analogy you like, and make these kinds of changes, why not go ahead and build it with the idea of making it agile in the first place? Now we can make crypto agility so that if we have to go back through this process again, it's gonna be relatively easy to do.
As I said before, change is the only constant. We know from the past that crypto algorithms get stale and need to be replaced. We also know that quantum computers are coming. And these will be able to break the ciphers in widespread use today. So it's best to prepare now and build flexibility into the process. So while you're under the hood, updating your crypto for the quantum era, go ahead and future-proof it with a more adaptable approach. That approach is what we call crypto agility.