The last few days has seen a number of new reports about a security vulnerability in RSA public/private keys in use on the Internet. The vulnerability has to do with duplicate keys, and not with any weakness in the cryptographic algorithm itself. But it is disturbing information because public/private key encryption is crucial to the security of web sites and a number of other secure applications and services.

The news is based on the work of academic researchers and you can read the paper here.

While the researchers did not identify the cause of the duplicate keys, a number of us are guessing that the problem lies in random number generation. It is really easy to create bad random number generators, and hard to get it right and prove that you have it right. So any sloppiness in your engineering processes related to RNG can lead to this type of problem. There are not a lot of applications in use that create RSA public/private keys and X509 certificates, so the problem may be limited to a small number of these applications. But at this time there is no indication of which RSA key generation routines may be at fault.

How bad is this problem and should you worry about it?

At this point I don’t think there are any known attacks or breaches based on this vulnerability. It may have happened, but it hasn’t been reported yet. However, while the original researchers did not disclose their methods for identifying the duplicate RSA keys, it doesn’t seem hard to think of ways to do this. That being said, I am not sure how easy it would be to mount an effective attack even if you know about the duplicate keys. A lot is still unknown about this vulnerability.

I think Bruce Schneier has a good take on this issue. If you are concerned about this potential problem, you can read his comments here.

Are there bad random number generators in the wild?

You bet. Some years ago we found one on the IBM i (AS/400, iSeries) platform. In the early days of the IBM i platform you could use a system API named CEERAN0 to generate random numbers. We were shocked to learn how poor this RNG application is. It would start generating collisions within about 30,000+ cycles. That is really bad. It turns out that IBM also provides a cryptographically secure RNG application, but the older one still exists and we’ve seen it used in vendor and customer applications.

So, the obvious question is how can you know if a random number generator is good? One place to start is with the National Institute of Standards and Technology (NIST). NIST publishes guidelines on proper RNG methods, and a certification program. You can read the NIST recommendations for certifying random number generators here (warning: heavy lifting ahead).

NIST also has a certification program for random number generators and vendors like us can submit our work to independent labs that perform NIST testing. All of our cryptographic solutions have been through this testing. It is also important to note that encryption key management systems that undergo FIPS 140-2 certification also go through full RNG testing. Our Alliance Key Manager if FIPS 140-2 certified and the RNG routines were NIST certified as a part of that process. We’ve also certified our RNG implementations on a variety of platforms including the IBM i. The list of vendors who have completed certification are here.

While I don’t think NIST certifications are a perfect indicator of good cryptographic implementations, I certainly wouldn’t accept any encryption key management or cryptographic solution that had not been through an independent certification process.

Proper random number generation is crucial to secure cryptographic systems. You can’t leave RNG to chance (sorry about that).

When more information is available on the RSA vulnerability I’ll give you an update. 

For more information on the importance of encryption key management, download our white paper "Key Management in the Multi-Platform Envrionment" and learn how to overcome the challenges of deploying encryption key management in business applications.

Stay safe.

Patrick

How Much Data Can You Encrypt with RSA Keys?

When someone first begins to consider using encryption to protect business data, they discover that there are two general types: symmetric (AES) and asymmetric (RSA). At first glance, which one you would choose can be confusing.

One of the differences between the two is speed. Symmetric encryption is much faster than asymmetric. The exact difference is implementation dependent, but may be on the order of 100 to 1000 times faster.

It is widely known that AES encrypts a 16-byte block of data at a time. However, how much data can be encrypted at one time with an RSA key is usually only discussed in vague terms such as “use RSA to encrypt session keys.” This raises the question of how much data can be encrypted by an RSA key in a single operation.

The typical encryption scenario is to encrypt with a public key and decrypt with the private key. OpenSSL provides the RSA_public_encrypt and RSA_private_decrypt functions to implement this.

The first parameter to the RSA_public_encrypt function is flen. This is an integer that indicates the number of bytes to encrypt. Its maximum value depends on the padding mode. For OAEP padding, recommended for all new applications, it must be less than the size of the key modulus – 41 (all in bytes).

To get the size of the modulus of an RSA key call the function RSA_size.

The modulus size is the key size in bits / 8. Thus a 1024-bit RSA key using OAEP padding can encrypt up to (1024/8) – 42 = 128 – 42 = 86 bytes.

A 2048-bit key can encrypt up to (2048/8) – 42 = 256 – 42 = 214 bytes.

Additional Resources for IT Developers and Professionals

We collaborate with developers and IT professionals around the world and know that they use a wide variety of languages and platforms to accomplish their work.  Our products include documentation, source code examples, and HOWTO guides for developers in order to help projects get done quickly. Visit our Developer Resources section of our web site to learn more and discuss your upcoming project with our development team.

 

 

As day three of the RSA Conference 2011 begins, it marks the half-way point through the largest data security tradeshow that the industry has to offer. Walking into the show you would be hard pressed to tell whether you walked into a security show or a grown up play-yard. Look to left you see sumo wrestlers, looking ahead there are unicycles weaving the crowd, and to the right are pirates handing out candy. And to top it all off, each night ends with beer, wine, and appetizers for all attendees. Who wouldn’t want to attend the RSA Conference 2011??!!

As you look past all the gimmicks, the technology is still really what matters.

A noticeable change over the past two years is the increased awareness of FIPS-140 certification for key managers.

We believe this is largely driven by compliance auditors whose demands have evolved from "you must encrypt" to "you can't store your keys with your data" to "you need to use a key manager" and are now converging on "you need a FIPS-140 certified key manager."

As the auditing community matures we expect the requirements for formal government certifications to move from occasional to manditory.

In the past we usually only heard these concerns from sophisticated security architects with very large companies. Now we are seeing this awareness beginning to move through the SMB marketplace.

Prospective partners, future clients and current customers recognize that Townsend Security has done encryption and key management the way that it needs to be done – and proven by NIST and FIPS certifications. If your encryption offering hasn’t been reviewed and certified by NIST, you have no assurance that you aren’t implementing a less than secure product. “I wouldn’t consider an encryption solution that isn’t certified by NIST” is a common statement by attendees at our booth.

Would you like to see first hand how certified encryption and key management will work at your organization? Click on the links to request evaluation versions of AES encryption and Key Manager. One of our security specialists will be in contact with you to make sure you are up and running and answer any questions that you might have.

Or, if you just would like to learn more about encryption and key management, visit the resources section of our web site.

And if you read this while you are still at the RSA Conference 2011, stop by our booth and pick up a little somethin’ special that we have been saving you.

The advent of faster and faster computers poses a never ending challenge for encryption methodologies. An excellent example of this is the demise of the DES encryption standard in 1999.  That was when a group of programmers was able to break the security of a DES key in about 22 hours using a brute force attack which simply tried every possible value of the key. Computers have gotten a lot faster since then! This exploit lead to the adoption of AES as the new standard for symmetric encryption.

This year marks another milestone regarding the use of RSA keys. These are the public-private key pairs that are used in the creation of the SSL/TLS connections that enable ecommerce to transactions to run over the Internet (for example when you engage in electronic banking or give a credit card number to an on-line merchant).

In the past the use of RSA keys with a length of 1024-bits was quite common. However, the official policy has changed. NIST (the National Institute for Standards in Technology) now recommends that 2048-bit keys be used to encrypt data through 2030. After that time 3072-bit keys will be required.

This is documented in NIST Special Publication 800-57, Recommendation for Key Management. See “Table 4: Recommended algorithms and minimum key sizes” for particulars.