At 9:25 AM -0400 4/26/07, Robert Relyea wrote:
>Now technically KMail MUST implement RC2-40 (is the implementers
>confusing RC2 with RC5?) according to the S/MIME spec (all
>implementations must support RC2-40. All strong implementations must
>support 3DES).
. . .
>4. The S/MIME spec requires accepting RC2-40 by all S/MIME implementations.
Not true. RFC 3851 is very, very careful about this. [[ Disclaimer: I
helped write a lot of the language in this part of the spec. ]]
Section 2.7 says:
Sending and receiving agents MUST support encryption and decryption
with DES EDE3 CBC, hereinafter called "tripleDES" [CMSALG].
Receiving agents SHOULD support encryption and decryption using the
RC2 [CMSALG] or a compatible algorithm at a key size of 40 bits,
hereinafter called "RC2/40". Sending and receiving agents SHOULD
support encryption and decryption with AES [CMSAES] at a key size of
128, 192, and 256 bits.
SHOULD != MUST.
Further, section 2.7.2 says:
2.7.2. 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.
>In practice the number of weak implementations out there has
>declined, so we may want to rethink our defaults in NSS to be 3DES
>unless we have some hint the recipient is a weak client.
Let's start that rethinking now. The only reason to support RC2/40
for encryption is to send to a receiver that does not support any of
the strong algorithms you know. There are essentially zero
applications for which this is true.
Proposal:
a) Completely turn off the ability to encrypt with RC2/40 unless
there is no strong algorithm.
b) Every time you are about to encrypt with RC2/40, warn the user,
including an explanation of how Tb got to this point in the logic
chain.
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
