Encryption is a lot like garlic. It's a
versatile part of many security recipes, but not to the
exclusion of other ingredients.
Some companies believe that by encrypting data, they're solving
most security problems, and they don't care whether attackers sniff
packets or break into systems -- because the data will be useless
to them if it's encrypted. But relying too much on encryption could
lull companies into a false sense of security and keep them from
paying necessary attention to network and operating system
security, a tendency that could come back to haunt them.
In other words, encryption is not a solution to security
concerns but a way to transfer the problem, said Benjamin Jun, vice
president at consultancy Cryptography Research. "Instead of
managing 100GB of critical data, you only have to manage a key,
which is much smaller in size," he said.
Before implementing any encryption, companies need to fully
understand the security problem they want to solve. "This may sound
easy, but it can be quite difficult," Jun said.
There are instances where encryption will solve particular
concerns, and other places where different solutions are needed.
For example, protecting data on laptops is one problem many
companies deal with. It's a fact of life that laptops will be lost
or stolen. Encrypting the data on them makes a lot of sense.
On the other hand, Cryptography Research, in another example,
was faced with a different problem. How could the company use
e-mail and have standard web access on the same network that it
uses to transport sensitive customer data? Instead of turning to
encryption, the company opted for two independent networks, one
used for e-mail and web browsing, and another used exclusively for
sensitive data. "We couldn't proactively stop everything at the
firewall," Jun said.
Companies have to consider many factors when considering
encryption, like key size and the length of time they want to
secure and store sensitive data.
Every few months, stories emerge about the latest key size to be
cracked. In October, RSA Security's RC5-64 cipher, the company's
64-bit encryption key, was cracked. To be fair, however, it did
take the equivalent of the population of a large city and its
computing power nearly five years to break a single key. Using
64-bit encryption would be far less risky than other security
activities.
Experts, however, warn against using 64-bit ciphers because of
Moore's Law. In other words, computing power increases at such a
rate that, in the not too distant future, systems would be able to
crack such encryption in a much shorter amount of time.
So when one is considering a key size, the amount of time that
data will need to be secure comes into play. In theory, encryption
can be foiled by random tries, so a longer period of time gives an
attacker a bigger window of opportunity to find the key.
Jun warns against focusing too much on key size. "It's like
arguing about how good the deadbolt on your front door is. The lock
may be great, but your house has windows which pose a much greater
security risk," he said.
Much like leaving valuables on the kitchen table due to a false
sense of security given by deadbolts, people who rely too heavily
on encryption may be opening themselves to other risks, Jun said.
There have been some implementations that have been vulnerable
because the random number generator was faulty, Jun said.
So what if you want to store some important data for 20 years?
Well, Ronald Rivest and Adi Shamir, two of the developers of the
RSA algorithm, recently suggested 2,048-bit keys for such
long-term, important storage during a panel discussion on
cryptography at the recent RSA Conference in San Francisco.
Jun recommends using 3 DES or AES (either 128-bit or 256-bit)
for such long-term storage. But users shouldn't get too bogged down
about the algorithm or key size they use. For the former, pick the
ones that have been around for a while and are well tested. The
more established encryption algorithms are better tested for
security than virtually any other piece of the security
infrastructure.
This article originally appeared on
SearchSecurity.com.