Townsend Security Data Privacy Blog

The time required to crack an encryption algorithm is directly related to the length of the key used to secure the data.

Every now and then, our development team comes across someone still using antiquated DES for encryption.  If you haven’t made the switch to the Advanced Encryption Standard (AES), let’s take a look at the two standards and see why you should!

Data Encryption Standard (DES):

DES is a symmetric block cipher (shared secret key), with a key length of 56-bits. Published as the Federal Information Processing Standards (FIPS) 46 standard in 1977, DES was officially withdrawn in 2005 [although NIST has approved Triple DES (3DES) through 2030 for sensitive government information].

The federal government originally developed DES encryption over 35 years ago to provide cryptographic security for all government communications. The idea was to ensure government systems all used the same, secure standard to facilitate interconnectivity.

To show that the DES was inadequate and should not be used in important systems anymore, a series of challenges were sponsored to see how long it would take to decrypt a message. Two organizations played key roles in breaking DES: distributed.net and the Electronic Frontier Foundation (EFF).

• The DES I contest (1997) took 84 days to use a brute force attack to break the encrypted message.
• In 1998, there were two DES II challenges issued. The first challenge took just over a month and the decrypted text was "The unknown message is: Many hands make light work". The second challenge took less than three days, with the plaintext message "It's time for those 128-, 192-, and 256-bit keys".
• The final DES III challenge in early 1999 only took 22 hours and 15 minutes. Electronic Frontier Foundation's Deep Crack computer (built for less than $250,000) and distributed.net's computing network found the 56-bit DES key, deciphered the message, and they (EFF & distributed.net) won the contest. The decrypted message read "See you in Rome (Second AES Candidate Conference, March 22-23, 1999)", and was found after checking about 30 percent of the key space...Finally proving that DES belonged to the past.

Even Triple DES (3DES), a way of using DES encryption three times, proved ineffective against brute force attacks (in addition to slowing down the process substantially).

Advanced Encryption Standard (AES):

Published as a FIPS 197 standard in 2001. AES data encryption is a more mathematically efficient and elegant cryptographic algorithm, but its main strength rests in the option for various key lengths. AES allows you to choose a 128-bit, 192-bit or 256-bit key, making it exponentially stronger than the 56-bit key of DES. In terms of structure, DES uses the Feistel network which divides the block into two halves before going through the encryption steps. AES on the other hand, uses permutation-substitution, which involves a series of substitution and permutation steps to create the encrypted block. The original DES designers made a great contribution to data security, but one could say that the aggregate effort of cryptographers for the AES algorithm has been far greater.

One of the original requirements by the National Institute of Standards and Technology (NIST) for the replacement algorithm was that it had to be efficient both in software and hardware implementations (DES was originally practical only in hardware implementations). Java and C reference implementations were used to do performance analysis of the algorithms. AES was chosen through an open competition with 15 candidates from as many research teams around the world, and the total amount of resources allocated to that process was tremendous. Finally, in October 2000, a NIST press release announced the selection of Rijndael as the proposed Advanced Encryption Standard (AES).

Comparing DES and AES

	DES	AES
Developed	1977	2000
Key Length	56 bits	128, 192, or 256 bits
Cipher Type	Symmetric block cipher	Symmetric block cipher
Block Size	64 bits	128 bits
Security	Proven inadequate	Considered secure

So the question remains for anyone still using DES encryption…
How can we help you make the switch to AES?

In the world of encryption there are many different names for encryption, but probably the two most common would have to be AES and PGP. But not everyone knows what these acronyms stand for. In today’s world of TLAs (Three Letter Acronyms) it’s easy to feel left behind in a data security conversation when they start replacing every other word. OMG!

First we’ll break both of them down a bit and then we’ll compare them to each other.

AES, or Advanced Encryption Standard, as we know it today is the dreamchild of two cryptographers’ proposal of a symmetric key encryption algorithm based on the Rijndael cipher. This algorithm was developed when NIST (National Institute of Standards and Technology) sent the call out to the cryptographic community to develop a new standard. NIST spent five years evaluating fifteen competing designs for the AES project and in 2001 announced the cipher developed by the two Belgians Joan Daemen and Vincent Rijmen as the adopted standard, known as FIPS-197, for electronic data encryption.

AES is a symmetric key encryption algorithm, which essentially means that the same key is used for the encryption and decryption of the data. A computer program takes clear text and processes it through an encryption key and returns ciphertext. If the data needs to be decrypted, the program processes it again with the same key and is able to reproduce the clear text. This method required less computational resources for the program to complete its cipher process, which means lower performance impact. AES encryption is a good method to protect sensitive data stored in large databases.

There is, however, a time when AES will not be your go-to encryption process. When you need to share sensitive information with trading partners or transfer information across networks, using AES has one downside when it comes to security: You would have to share your encryption key with your trading partners. Sure, they’d be able to decrypt the information you sent them, but they would also be able to decrypt anything else encrypted with that key, and if the key itself became compromised anyone in possession of it could decrypt your data.

Enter PGP. PGP stands for Pretty Good Privacy, and before you get too distracted by the name, I can tell you it is actually much better than just pretty good. PGP uses symmetric and  asymmetric keys to encrypt data being transferred across networks. It was developed by the American computer scientist Phil Zimmerman, who made it available for non-commercial use for no charge in 1991. To encrypt data, PGP generates a symmetric key to encrypt data which is protected by the asymmetric key. 

Asymmetric encryption uses two different keys for the encryption and decryption processes of sensitive information. Both keys are derived from one another and created at the same time. They are divided into and referred to as a public and a private key, which makes up the key pair. Data is only encrypted with a public key and thus can only be decrypted with the matching private key. The encryption PGP offers is just as strong as that of AES, but it adds the additional security that prevents anyone with just the public key from being able to decrypt data that was previously encrypted with it. Another benefit of asymmetric encryption is that it allows for authentication. After you have exchanged public keys with your trading partners, the private keys can be used to digitally sign the encrypted content, allowing the decryptor to verify the authenticity of the sender.

PGP does require more computational resources, which is why it is usually not recommended for encrypting data in large databases where information needs to be accessed frequently, and each record that you access needs to be ran through a cryptographic process.

When you are considering which encryption to use for your sensitive information choose whichever will suit your needs best. AES is fast and works best in closed systems and large databases; PGP should be used when sharing information across an open network, but it can be slower and works better for individual files.

 

AES Encryption & Related Concepts Download the white paper "AES Encryption & Related Concepts" Click Here to Download Now

It seems like every day the media reports another data breach—a stolen laptop that contains patients’ private information, credit cardholders’ names and social security numbers hacked. Not only do the headlines prove to be public relations nightmares for the companies involved—especially if the stolen or hacked data isn’t encrypted—but they come with severe financial penalties, often reaching into millions of dollars.

When data is encrypted, companies can assure those whose data has been stolen or hacked that there is no reason to worry. Thieves may have the files containing the data, but the thief will be unable to access the data itself. This minimizes the public relations hit and reduces liability with compliance regulators. In today’s highly regulated business world, there is no excuse for not having encryption on your IBM i. Here are two types of encryption to make sure your data is secure:

NIST-Certified AES Encryption for Data at Rest
NIST sets non-military government standards for a wide variety of technologies including data encryption. Because NIST uses an open and professional process to establish standards, the private sector usually adopts NIST standards for commercial use. NIST is one of the most trusted sources for technology standards.

Since AES was introduced, it has been adopted by all U.S. government agencies as the gold standard for protecting sensitive data, and many software companies have made it available to consumers through encryption software. When selecting a data security service, looking for one that has NIST certification should be at the top of your list.

PGP Encryption for Data in Motion
In today’s world, data moves faster and further than ever. That’s why it’s important to ensure it’s secure whether it’s in a database, on a laptop, or sent via email.

PGP encryption is ideal for exchanging data with trading partners, banks, insurance companies, benefits providers, and many other external partners. It’s ability to run on any computing platform makes it ideal for this type of secure data exchange.

Data breaches and associated fines don't have to be a reality of doing business. By properly encrypting your sensitive information you remove the risk of seeing your name in the headlines, being fined millions of dollars, and trust of your brand by your customers.  Download our white paper "AES Encryption and Related Concepts" to learn more about industry best practices for securing your data.

 

The newest version of the IBM i (AS400) operating system, V7R1, brings sophisticated new security tools from IBM’s larger systems to mid-range markets. These new features allow third-party companies such as Townsend Security to offer NIST-certified automatic AES encryption, so that you can now encrypt your sensitive data without application changes!

With the update from V5R4 or V6R1 to V7R1, the AS400 can now protect data more efficiently by using FIELDPROC, an “exit point” technology that works in the database instead of in application programs. Previously, IBM i (AS400) encryption was an application-level process where a user had to first identify the field such as credit card numbers, social security numbers, or other private information and then decide on an approach that usually involved modifying applications. This required programmers to make changes and undergo a sophisticated test cycle.

The new FIELDPROC exit point allows a user to identify all fields they wish to encrypt with Townsend Security’s automatic AES encryption without making application changes.

It is crucial to keep in mind that administrators can use strong encryption in a weak manner by neglecting the use of proper encryption key management. In using a third-party encryption  provider such as Townsend Security, a company with more than 20 years of IBM i (AS400) experience has three distinct advantages:

1. AES encryption is automatic, meaning that no changes in applications need to be made. This saves your company time and money by focusing on your business instead of a complicated encryption project.
2. NIST-certified encryption will pass all state, federal, and industry compliance regulations. Townsend Security guarantees our NIST certified Alliance AES/400 solution will meet or exceed encryption standards in PCI, SOX, HIPAA/HITECH and other regulations.
3. Third-party encryption can be faster. Alliance AES/400 from Townsend Security can encrypt one million credit card numbers in one second of CPU time--100 times faster than competing encryption libraries on the same IBM i platform.

Because encryption has a reputation for creating performance problems, the newly specialized FIELDPROC tool optimizes encryption and sets up secure caches. Townsend Security’s Automatic AES Encryption integrates seamlessly with these features to create the most secure data environment available on the IBM i (AS400) today.

Download our podcast on "The Benefits of FIELDPROC Encryption" to learn more about FIELDPROC capabilities and the benefits of automatic encryption.  Additionally, we have a podcast titled "FIELDPROC Performance - Speed Matters" for those who are wondering how it will impact their systems.

I recently had a conversation with one of our customers about the automatic encryption webinar they attended.  The webinar demonstrated how companies can implement AES encryption on their AS/400 without making application changes. This customer currently has our managed file transfer solution, FTP Manager with PGP encryption, and was confused as to why they would need AES encryption if they were using PGP. I explained that PGP encryption protects data in motion - when it is transferred outside his company. If he was storing data on his AS/400, he would need AES encryption to protect his data at rest.

AES Encryption
AES encryption is the standard when it comes to encrypting data in a database. Advanced Encryption Standard (AES) has been adopted as a standard by the US government and many state and local agencies. AES is the recommended encryption method for PCI, HIPAA/HITECH, GLBA and individual state privacy regulations. AES encryption uses an encryption key to encrypt the data. Typically, this key is stored on the AS/400 and used when the data needs to be decrypted.  To side track here a little, this is not a good idea. Leaving your encrypted data and keys in the same place is like leaving the key to your house under your door mat. If you want to learn more about why this is a bad idea, take a look at this blog article on the topic.

PGP Encryption
PGP encryption is the standard when it comes to encrypting files that need to be transferred. Pretty Good Privacy (PGP) is the standard for encrypted file exchange among the world’s largest financial, medical, industrial, and services companies. Also know that when encrypting a file with PGP, you may be using AES encryption.  

AES encryption and PGP encryption solutions work together to ensure that all your sensitive data is secure. AES will protect data at rest within your organization and PGP encryption keeps it secure when it is sent outside your company.

I hope this has been helpful in better understanding the differences and similarities of PGP encryption and AES encryption. Learn more about AES and PGP encryption with the webinar "Automatic Encryption on the IBM i" that spurred this conversation or the whitepaper "AES Encryption and Related Concepts". 
 

 

 

DOWNLOAD WHITE PAPER Download the white paper "Achieve Safe-Harbor Status from HITECH Act Breach Notification" to learn more about encyption and key management best practices. Click Here to Download Now

The recent news of SAIC being dinged for not protecting US military TRICARE medical information with standard AES encryption and suffering a data loss is interesting. While the details are still thin, it appears that the data was encrypted, but not with a standard AES encryption method. The HITECH Act proposed data security rules make specific reference to AES and other NIST standards.

We don’t know which encryption method was used to protect the data. It could have been a home grown method of encryption, or it may have been a widely accepted encryption method that was just not a part of NIST standards. But it apparently doesn’t matter. If you are not using a NIST standard method of encryption, you are in violation of the compliance requirements.

I think it is going to take some time for the implications of this to settle in. Here are some rather unorganized thoughts:

Over the last two years I’ve seen at least FOUR instances of vendor “AES” encryption solutions that actually weren’t AES encryption. In one case, a point-of-sale vendor implemented an AES encryption library with a 256-bit AES block size. The AES standard (FIPS-197) only allows the use of a 128-bit block size.  The company running this software had no idea that they weren’t actually running an industry standard method of encryption.

In another case a customer was running AES encryption with a non-approved mode of encryption. The underlying encryption library was AES, but the mode was not a NIST-approved mode of operation. This was a distinction lost on the company running this “AES” solution. But it seems likely to me that they were out of compliance and at risk in the same way SAIC was. This company is going to have to rip out the current solution and replace it with something that is actually compliant. That seems like such a waste of time and resources.

In one of these cases the software was provided by a “security” vendor. This vendor sells encryption and key management software specifically to meet encryption compliance regulations. That’s very sad.

With the best of intentions and with deep knowledge of encryption protocols, you can still make mistakes when developing an encryption solution. It is hard to get this right. And weak vendors without the commitment and passion to get it right represent a risk to everyone. So, if you are a vendor of encryption solutions, what do you do to insure that you are getting things right? You learn to not trust yourself so much, you invest in independent review of your solutions, and you invest in independent certification. Today we would never release an encryption product without subjecting it to NIST certification and independent review.

If you are a company facing an encryption project, how will you select a security vendor for your encryption libraries and encryption key management solution? How will you know that their AES encryption is really based on the NIST standard? Are you ready to trust the claims of a sales person? I wouldn’t, and I don’t think you should, either. If a security vendor can’t show you a formal NIST AES Validation certificate, or a FIPS-140-2 certification, you should run for the nearest exit. You just have way too much to lose.

If you think that the HITECH Act is unique in its reference to NIST standards, have a look at the proposed Federal Privacy Law (Senate Bill 1151) that passed out of the Senate Judiciary committee last week. It is likely to empower the FTC to propose standards for encryption and encryption key management, and the FTC is likely to look to NIST for these standards.

The writing is on the wall, or rather, it’s on the Internet at www.nist.gov.

Learn more about proper encryption and key management best practices for HIPAA and HITECH Act in our white paper titled "Achieve Safe-Harbor Status from HITECH Act Breach Notification".

Patrick

 

 

 

 

It was fascinating to read the headlines this week about the terrible flaw that was discovered in the Advanced Encryption Standard (AES). It sounded like the end of security as we know it. I read blogs and articles that headlined “AES Broken” and “Fatal Flaw in AES”. It was fun reading, but completely misleading. So, what really happened?

Three cryptographers (Andrey Bogdanov,  Dmitry Khovratovich, and Christian Rechberger) found a slight mathematical weakness in the AES encryption algorithm and published a paper on their findings. These aren’t hackers trying to break into systems. These are professionals in their field working on cryptanalysis projects. This is what the professional cryptographic community does, and we all benefit from their work. They are to be applauded for their findings as it advances our understanding of cryptography and cryptanalysis, and this leads to more secure systems.

What is the practical impact of their finding? Do we all need to bunker down in a newly insecure world?

No. There is no practical attack on encrypted data with these findings. The effect is to weaken 128-bit AES encryption to about 126-bit AES encryption. That is still plenty strong and we don’t have to worry about new attacks on encrypted data. Here is a really good description from William Hugh Murray in the SANS newsletter:

“While this is a significant analysis, worthy of a paper, perhaps even a headline, an attack using this information, begun at the Big Bang, would not have completed yet.  Kudos to the analysts.”

And I like this one from ScienceDaily.com (originally from a source at Katholieke Universiteit Leuven) even better:

“Even with the new attack, the effort to recover a key is still huge: the number of steps to find the key for AES-128 is an 8 followed by 37 zeros. To put this into perspective: on a trillion machines, that each could test a billion keys per second, it would take more than two billion years to recover an AES-128 key.”

The earth is due to burn up in about 500 million years, so we don’t have anything to worry about quite yet.

By the way, this work points directly at the value of using standards-based encryption. The cryptographic community does not work much on non-standard algorithms and propriety methods. If there is a weakness in an encryption method, we really want the good guys to find it. Weaknesses in non-standard algorithms and methods are likely to go undetected for a much longer period of time.

For more information on AES encryption, download our white paper "AES Encryption and Related Concepts" and learn about how proper encryption and key management work together to secure your data.

Patrick

When encrypting data, the most widely accepted cryptographic standard is the Advanced Encryption Standard (AES).

AES is defined by the National Institute of Standards and Technology (NIST) in the FIPS-197 standards document. AES supports nine modes of encryption, each of them having been extensively tested and vetted for security, recovery, and durability. When compliance regulations make reference to “industry standard encryption”, they are referring to the encryption modes identified in the NIST documents on AES.

Other modes used in AES are not NIST certified and are not even certifiable. Some products offer only the CUSP mode of encryption, which is not NIST certified and not certifiable. CUSP mode encryption is only implemented on IBM i and IBM z platforms and is not interoperable with other encryption modes. The CUSP mode of encryption has not been proposed or adopted as a NIST standard, and has not been generally reviewed or accepted by the professional security community.

Modes of encryption are recommended by NIST after they have been extensively reviewed by the professional cryptographic community. This is an international group of cryptographers whose long experience and analytic work are important to the vetting of proposed modes of encryption. In some cases it takes years of work before a mode is approved by NIST; many mode submissions are never approved for use.

There are several potential problems related to the use of the CUSP mode of AES encryption.

The CUSP mode of encryption is not included in the NIST list of recommended modes, and has not been submitted to NIST for consideration. It is therefore not a part of the NIST standards, or of any other generally accepted body of standards, and has not been formally reviewed by the cryptographic community. Therefore, the use of CUSP mode would be outside the scope of most data security regulations.

Further, there is no NIST certification protocol for the CUSP mode of encryption. It is not possible to claim that an encryption product using CUSP has been certified by NIST, or that it is in anyway compliant with the NIST standard.

Organizations contemplating the CUSP mode of encryption should be aware that their data protection mechanism could fail to provide “safe harbor” from breach notification requirements, and may not limit their legal liability in the event of a data loss.

The solution?  Most software vendors choose to certify just one or two modes of encryption, and on one key size. The Townsend Security Alliance AES Encryption products are NIST-certified on the five commonly used modes for data encryption, and all three key sizes for all major Enterprise platforms (Windows, Linux, UNIX, IBM i, and IBM z).  Townend Security Alliance AES Encryption is certified, compatibile, and complete.

Download a free 30-day evaluation of our Alliance AES Encryption now.

I’ve always liked those Holiday Inn Express commercials with the theme of “Stay Smart.” The commercials portray an “expert” stepping in to save the day. In one, a “nuclear expert” takes charge of a reactor about to melt down. In another a “doctor” arrives to deliver a baby just in the nick of time. The tag line is funny because the so-called expert turns out not to be a nuclear scientist or a doctor, but just an average person who stayed at a Holiday Inn Express. That made them “smart.” Don’t worry; I’ll bring this discussion back to encryption momentarily.

A while back, reports surfaced of broken encryption security for some Kingston, Verbatim, and SanDisk secure USB storage devices. Not all of the vendor’s devices were affected, but some of their most popular products were. All these products were NIST-certified, causing some industry commentators to erroneously question the certification process. Being a big believer in independent certification, I’d like to weigh in on this controversy and set the record straight.

As it turns out, the weakness, in these devices, was not in the actual AES encryption, but in the key management processes. All the affected vendors quickly released replacements or patches to fix the problem, which is the right thing to do. But it was fascinating to watch some of the responses to this problem. Many commentators complained that the FIPS-140 testing was faulty, or that FIPS-140 testing was irrelevant. The implication is that FIPS-140 does not really give you any assurance of security, and therefore, also by implication, that it is not important.

This is really the wrong conclusion. Let me talk a little about FIPS-140 certification and what is does mean.

First, FIPS-140 certification is not a guarantee of security. It is an assurance that encryption and related security algorithms have been implemented in compliance with published standards, that an application uses good practices in exposing it’s operational interfaces, that start up tests validate that the application has not been modified or corrupted, that cryptographic material is not exposed in application logs or leaked to memory, and that an independent expert has reviewed the source code. Going through a FIPS-140 certification is a grueling process for an encryption vendor and almost always results in finding some issues that need to be addressed to make the product more secure. Companies that engage in FIPS-140 certifications produce better products, and become better security designers in the process.

Is the FIPS-140 testing and certification process perfect? Of course not. That’s not a standard anyone can meet. In fact, NIST is working on a project right now to enhance the process. Believe me, the new certification process (probably to be named FIPS-140-3, for version 3) will not be weaker than the current process, it will be better.

The lesson from the encrypted USB problem is not that FIPS-140 certification is meaningless. It’s that doing encryption right is really difficult. If you want a secure USB storage device, you would NEVER consider using a product that was not FIPS-140 certified. We have plenty of experience of broken security on non-certified products. Problems with certified products are rare, but do happen. Usually you will find that a problem with a FIPS-140 certified product is with some aspect of the application that was out of scope for the certification. That’s the case for the encrypted USB devices that had problems.

To bring us back full circle, I just want to say that no responsible Enterprise should trust a non-certified USB device, anymore than you or I should trust a “doctor” to perform surgery because that “doctor” stayed at a Holiday Inn Express. The sad fact is that many large corporations today are putting their trust in encryption vendors who have not FIPS-140 certified their products. The management of these companies would never consider using a $100 secure USB device without certification, but do entrust the protection of huge amounts of sensitive data to non-certified vendors. In this age where too many try to pass themselves off as experts, it often takes an organization like NIST to certify the expertise behind something as important as encryption.

I’m proud of our NIST certifications – we will never back down from our commitment to provide you with the best security products and our commitment to independent certification. You can learn more about FIPS-140 certification on our web site, or directly from NIST at www.NIST.gov.

For more information, download our white paper "AES Encryption and Related Concepts" and learn about how proper encryption and encryption key management work together to secure your data.

For most organizations, the entire impetus to encrypt is closely tied to the need to be compliant with one regulation or another.  There is the PCI regulation, the HITECH act of 2009, HIPAA, Sarbanes-Oxley, and a whole host of state privacy laws.  If you are going through the due diligence of database encryption, you sure as heck want to get it right the first time.

A big part of getting it right is using the right encryption tool.  There are plenty of tools on the market that claim to do encryption, and you probably know a clever programmer or two who thinks he can come up with a nifty little data scrambling algorithm that no-one has ever seen before. But encryption — real encryption — demands that we reach for a higher standard.

The U.S. Department of Commerce publishes the definitive encryption standard on its National Institute of Standard and Technology (NIST) website and to date, hundreds of cryptographic providers have achieved this high standard.  As of this writing, NIST has certified over 1,300 AES encryption implementations.

A Fundamental Truth
Cryptographers do not suffer fools lightly.  Their science is mathematically based and their algorithms are well known and well vetted.  A fundamental truth of cryptography is that real encryption cannot rely on keeping the algorithm secret.  Instead the secret that protects the data is the encryption key, and only the encryption key.  Anyone who says different may find themselves on the receiving end of an extra-long mathematical dissertation on the mathematical correctness of accepted encryption algorithms.

When you stop to think about it, this makes perfect sense.  If the world used a secret algorithm to encrypt data, if that algorithm were ever to be discovered then all the world’s data would be at risk.  But if the key is the one-and-only secret that unlocks the data, then a compromised key only puts the data at risk that was encrypted with that particular key.  All the other data that has been encrypted with other keys is still safe.  This demonstrates both the wisdom of strong (and open) algorithms, but also the essential importance of strong key protection.

Another benefit of open algorithms is that they are peer reviewed and extremely well vetted.  The AES standard that is the de-facto standard for encrypting data at rest is well known in cryptography and mathematical circles and is recognized the world over as the most effective method for encrypting business data.  Its modes of encryption are well known and proven. And there is a strong body of knowledge about how to correctly implement the AES standard.  From the perspective of a cryptographic (encryption) provider, encryption libraries are not easy to write, but they are known to be solid when implemented according to accepted standards.

Homegrown Encryption
Unfortunately, some software providers seemed to have taken a different road. AES encryption must have seemed too difficult, or too cumbersome, so instead they found loopholes and/or shortcuts to simplify their implementation.  Some software providers use untested software, or unique and un-vetted methods of encryption.  These data scrambling methods aren’t (and never could be) NIST or FIPS certified, but if their customers never ask about certification or independent validation, those providers are not likely to raise the topic.

So we are seeing a raft of uncertified, and un-vetted cipher methods introduced in the market place.  Some, like OMAC, CS, and CWC have languished on the NIST list of “Proposed Modes” for years, while others like CUSP have never even been submitted as a proposed standard.  And while it is possible that one or more of these upstart modes could be better than one of the current, standard modes, there is no way to know this because these new modes have not been properly tested and crypto-analyzed.  Without testing and peer review, each of these modes is just another premature idea that is statistically more likely to be a bad encryption method than a good one.

Show Me the Cert!
Many software vendors are beginning to recognize the value of certifications.  Some claim certifications they don’t actually have (HINT: PCI does not certify encryption software) and some will use confusing language to infer they have achieved levels of certification they haven’t.  Recently I visited a website that claimed (I’m paraphrasing):

Our stuff uses FIPS 140-2 certified algorithms to ensure the highest level of data security.

The NIST AES website displays no record of this company ever having received a certification for any encryption software.  Clearly they recognize the value of certification, but have not yet knuckled down to do the hard work to make it so.  And if you don’t check their supposed “facts,” it’s likely that you’ll soon regret it.

My advice?  When someone claims to be certified for any type of encryption, ask a simple question: “Can you show me the cert?”  It ought to be available on the web, or in paper form that they can show to you so that you know this software has passed an independent evaluation.  If they have a cert, then you can dig down deeper and find out whether the software will fit your needs.  But if they are claiming a certification that they cannot prove, my advice is to keep your hand on your wallet and then run.

For more information on encryption and key management, download our white paper titled "AES Encryption and Related Concepts."