RE: S/MIME

I'm sorry, but I have to disagree on that one.  S/MIME DOES use 40 bit 
RC2, by the standard, but the standard specifically states the 
weakness of those keys, and recommends using another implementation. 
 The standard strongly recommends the use of triple-DES, and 
apparently the Communicator and Outlook S/MIME triple-DES now 
interoperates properly.  Deming has also had a plugin which does 
triple-DES for quite a while.  In addition, individual vendors are 
allowed to put in any other algorithms into an S/MIME implementation 
that they desire - for example, the default algorithm in Entrust's 
S/MIME implementation is CAST-128.

The point that I'm trying to make here is that while PGP defines both 
algorithm and protocol, S/MIME just defines protocol.  As long as you 
have two clients which share common algorithms, then you can use any 
algorithms that you like with S/MIME.

								ian

----------
From:  Jonathan Wienke [SMTP:JonWienk@ix.netcom.com]
Sent:  Monday, November 03, 1997 9:34 PM
To:  Nobuki Nakatuji; cypherpunks@toad.com
Subject:  Re: S/MIME

At 08:49 PM 11/2/97 PST, Nobuki Nakatuji wrote:
>Is S/MIME secure than PGP ?

No. S/MIME uses 40 bit keys, which are trivially breakable by 
paralell
brute-force key search attacks.

Jonathan Wienke

-----BEGIN PGP SIGNED MESSAGE-----

In
<c=CA%a=_%p=NorTel_Secure_Ne%l=APOLLO-971104145454Z-34522@mail.entrust.com>,
on 11/04/97 
   at 09:54 AM, Ian Clysdale <iancly@entrust.com> said:

>I'm sorry, but I have to disagree on that one.  S/MIME DOES use 40 bit 
>RC2, by the standard, but the standard specifically states the  weakness
>of those keys, and recommends using another implementation. 
> The standard strongly recommends the use of triple-DES, and  apparently
>the Communicator and Outlook S/MIME triple-DES now  interoperates
>properly.  Deming has also had a plugin which does  triple-DES for quite
>a while.  In addition, individual vendors are  allowed to put in any
>other algorithms into an S/MIME implementation  that they desire - for
>example, the default algorithm in Entrust's  S/MIME implementation is
>CAST-128.

>The point that I'm trying to make here is that while PGP defines both 
>algorithm and protocol, S/MIME just defines protocol.  As long as you 
>have two clients which share common algorithms, then you can use any 
>algorithms that you like with S/MIME.


This is not true.

If you read the S/MIME specs it says one MUST implement the RC2/40
algorithm. A MUST in an RFC has a very definate purpose: If an aplication
does not implement all MUST sections of the RFC then it is not compliant!
To create an S/MIME compliant application one MUST implement RC2/40 and
one MUST pay RSA to do so!!

This is the BIG difference between S/MIME and Open-PGP. In Open-PGP there
is no MUST to implemnet weak crypto. In Open-PGP there is no MUST to
implement propritary algoritms.

For those in the cheap seats:

S/MIME:

- -Weak Crypto
- -Pay RSA

Open-PGP:

- -Strong Crypto
- -Don't Pay Anyone

I think that this should be simple enough for anyone here to understand.

If your Entrust product is going to be using S/MIME to communicate with
overseas users of Netscape and/or MS Outlook then you will be using RC2/40
to do so. That is the reason it is in the specs as a MUST, so MS and
Netscape can export their products!!!

Netscape, Microsoft, and RSA are letting thier greed get in the way of
developing a message encryption protocol that provides strong crypto to
ALL users.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.amaranth.com/~whgiii
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: cp850
Comment: Registered_User_E-Secure_v1.1b1_ES000000

iQCVAwUBNF9Ar49Co1n+aLhhAQH40AQAuHFsUjilp7QeLJoXy6QIZyGEK8T6iQtA
LJDZnTyQvVF/dLvbo5cxVZky8rhdp5GsS5jH1ASlaQGuFzPVqddkZouw5a8GRicw
fLfJvRethaSE2JEHk5GSVehGNHkGI6UbdIWTYGcap5aHxmAXouJTsAWkJbULdUKq
2GHkdXU6LN0=
=7Pba
-----END PGP SIGNATURE-----