Cryptography for Mere Mortals #15

An occasional feature, Cryptography for Mere Mortals attempts to provide clear, accessible answers to questions about cryptography for those who are not cryptographers or mathematicians.

Phil Smith III, Senior Architect & Product Manager, Mainframe & Enterprise Distinguished Technologist and Dave Mulligan, Chief Services Strategist, HPE Security – Data Security

Q: I heard that National Institute of Standards and Technology (NIST) just repudiated the format-preserving encryption (FPE) standard—should we be concerned about that?

A: Maybe. Let’s talk some more about standards. In installment 14, we talked about why standards are important.

Since that post, NIST released Special Publication 800-38G, “Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption”. This included two new modes of AES, FF1 and FF3; FF1 is the Format-Preserving Encryption included in HPE SecureData, proven through almost a decade of real-world use. (For those who are wondering: FF2 was another approach, which was discarded partway through the standards process due to weaknesses found by the standards body’s analysis.)

Great! A new standard, with two choices that achieve similar results! Vendors leapt on the FPE bandwagon and started implementing these new modes in their products. Many of them chose to implement the FF3 mode, and have products available now.

Now comes the bad news: as discussed in April, a problem was found with FF3 that makes it vulnerable to attack. O noes! Standards fail! Maybe standards aren’t so wonderful after all?!

Not so fast. Yes, FF3 has a weakness, and yes, vendors and customers who chose that route have a problem. But it falls in the category of “an honest mistake”, and is one that can be rectified without embarrassment or arguing. Contrast that with having chosen an encryption algorithm not blessed by any standards body: if a weakness is discovered, there’s no good excuse for having chosen it. Worse, without a neutral third party saying “Hey, there’s a problem”, a sleazy vendor could just say “We don’t think this matters, move along, nothing to see here.”

Besides, this weakness was discovered because it was a standard: the cryptographic community tends to focus its analysis efforts on standard-based algorithms. There is a positive feedback loop here: the focus is on standards-blessed algorithms, which encourages customers to use those, which encourages more analysis… The alternative is security by obscurity: a non-standard, untested algorithm might be secure, but nobody knows. Which is hardly a solid basis for a security posture.

Bottom line is, the exception does not invalidate the value of standards, and enterprises examining their choices for data protection would be foolish to select approaches that are not at least on a standards track.

HPE SecureData, of course, has offered FF1 for almost a decade, on a variety of platforms, and is not subject to the weakness that FF3 suffers from. We take a conservative approach in designing our solutions, and FF1 includes extra internal “rounds” (iterations) that increase its security, helping to guard against new attacks such as the one that makes FF3 vulnerable. This is just one reason enterprises that have done the analysis consistently choose HPE SecureData to protect their information.

Meanwhile, companies using an FF3-based approach must act, as discussed in the April post here. If data protected using FF3 is breached, the data will of course still be less vulnerable than if it were not protected at all, but the organization will not be able to claim exemption from data breach disclosure rules. This means they must take the same steps as if the data were not protected at all: suffer disclosure, fines, etc. Considering the full costs of this remediation, it is clear that taking security shortcuts carries significant risk; The 2016 Ponemon Cost of Cyber Crime Study reported that the total average cost for a breach is now $7 million!

Leave a Reply

Your email address will not be published. Required fields are marked *