S/MIME Crack? Beware press bearing incomplete stories

What I did: write a Windows 95 screen saver that automatically brute forces 40-bit RC2 keys. The screen saver is has an easy interface, and parallizes nicely. What I didn't do: break S/MIME. I did not find any flaw in the S/MIME security specification. I did not find any flaw in any of the cryptographic algorithms used. I did not find any flaw in any software implementation of S/MIME. There is nothing wrong with the S/MIME standard. What I find, though, is that many S/MIME implementations don't interporate at anything stronger than 40-bit RC2. I find that the default encryption is 40-bit RC2, and the user isn't given any indication that the encryption level should be changed. 40-bit RC2 is weak. This is nothing new to anyone who reads the S/MIME specifications. In fact, the S/MIME specification is very forthcoming in discussing security of 40-bit RC2.
2.6 ContentEncryptionAlgorithmIdentifier
Receiving agents MUST support decryption and encryption using the RC2 algorithm [RC2] at a key size of 40 bits, hereinafter called "RC2/40". Receiving agents SHOULD support decryption using DES EDE3 CBC, hereinafter called "tripleDES".
Sending agents SHOULD support encryption with RC2/40 and tripleDES.
Later in the spec, the following appears:
Before sending a message, the sending agent MUST decide whether it is willing to use weak encryption for the particular data in the message. If the sending agent decides that weak encryption is unacceptable for this data, then the sending agent MUST NOT use a weak algorithm such as RC2/40. The decision to use or not use weak encryption overrides any other decision in this section about which encryption algorithm to use.
And even later:
2.6.2.3 Rule 3: Unknown Capabilities, Risk of Failed Decryption
If: - the sending agent has no knowledge of the encryption capabilities of the recipient, - and the sending agent is willing to risk that the recipient may not be able to decrypt the message, then the sending agent SHOULD use tripleDES.
2.6.2.4 Rule 4: Unknown Capabilities, No Risk of Failed Decryption
If: - the sending agent has no knowledge of the encryption capabilities of the recipient, - and the sending agent is not willing to risk that the recipient may not be able to decrypt the message, then the sending agent MUST use RC2/40.
And:
2.6.3 Choosing Weak Encryption
Like all algorithms that use 40 bit keys, RC2/40 is considered by many to be weak encryption. A sending agent that is controlled by a human SHOULD allow a human sender to determine the risks of sending data using RC2/40 or a similarly weak encryption algorithm before sending the data, and possibly allow the human to use a stronger encryption method such as tripleDES.
I wrote this screen saver not to trash S/MIME (even though the announcement was used by another company), but to 1) illustrate that 40-bit RC2 really is insecure, and 2) try to force companies who implement S/MIME to get DES and triple-DES to interoperate. I heard recently that RSADSI has said there is a triple-DES message on their website that can be understood by both Microsoft Internet Explorer and Netscape Communicator. I don't know about the message, but when I tried to get DES and triple-DES to interoperate a few months ago I couldn't. Bruce ********************************************************************** Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098 101 E Minnehaha Parkway, Minneapolis,MN 55419 Fax: 612-823-1590 http://www.counterpane.com
participants (1)
-
Bruce Schneier