S/MIME Crack? Beware press bearing incomplete stories

1 view
Skip to first unread message

Bruce Schneier

unread,
Sep 26, 1997, 3:00:00 AM9/26/97
to

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 APPLIED CRYPTOGRAPHY, 2nd EDITION is
* Counterpane Systems available. For info on a 15%
* schn...@counterpane.com discount offer, send me e-mail.
*
* http://www.counterpane.com/
**************************************************************************

Reply all
Reply to author
Forward
0 new messages