Look What the NSA Dragged In

There are many changes to track in the world of standards-based crypto, another on the long list of challenging facets in this industry.  These changes can sometimes include the algorithms themselves.

NIST Special Publication 800-131A defines transition timelines for what NIST considers to be weak or weakening algorithms.  It makes sense; as computing power increases, the underlying strength of cryptographic algorithms (whether for encryption or hashing) diminishes.  This is tricky business though, as some of these algorithms are part of protocols implemented by technology vendors and are widely supported and adopted by the industry.  It's hard for some folks to develop towards those changes because of user adoption, customer environments, backwards compatibility, and other reasons, but eventually the algorithm must be phased out.

We are currently facing an entirely different and even more rare algorithm change, which requires quick action and leaves little time for a planned transition.  It was the direct result of the discussions on surrounding entropy sources and the 800-90 series of draft Special Publications from NIST.  SP 800-90A is titled "Recommendation for Random Number Generation Using Deterministic Random Bit Generators" and does just that.  However, one of the methods listed is now under scrutiny, and NIST has re-opened the public comment period to address concerns from the community.

The end result is a consensus revocation of confidence in the security of the Dual EC DRBG algorithm.  In the wake of the NSA revelations, the industry has become very sensitive to potential conflicts of interest and this algorithm is suspected of containing backdoors.  Even though Dual EC DRBG is a FIPS-approved algorithm, NIST is currently recommending against using Dual EC DRBG until SP 800-A is re-issued.

In this context, SafeLogic issued a notice on our support portal.  SafeLogic agrees with NIST’s evaluation and we discourage the use of Dual EC DRBG until further notice.  Fortunately, there is no impact to our FIPS 140 certificate, our customers' FIPS 140 certificates, or our customers' products and solutions. Dual EC DRBG is one of many algorithms available for use within CryptoComply for Mobile and CryptoComply for Server modules, but requires specific customer action to select and activate the algorithm in question.  Our default is AES 256 CTR, which is covered in Section 10.2 of SP 800-90A, and if that is not your preference, there are several other options that are still endorsed by NIST.

Of greater concern is the prevalence of use across the industry.  While SafeLogic has not promoted the use of Dual EC DRBG, it is the sole algorithm in use for some solutions.  In others, including the entire RSA BSAFE family of cryptographic toolkits, Dual EC DRBG is of primary importance and is used as a default algorithm in every version of BSAFE and Data Protection Manager (DPM).

RSA responded by making a similar announcement, advising all developer customers to discontinue use of the algorithm immediately.  They plan to update their libraries ‘as needed’ and ‘change the RNG as appropriate’ as well.  This, of course, does not help existing customers, who must follow technical guidance provided by RSA to update their own implementations.  This is no trivial undertaking and is by no means immediate.  RSA has provided a complicated and time-consuming recipe for an antidote, while the poison itself is already at work.  While I’m sure many developers spent their weekend on this, the popularity of RSA’s BSAFE product line leaves a high probability that there are many more still vulnerable and struggling to respond.

If you are in this group, please reach out.  SafeLogic is making the team available to answer any questions you may have about algorithm selection, how to respond to these advisories, and how CryptoComply may solve your issues.