Creating useful standards

Determining exactly how big a cryptographic key needs to be can be confusing. Even in the case of symmetric algorithms it can be tricky. DES, for example, uses a 64-bit key, but that doesn't mean that it provides 64 bits of strength. Eight of the 64 bits are parity bits, which don't give cryptographic strength. Only the remaining 56 bits do that. In the case of Triple-DES, you have 192 bits of key. Of these, 24 are parity bits, leaving only 168 that can provide cryptographic strength. There's an attack, however, that can be done in much less time that trying all 2168 Triple-DES keys. Because this attack can be done in the time needed to try only 2112 keys, Triple-DES is said to provide 112 bits of strength.

It's even trickier when it comes to public-key algorithms. Even experts disagree on exactly how much work it takes to defeat a 1,024-bit RSA key. You can find a comparison of several different points of view here.

The issue of determining exactly how many bits of strength an asymmetric key provides is apparently so bitterly debated that if you pick any one of the expert opinions and try to incorporate it into a standards document, there will always be someone who complains. This seems to be why the IEEE P1363 Standard Specifications For Public-Key Cryptography doesn't even try to tell how many bits of key are needed to provide standard levels of cryptographic protection. Instead, they just give vague and general guidance that's useless to a person trying to implement the algorithms described in standard. This is unfortunate. I've seen people make mistakes because they didn't understand how many bits of RSA key are needed to get the same protection as a Triple-DES key, and this confusion could have been avoided if standards documents were clearer.

It seems to me that the people who write the papers that give different estimates for asymmetric key strength are missing an important point. What's not really very important is exactly how much work is needed to attack a particular RSA key. Instead, what's important is what size key customers say they want to use. Both NIST and ASC X9 have made this very clear, and their needs are reflected in standards like FIPS 140-2, even if other standards can't quite manage to decide what to say.

If customers say that's what they want, then security vendors should give them that, even if arcane academic arguments say that the estimates are off by a few bits. Leaving this information out of standards and hoping that customers will be able to figure it out for themselves isn't a good idea at all. The customers that care have clearly said what they want. The participants in standards bodies should listen to this advice and use it when they create standards.

Leave a Reply

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