S/MIME Crack? Beware press bearing incomplete stories

[Bruce Schneier <schneier@counterpane.com>]

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