Cryptography Limitations – SY0-601 CompTIA Security+ : 2.8

Although cryptography provides significant functionality, it’s not without tradeoffs. In this video, you’ll learn the use and limitations of using cryptography technology in practical use.


Although cryptography provides us with a number of very powerful capabilities, there are still limitations into how we use cryptography. If you were to examine the way that cryptography has been implemented with one application and compare that to a different application, you’ll probably see a very big difference between those two. Those differences allow us to customize the way that those different applications will be using this cryptography. But, of course, to integrate with that we need to understand how that cryptography was originally implemented.

And it’s the implementation of the cryptography that is often its biggest weakness. For example, you may use hashing to store passwords. But if you don’t apply a random salt to that password hash, then you may not be storing things as securely as you could be. If you’re in charge of implementing some type of cryptography on your network, your firewalls, or your VPNs, then make sure you do your homework and that you’re implementing the correct type of cryptography for your purposes.

One of these considerations is speed. We have to make sure that the application can perform quick enough with the type of cryptography that we’re using. We have to think about the overhead associated with encrypting or decrypting this data. That means we need to make sure that the CPU can handle this encryption and decryption process and that we have enough power in the system to be able to support that. When we implement this encryption, it will put additional load on the CPU. It will use more power and more battery life. And we, of course, need to consider that when implementing the cryptography.

If we’re using a block cipher to be able to encrypt data, it’s important to know that if we’re encrypting 16 bytes of data, that usually the encrypted information is also 16 bytes. So by using this encryption, we’re not increasing the amount of storage that we might need. The only place where that does become important to consider is when we might be encrypting less than the size of the block.

For example, if your block size is 16 bytes and you’re encrypting some data that is 8 bytes in size, you have to fill in the other remaining 8 bytes so that you have a full 16 bytes to be able to encrypt. If the block cipher is 16 bytes in size, then the amount of data that’s encrypted has to be 16 bytes as part of its plain text. That means that we would have to add another 8 bytes to this, which would effectively double the storage size of what we happen to be saving.

We also have to think about the size of the keys that we’re using during the encryption process. And generally, larger keys will make it much more difficult to brute force. A good example of where a weak key could be a significant problem was in the wireless encryption that we used for WEP. The weak initialization variable that was used in RC4 resulted in cryptographic vulnerabilities that made it very easy for someone to gain access to our wireless data.

You also have to consider how long someone’s willing to wait for this encryption or decryption process. It takes time to perform encryption or hashing. And, of course, larger files are going to take a larger amount of time. You might also want to consider the type of encryption you’re using. If you perform asymmetric encryption, it may take much longer to perform that function than if you had used symmetric encryption.

It’s also important to think about how long this encryption type is able to be used. As time goes on, our CPUs get much more powerful, and we’re able to do brute forcing much faster than we have in the past. A good example of this is when Data Encryption Standard, or DES, was released in 1977, it was considered to be a very secure encryption type. But only 22 years later in 1999, we were able to put together technology that was able to brute force DES in just 22 hours. If you use larger keys instead of smaller keys, you might be able to extend the life of that encryption method.

Cryptography also relies on randomization. If you know what’s going to happen next, you may be able to predict what’s going to happen with the encryption. So having some type of random number generation that can’t be easily predicted is crucial for any type of cryptography. For example, Cloudflare has their wall of lava lamps that provides them with a type of randomization that they can then apply back to their encryption. And, of course, if you’re creating some type of passphrase, it needs to be something that can’t be predicted. And something very random is a much more powerful passphrase than something that can be predicted.

In most implementations, the process for encryption doesn’t change. But the key that’s used during the encryption process does change. However, changing that key can add additional overhead. So using the same key is something that’s commonly seen in a number of encryption mechanisms. The problem with that, of course, is that if someone gains access to that key, they would effectively have access to everything that was encrypted using that key. So although there is some work involved to change that key, there are some significant security advantages to doing that.

It may be that some of the devices you have don’t allow you to change the key. For example, Internet of Things devices are relatively straightforward in simple devices and, in some cases, have the key embedded in the firmware itself. That means if you need to change the key, you have to update the entire firmware for that IoT device. And it’s in these Internet of Things devices where we start to see large differences between the requirements for encryption and the resources that we might have available to provide that encryption.

IoT devices have a limited CPU. They have just enough memory to keep the system running and, in some cases, are running on battery power or limited power sources. If this IoT device is monitoring something in real time, there’s not a lot of cycles available to perform encryption or decryption. So there needs to be a happy medium between security on the device and having the device application work properly.

You might also find that these IoT devices are not really built for security. So it’s up to you to determine what’s going to be required to provide the proper amount of security and the security updates for those Internet of Things devices.