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.