Today’s Security Tip of the Day deals with a subject that is pretty abstract to most people.  Cryptography is referred to as the science of secret writing. This is not a new concept that came about with the development of the Internet.  Cryptography has been around for hundreds of years dating back to the days of the pyramids and the Ancient Egyptians. Today we use the concept introduced by them to develop a safe, secure method of communicating, exchanging and validating data between computer systems. 

Whether it is very sensitive information that needs to be transmitted via an email, online financial or banking transactions, or any other data that you would rather not have the whole world knowing about, encryption can help you protect the data.  When email, data, etc is transmitted via the Internet with no encryption, it is possible that someone could eavesdrop and intercept the communication.  Good encryption assures that the data remains intact and maintains the confidentiality, integrity, authentication and non-repudiation of the data received.

There are 3 general types of crypto algorithms:

                 Secret Key – Symmetric containing single or 1-key encryption

                Public Key – Asymmetric containing dual or 2-key encryption

                Hash – One way transformation with no key encryption

There are many different methods of data cryptography and a variety of vendors providing encryption software.  All of the encryption programs perform two distinct operations: Encryption, encoding the data in such a way as to conceal the information and Decryption, the process of transforming the data back to its original form. 

There are advantages and disadvantages to each and differing opinions of which is best and when each should be used, but most everyone agrees that encryption plays a crucial role in data protection.  And in most environments today you will see a mixture of algorithms in use.  Each situation has its own set of requirements.  In today’s world all Security Administrators and users need to be conscious of the significance of the data they are dealing with and the need to secure that data.  

 Tell us what you think.  What if anything is your company doing?  Have a good program you are using, let us know.

Update: 

A couple of responses that we received regarding encryption provide good insight into the use of Encryption. Here they are in part:

Email 1

From Lyal: Not all are right in every situation. We typically find our clients chose 2 or 3 of the above methods, just to ease deployment and ensure compatibility.

It doesn't look like open source crypto tools (and there are some good ones) are oriented towards server protection - they all operate in user land, or are oriented to personal key management, not dual control, split knowledge etc.  If the adopted StrongKey or similar, it'd be much easier in the corporate world.

Email2

From a reader that does not want their name published:

I look forward to seeing what comes of the proposed discussion about which crypto, SecKey/PubKey/Hash is "best."  

Me thinks the answer is none...  But that's only one dweeb's vote.  

What matters more to me is the context in which crypto is being used to protect data.  

When crypto is used there are several necessary bases also need to be covered:  

1)  for data "on disk"
 - strong user authentication
   (for the obvious reasons, but also for granular,
   role-based access to encrypted assets
 - full disk encryption  
   (strong FDE means you can Secure Delete by good key
   management and delete-by-destruction of keys, rather
   than resorting to DoD overwrites -- which isn't Good
   Enough for Top Secret or better;  more and more caches
   are being implemented as encrypted stores, with
   decryption occurring only as data moves into "volatile
   memory")
 - folder/file encryption  
   (for granular, role-based access to sensitive/regulated
   assets on otherwise encrypted disks/partitions)
 - never store passwords on the devices to be protected
 - never store keys in-in-the-clear (store hashed keys,
   if they have to be stored on-device)  

2)  for data "in motion"
 - two-way authentication and two-way encryption on the
   "wire"  
   ideally with unique *client* and "server" certificates
 - don't use known-to-be broken encryption (SSL1/2)

Most sensitive/proprietary/regulated data will require both sets of protection.  What useful data that resides on disk is not accessed over some kind of network as part of production???...  Almost none.  Yet both bases are rarely covered.  

Take away any one of these elements and the crypto effort will not be for much more than naught.  

 ...  

Gartner has recently begun beating the drum that FDE, alone, Ain't Good Enough.  This after thoroughly trouncing F/FBE-only, for years, for inadequately protecting data.  

It takes both forms of "at-rest" crypto to significantly mitigate risks of data loss/leakage.  

Crypto also has to be *relatively painless* for the end-user to live/work with, otherwise there will be devastation from pilot error.  Single sign-on, and, for the vast majority, integration with Windows Active Directory, will have to play a role in easing some of the burden on end users.  

There is some cool stuff from Seagate (Momentus) and Wave Systems for integrating HW-based, managed FDE with Windows Authentication.  It's even cooler when there's TPM 1.2 to mash/mesh with.  I'm not the only one who thinks this stuff is good -- it's being fast-tracked for "Federal"-use approval, outside of FIPS.  

There's also some interesting use of crypto in VMware's ACE2, which isn't your mammy's or pappy's ACE1, that integrates slickly with Windows AD -- if you're thinking about leveraging managed desktop clients.  

 ...  

Hashes bring up another problem...  

Has anyone figured out how to write "good" ones?  

The big problem with today's hashing algorithms are hash collisions.  It's an elephant in the room that most InfoSec practitioners simply ignore.  

 ...  

TLS1.0/SSL3 is undergoing thorough analysis and attack.  
I keep hearing about side-band attacks, etc. that are
*almost* there, in terms of what White Hats know.  

What do we have waiting in the wings for when TLS1 is broken???...  

That day is coming...  and I, for one, don't know...