Counterpane Labs Releases Windows 95-compatible S/MIME 40-bit RC2 Cracking ScreenSaver
Technical Information and Download
What I did: write a Windows 95 screen saver that automatically brute forces 40-bit RC2 keys. The screen saver has an easy interface, and parallelizes nicely.
Why I did it: to
- illustrate yet again that 40-bit RC2 really is insecure, and
- try to force companies who implement S/MIME to get DES and triple-DES to interoperate.
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 found, though, is that some S/MIME implementations didn't interoperate at anything stronger than 40-bit RC2. (I did this research in May 1997; things may have changed since then.) I also found that the default encryption was 40-bit RC2, and that the user wasn't given any indication that the encryption level should be changed. And, of course, 40-bit RC2 is all foreign users ever get.
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 the 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.
up to Academic
Photo of Bruce Schneier by Per Ervland.
Schneier on Security is a personal website. Opinions expressed are not necessarily those of IBM Resilient.