• United States




5 myths about data encryption

Sep 24, 20154 mins

Encryption has a bad rap and far too often protection schemes are deployed foolishly without encryption in hopes of protecting data.

It’s a heartache, nothing but a heartache. Hits you when it’s too late, hits you when you’re down. It’s a fools’ game, nothing but a fool’s game. Standing in the cold rain, feeling like a clown.

When singer Bonnie Tyler recorded in her distinctive raspy voice “It’s A Heartache” in 1978, you’d think she was an oracle of sorts, predicting the rocky road that encryption would have to travel.

Just a year earlier in 1977 the Encryption Standard (DES) became the federal standard for block symmetric encryption (FIPS 46). But, oh, what a disappointment encryption DES would become. In less than 20 years since its inception, DES would be declared DOA (dead on arrival), impenetrable NOT.

How could that possibly be?

A brief history of encryption

Based on an algorithm developed by IBM and modified by the National Security Agency (NSA), DES was at first considered unbreakable in the 1970s except by brute-force attack — that is, trying every possible key (DES uses a 56-bit key, so there are 2^56, or 72,057,594,037,927,936 of them).

By the late 1990s it was possible to break DES in a matter of several days. This was because of the relatively small block size (64 bits) and key size and advances in computing power according to Moore’s Law. Eventually, unbreakable encryption would achieve a resurrection of sorts.

Although originally approved for encryption of only non-classified governmental data, encryption AES was approved for use with Secret and Top Secret classified information of the U.S. government in 2003.

Encryption AES is a symmetric block cipher, operating on fixed-size blocks of data. The goal of AES was not only to select a new cipher algorithm but also to dramatically increase both the block and key size compared with DES. Where DES used 64-bit blocks, AES uses 128-bit blocks. Doubling the block size increases the number of possible blocks by a factor of 2^64, a dramatic advantage over DES. More importantly, in contrast to relatively short 56-bit DES key, AES supports 128-, 192-, and 256-bit keys.

The length of these keys means that brute-force attacks on AES are infeasible, at least for the foreseeable future. A further advantage of AES is that there are no “weak” or “semi-weak” keys to be avoided (as in DES, which has 16 of them).

Few today dispute the virtual impenetrability of AES encryption. Via AES, only those in possession of management keys and/or who are granted permission to access the encrypted data can read/use the encrypted data.

Despite all that, data encryption has developed a bad rap of sorts and far too often data protection schemes without encryption are employed to guard against the theft of sensitive data.

Here are five myths about data encryption in today’s marketplace: 

1. Encryption is too complicated and requires too many resources

In fact, data encryption can be very simple to implement and manage. The key is to understand the types of data you need to encrypt, where it resides, and who should have access to it. 

2. Only businesses that have compliance requirements whereby encryption is mandated by law need to use encryption.

Sensitive data should always be encrypted – whether it is mandated or not. 

3. Encryption will kill database and application performance

Performance of applications, databases, servers, and networks is a top priority of IT and end users. When designed and implemented properly, encryption can not only protect the critical data running through those systems, but its presence can have minimal impact on performance that is not perceivable to users.

4. Encryption doesn’t make data stored in the cloud more secure

Storing encrypted data in the cloud is more secure than storing non-encrypted data in the cloud. Too often, those who store data in the cloud do not know where their data is stored, nor do they know who has access to the data; all the more reason that all the data sent to the cloud should be encrypted, with the encryption keys in your control. 

5. Encrypting data is more important than key management

Too many organizations fail to manage their encryption keys, either storing them on the same server as the encrypted data or allowing a cloud provider to manage them; such pointless behavior is similar to locking the door to your automobile and leaving the key in the door.

Special thanks to Sophos for research leading to this article. Disclosure: Sophos is a business partner of Towerwall. The opinions expressed in this Blog are those of Michelle Drolet and do not necessarily represent those of the IDG Communications, Inc., its parent, subsidiary or affiliated companies.


Michelle Drolet is a seasoned security expert with 26 years of experience providing organizations with IT security technology services. Prior to founding Towerwall (formerly Conqwest) in 1993, she founded CDG Technologies, growing the IT consulting business from two to 17 employees in its first year. She then sold it to a public company and remained on board. Discouraged by the direction the parent company was taking, she decided to buy back her company. She re-launched the Framingham-based company as Towerwall. Her clients include Biogen Idec, Middlesex Savings Bank, PerkinElmer, Raytheon, Smith & Wesson, Covenant Healthcare and many mid-size organizations.

A community activist, she has received citations from State Senators Karen Spilka and David Magnani for her community service. Twice she has received a Cyber Citizenship award for community support and participation. She's also involved with the School-to-Career program, an intern and externship program, the Women’s Independent Network, Young Women and Minorities in Science and Technology, and Athena, a girl’s mentorship program.

Michelle is the founder of the Information Security Summit at Mass Bay Community College. Her numerous articles have appeared in Network World, Cloud Computing, Worcester Business Journal, SC Magazine, InfoSecurity,, Web Security Journal and others.

The opinions expressed in this blog are those of Michelle Drolet and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.